VMware Cloud Community
jprior
Enthusiast
Enthusiast
Jump to solution

VI Client 2.5 only supports 32bit OS?

Working through my ESX 3.5 / VC 2.5 upgrade, I download the new VI client onto my workstation (Vista x64 Enterprise) and receive a lovely error message that "This product be installed only on 32-bit operating systems."

Why was that broken? VI client previously worked fine on x64, now it doesn't? Anyone have any workarounds to get it to run on x64 yet?

Reply
0 Kudos
1 Solution

Accepted Solutions
mcadler
Contributor
Contributor
Jump to solution

I got VI Client 2.5 running on Vista 64 bit today. It took some effort. The first steps are outlined above.

  1. Run the installer. While it is sitting in the error message about needing a 32 bit OS find and copy "VMware Infrastructure Client 2.5.msi" in a subdirectory of the system temporary directory.

  2. Find an MSI table editor. You can get one called Orca from a Microsoft SDK. (Search for orca.msi.)

  3. Using orca, open the .msi file and delete the LaunchConditions steps from InstallUISequence and from InstallExecuteSequence. This new .msi file will install the program.

  4. Trying to connect to a VM will now probably fail. This is because it needs to run in a 32 bit managed environment and the default is 64. You can either change the entire machine state to default to 32 bits using "c:\Windows\Microsoft.NET\Framework64\v2.0.50727\Ldr64.exe setwow" or use corflags.exe from Visual Studio to set the 32 bit env flag on the VI Client binary itself, using "corflags VpxClient.exe /32BIT+" in "C:\Program Files (x86)\VMware\Infrastructure\Virtual Infrastructure Client\Launcher". The corflags solution is cleaner since it only has to be done once and affects only VI Client. I assume the ldr64 command would have to be done after each boot and it is a global change.

Good luck. We shouldn't all have to do this. It would be trivial to make an installable version with these changes.

View solution in original post

Reply
0 Kudos
120 Replies
mcwill
Expert
Expert
Jump to solution

Yep, we hit this as well, and it is probably the only thing stopping me from hitting the "buy" button on the foundation bundle at the moment.

We got around it by temporarily installing the client on another 32bit PC and remote desking to that PC to manage the server. Whilst acceptable for testing it isn't a viable solution for production.

Reply
0 Kudos
jprior
Enthusiast
Enthusiast
Jump to solution

I thought about doing that, but decided I might as well remote into my VC server, seeing as it's hosting the app. Why remote to a client to connect to a server? Right now it's just me that uses the client, but seeing as I am on x64 (because my workstations are VM dev machines, with 4gb ram that I actually want to use) that's a problem.

VMware doesn't seem to be interested in supporting x64 right now, it seems 😐

Reply
0 Kudos
ngrundy
Enthusiast
Enthusiast
Jump to solution

Well this is useful isn't is.

Looks like we will be forced to stay at the 3.0.2 and VC 2.0.2 software level. 4 of the 6 administrators who use VIC on a daily basis here, including myself all run x64 operating systems on our workstations. Be they XP or Vista.

Looks like it's time to find an account manager to start yelling at loudly.

Reply
0 Kudos
dmadden
VMware Employee
VMware Employee
Jump to solution

Even in 3.0.2 the VI Client was only supported on 32 bit operating systems.

Reply
0 Kudos
jprior
Enthusiast
Enthusiast
Jump to solution

Officially supported and not being able to install at all are different things. VMware need to modernize and include 64bit host support.

Reply
0 Kudos
clerum
Contributor
Contributor
Jump to solution

Same here.

x64 workstations are becoming more and more common.

So far VI-Client and itunes are the programs I'm currently having problems with.

Wondering if there is a command line switch to bypass the OS check....

Reply
0 Kudos
admin
Immortal
Immortal
Jump to solution

Hey All,

I've done a "straw poll" worldwide, albeit internally - to my peers to gauge the level of interest, complaints etc in regards to not supporting 64-bit client. To date, only the posts listed here are the only customers worldwide who have said they needed this client to be 64-bit. You do have a valid point that the checker has only now kicked in, so maybe there is a "hidden" 64-bit ADMIN workstation community, which has NOT been seen before by VMware.

As mentioned on a previous post, the documentation has always stated 32-bit requirement for the client, since the overwhelming OS for the desktop worldwide, including IT administration, is still 32-bit based. We have focused our efforts to provide 64-bit support for Linux and Windows and our ESX kernel, which is where we saw the demand - the server backend.

