Im doing a fresh install of VMware 5.5 remotely. I don't have any modern windows computers on the local network. Can someone point me in the direction of how to get the client installed on windows xp.
I am not sure Windows XP is supported for the client. I would suggest that you use the web client since Firefox and chrome still support XP. The web client would also present all the new features. Just my two cents.
Welcome to the Community,
please take a look at the vSphere 5.5 Release Notes (vSphere Client and vSphere PowerCLI might fail to connect to vCenter Server 5.5, with a handshake failure) for workarounds to be able to run the vSphere Client on Windows XP.
The relevant 32 bit 2003 SP2 KB (KB948963) is
"An update is available to adds support for the TLS_RSA_WITH_AES_128_CBC_SHA AES128-SHA and the TLS_RSA_WITH_AES_256_CBC_SHA AES256-SHA AES cipher suites in Windows Server 2003"
It's possible to extract the 32 bit 2003 hotfix files from the hotfix
by running the hotfix from a command line with the /extract flag, but the extracted files pretty clearly wants to match up against 2003 SP2.
Looking at the extracted files, there are SP installer apps and INF files (most likely to fiddle with registered files for a given SP and configure uninstall information). For the actual hotfix payload, it appears to be only two specific DLLs.
which are what we probably need (and notably only 4 months newer than XPSP3 DLL's). Poking around the INF files suggests they go into system32, and there doesn't seem to be any obvious registry registrations aside from noting the presence of the hotfix install itself. There's even an XP callout, so somebody had thought of doing XP in the hotfix as well but then gave up on it it seems. There are also terminal server/client callouts, so this originally was revolving around RDP connection security issues (FIPS compliance?)
All of which suggests the thin possibility of manually throwing those two DLL's in system32 and having it work. Except to protect against DLL hell, windows replaces foreign DLL's with registered safe DLL's stored elsewhere to prevent tampering, more or less.
But, most apps if written well prioritize local DLL's before using system DLL's. A little experimentation with putting the 2 DLL's into the Launcher directory where VpxClient.exe is causes VIclient to to fail to even start, citing a release name issue with ntdll.dll (likely looking for a 2003SP2 release) so close but no cigar. Trying to put the 2 into the 5.5 directory results in the original handshake error, so the Launcher is clearly doing the connection work and determining which sub parts to load based on the host.
At this point, the easy way out doesn't seem to exist, short of microsoft fixing this hotfix for XP compatibility. Though this link has some interesting info that might be applicable...
This might help a little...
Isuppose a remote possibility is trying to extract the XP 64 bit DLL's but I suspect that has less of a chance of working. Though anyone else is welcome to try.
For those that don't have vCenter or want to connect to a stand alone ESXi 5.5 host via the vSphere Client, you'll need to ssh into the ESXi host and modify the following file: /etc/vmware/rhttpproxy/config.xml
Insert the following xml line into the appropriate section:
After saving your changes restart the service:
You sir a a scholar and a gentleman.
It's important to do this exactly in the right order including using the onboard vi within ESXi, or else you get some sort of weird locking effect on the file making you think you overwrote successfully when you didn't.
at the bottom for details.
use vi to edit the file
locate the right area to edit using arrow keys
press i to enter vi insert mode
add the new line (avoid using tabs?)
press ESC to return to vi command mode
type :w and press enter to overwrite
type :wq to overwrite again and quit vi
Confirm this works.
Wow, the config.xml <cipherList>ALL</cipherList> tip from above allowed my Win XP vSphere 5.5 client to connect after all 🙂
I needed to enable SSH in though 1st ... remember to disable after tuning config.xml,
Been there, tried this (replacing the two DLLs with the ones from the W2003 hotfix): it fails miserably because there are unresolved references to entry points only found in the Windows Server DLLs.
It also breaks XP pretty well, can't even log into the machine anymore (unable to check license status blah blah...)
I had to copy the original DLLs back over the C$ share.
Unfortunately, the fix suggested by VMware themselves on the VCSA appliance (editing server.xml and add ciphers to the list) didn't work for me either.
Oh well, I guess I can live without inventory search whenever I still need to use this XP-based machine.
For those less versed in the collection of services and the methods to restart, here's the line needed to kick it off after the changes were made:
PS This resurrected my XP install of the vsphere client. I had reinstalled with the latest update but to no avail. This did the trick. Thanks.
Thank you all for the info ! - I would have been lost without it
Just to confirm, this worked for me from an old P4 running XP pro with the vSphere 6.0 client
to a Lenovo TS140 running VMvisor 6.0 update 1.
I just restarted the server after the update of the file as I have nothing running yet.