Hi, sorry to dig up such an old post, but i've stumbled across a specific problem behind this "non-english" Problem even on newer systems/installs.
Maybe this helps someone googling around.
I've tried to install CV 10.1 on a system which my customer used to manage his EVA 4400 so far flawlessly.
At first i tried the upgrade but afterwards the CVEVA service would not start. After a reboot the XF service wouldn't start either. So i uninstalled the whole bunch and reinstalled from scratch which led to an installer saying "DONE" but without a working CV on this box.
I've created a little decription for our own company KB here, which i'd like to share with you:
PROBLEM DESCRIPTION:
1. HP P6000 Command View 10.1 Installer (Other versions are also affected) does finish, but only the "HP MIF" (XF) service is installed.
The necessary Service "HP P6000 Command View" (CVEVA) has not been installed, the installation folder %PROGRAMFILES%\Hewlett-Packard\Sanworks\Element Manager for StorageWorks HSV\
is nearly empty and subsequently Command View has not been installed.
The log in "%PROGRAMFILES%\Hewlett-Packard\Installer.log" does show a Command View EVA installer rollback during the Suite Install.
or
2. The Command View has been upgraded, so the "HP P6000 Command View" (CVEVA) service is present, but does not start.
The "HP MIF" service does not start (anymore) as well.
Also access to the folder "%PROGRAMFILES%\Hewlett-Packard\XFROOT" is not possible without resetting ACLs.
The operating system language is NOT ENGLISH
ROOT CAUSE:
A long explanation follows since the main reason of the failed installation lies in between, so this is a brief overwiew what the installer does.
During the installation the Management Integration Framework service ("HP MIF" or "XF") is installed first and gets started immediately.
The XF service does set up everything it needs to run properly like service entries, environemt vars and finally the XFROOT folder under "%PROGRAMFILES%\Hewlett-Packard"
At this point of the installation the XF service is well running and healthy.
Coming up next ist the actual Command View Installation which copies files, sets up service entries and finally tries to start but never comes up running.
The installer-logfile shows that its waiting for the service to come up with the following entry:
"Start service waiting for 1 second :cveva"
After (i think) 60 second the main installer gives up and rolls back the whole Command View stuff but leaving the XF service installed.
Unfortunately the main installer just says "done" - without further notice.
The main problem lies in a quite strange behavior of the CVEVA.EXE process (the "HP P6000 Command View" (CVEVA) service):
The CVEVA.EXE checks and/or sets the NTFS settings of the XFROOT directory on startup. (Can be observed with Procmon)
It tries to set the ACL of the XFROOT-folder to:
"NT-AUTHORITY\SYSTEM" : FULL ACCESS
"ADMINISTRATORS" : FULL ACCESS
Apparently these two group names appear to be hardcoded in cveva.exe (easily found with a hexeditor) which lead to the aforementioned problem.
A german OS would accept "NT-AUTHORITY\SYSTEM" but not "ADMINISTRATORS" since this group is named "ADMINISTRATOREN" in german.
Since this group is not present in the local system, the buildup of this DACL inside of cveva.exe fails, leading to a NULL DACL.
Unfortunately this will not bother CVEVA.EXE from setting a DACL, leading to a NULL DACL on the folder "%PROGRAMFILES%\Hewlett-Packard\XFROOT"
(Can be observed with procmon as well)
Even more unfortunately this NULL DACL behavior has been changed by Microsoft throughout the years and OS evolutions to the point that eventually NO ONE has access.
(This depends on many things, google: "NULL DACL" gives some technical detail about this)
So neither the CVEVA.EXE nor XF.EXE can now access the XFROOT folder anymore.
Since CVEVA.EXE waits for XF.EXE which in turn needs the XFROOT folder but cannot access this anymore due to CVEVA's deliberate NTFS ACL mayhem, the start of CVEVA.EXE stalls.
(Subsequently after a reboot or manual stop the "MP MIF" (XF) service would not start anymore aswell).
So in short: the cveva.exe pulls its own floor during startup by clearing a necessary ACL.
RESOLUTION:
Simply create a local Group called "ADMINISTRATORS" (leaving the localized administrators group untouched) on the local system.
This group does not even need any member inside of it, it's just for this strange CVEVA.EXE behaviour.
FINAL WORDS:
This took me almost a day to sort out using Procmon, ProcExp and OllyDbg and although the search was quite funny i cannot understand WHY this was programmed like this.
Furthermore i'm wondering why this problem seems to be present throughout many versions of CV without a major support document about this. As fgar as i can see this is the ONLY (!) reason for having only EN/JP OS supported.
At least tell something about the HARDCODED Group Name in the installation.