This doesn't mean VMware doesn't care about our customers, or for being shortsighted, etc - each support effort requires backend processes and testing to provide true support for a product. In this case 64-bit client support would entail full integration with the vendor OS (Windows and the various flavours of Linux) - not just "get it to work". That's a huge effort if you think about the amount of OS changes that need to be vetted properly to ensure a working product, support processes in the back-end and continuous development. I want to be clear - VMware is not saying "it's just not worth it", we are saying "do we need to shift resources right now?"

Now this doesn't mean we are not going to ever have support for a 64-bit client, but to be frank it will most likely will not occur immediately as requested by some people. We have also seen issues with some of the OS components in the 64-bit environment, hence the OS checker has been activated. What I will ask if it is possible to remove the OS checker restriction to allow customers to "go it alone" with no support, but even that has it's own issues as some people would assume support since it installed. Maybe a warning message with a check-box so you could agree to "go it alone" before install?

Now I know it's not the true solution you are looking for - but you've all run workstation in the pass to support applications that may not run on your host environment - this would be one of those situations as a workaround temporarily. A small 32-bit XP with the client that you could suspend\activate when needed would do the trick.

Finally , we do listen - this has been raised internally to the executive level in the US by myself just yesterday. We are contiuously evaluating where to put our resources for a variety of products and we will look at this issue from a global perpective in order to make the right decision for all of our customers.

Regards,

Andre Kemp

Sr. Product Marketing Manager

VMware, APAC

Reply
0 Kudos
RickPollock
Enthusiast
Enthusiast
Jump to solution

I think a switch to bypass the OS would be great. I think your going to be seeing more of this with most of the new CPU's being 64-bit compatible. I dont really think its worthwhile to use a 64-bit OS on a PC, but that just my preference.

Reply
0 Kudos
ngrundy
Enthusiast
Enthusiast
Jump to solution

Hi Andre,

Thanks for your response. It's good to see such a request taken seriously. The ability as you say to "go it alone" would be useful in the current situation. I've given consideration to creating a VM as you say on my desktop to run the new client in. My hesitation around this is that next to my web browser and email client the VI Client is where is spend most of my day and having to work within a VM constantly would become tedious fairly quickly. I've done it before when my previous desktop machine was a macintosh.

Hopefully, we'll see some encouraging progress around this in future product updates.

Reply
0 Kudos
shurik
Contributor
Contributor
Jump to solution

Andre, they are not alone :-). All our workstations are XP 64 bit as well and have been for over a year.

Please add my vote Smiley Happy

Alex

Reply
0 Kudos
aharden
Enthusiast
Enthusiast
Jump to solution

With all due respect: without an effort to poll your customer environments programmatically and proactively, there's probably no way you could have known how many customers ran the VI Client on x64 OS's. My VC server and workstation OS's are 32-bit, but I probably have a few VIC installs on shared WS2003 x64 servers.

On the server side, my best practice is to install WS2003 x64 on capable hardware, barring known application incompatibilities. Most 32-bit apps we use run fine on x64. I doubt that VMware or other ISVs will be pushed to support x64 OS's unless customers proactively adopt it. Please know that many of us want to move to x64 OS's natively to support the processors we've been purchasing for over 2 years, as well as to avoid purchasing WS2003 Enterprise for systems with 4GB-32GB of RAM.

Thanks,

-Alex Harden

Reply
0 Kudos
devol_us
Contributor
Contributor
Jump to solution

So vmware supports 64bit guest os's, but you can't manage them from a 64 bit machine? How does that work?

What will you do when someone wants to install virtualcenter onto a 64bit host?

Reply
0 Kudos
nathanbach
Contributor
Contributor
Jump to solution

I completely agree. I just upgraded our lab to VI 3.5 and then found this issue. In a year no admins will be running 32 bit OS. As an Enterprise VMware partner this really is a bad move on VMware's part. It's going to be a big stumbling block to new customers. FIX IT!

Reply
0 Kudos
jlauro
Expert
Expert
Jump to solution

Add me to the list. This is very frustrating. I don't even know why the client is so tied into windows anyways. It should just be packaged as a VM ready for vmplayer if you can't support 64 bit windows. This definitely puts a slowdown on our testing and deployment to 3.5. The worse part is, this is a downgrade as we were previously able to run the other version in 64 bit windows.

If there way a straw poll, it was probably assumed the question was if there was a need for a 64 bit version of the app. No one probably cares much about that as long as a 32 bit version runs under 64 bit windows! Obviously your poll was flawed in how the question was asked.

Reply
0 Kudos
admin
Immortal
Immortal
Jump to solution

Jlauro,

Thanks for your email. The poll was conducted based on asking the question how many customers need 32-bit support for the client under a 64-bit host.

We will have support for this and also a true 64-bit client somtime second-half next year.

Regards,

Andre Kemp

Sr. Product Marketing Manager

Reply
0 Kudos
mcwill
Expert
Expert
Jump to solution

6-12 months, ouch that's a lot longer than I had expected. Or is this the timeframe for a supported solution with an unsupported patch available much sooner?

Unfortunately in order to use VC under a foundation license we have been forced to install 2.5, this now means that I have to start a 32bit VM to manage/monitor our infrastructure which I'm sure you would agree is not ideal to put it lightly.

Reply
0 Kudos
admin
Immortal
Immortal
Jump to solution

Mcwill,

A unsupported patch is in the works, the timeline I gave was for a fully supported version. One of our customers has found a workaround themselves, so you can try this as well: If the customer on question wishes to post the details on what they did I'll leave it up to them. Below are the high-level steps

**The below procedure is not supported by VMware*Implement at your own risk**

1. Set the client installer to Windows 2000 compatibility mode

2. Get access to an MSI editor

3. Open the MSI installer with your editor and removed the setup routine which checks for a 64-bit platform

4. You should be able to install the client completely, with no errors

****Above procedure is not supported by VMware*****

Again using a VM in workstation is something that can alleviate the situation in the short term, so being "forced" to delay implementing a virtualization solution, which reaps tremendous benefits is not realistic, since you do have other options to manage the environment using a workstation VM.

Again I understand this is not the preferred solution and we will have support in the near future based on our own internal roadmap, which not only encompasses just getting a client to work, but also have the proper development and support processes available. Look for 2nd half of 2008 for this, which by the way fits perfectly into some of the previous comments about 64-bit workstations becoming commonplace in 2009.

Regards,

Andre Kemp

Sr. Product Marketing Manager - APAC

Reply
0 Kudos
mcwill
Expert
Expert
Jump to solution

Mcwill,

A unsupported patch is in the works, the timeline I gave was for a fully supported version. One of our customers has found a workaround themselves, so you can try this as well: If the customer on question wishes to post the details on what they did I'll leave it up to them. Below are the high-level steps

**The below procedure is not supported by VMware*Implement at your own risk**

1. Set the client installer to Windows 2000 compatibility mode

2. Get access to an MSI editor

3. Open the MSI installer with your editor and removed the setup routine which checks for a 64-bit platform

4. You should be able to install the client completely, with no errors

****Above procedure is not supported by VMware*****

Yes I saw a posting of this yesterday, however I hit the same problem as the original author. The package installs correctly, but when attempting to log into the VC the client GPFs with the following error...

-


Error Connecting

-


is not a valid Win32 application. (Exception from HRESULT: 0x800700C1)

-


Again using a VM in workstation is something that can alleviate the situation in the short term, so being "forced" to delay implementing a virtualization solution, which reaps tremendous benefits is not realistic, since you do have other options to manage the environment using a workstation VM.

I'm afraid you misunderstood me, I used "forced" in the context of being forced to upgrade to 2.5 in order to use our new VC Foundation license. But don't worry, it happens to me a lot my communication skills aren't that great Smiley Happy

Currently we are using a workstation VM to manage the system, but it does dull the benefits offered by VC 2.5.

Regards,

Iain

Reply
0 Kudos
admin
Immortal
Immortal
Jump to solution

Iain,

Thanks for the reply. As for the GPF, this is what I was referring to a few posts back, about how we have run into issues with some of the components in the 64-bit host environment. Our client has changed significantly compared to previous versions, so that is one of the reasons it worked with no issues in previous releases. We have seen development issues with our new client on a 64-bit host, so due to other priorities the engineers put in the blocking issue to prevent installing the client.

It appears right now the most valid work around is to run a 32-bit VM until we have our 64-bit client available sometime 2nd half next year.

Regards,

Andre Kemp

Sr. Product Marketing Manager - APAC

Reply
0 Kudos