vSphere client and Windows 7 compatibility

[TiborMarchyn]

When will be vSphere client compatible with Windows 7? or is there any way to connect to vSphere server or vCenter server???

[RParker]

http://communities.vmware.com/thread/211440

[TheSparrow]

The thread posted is titled "vsphere client on Windows 7 rc". Windows 7 is well past RC stage at this point. It is not only been released to manufacturing, but has actually been released to corporate customers worldwide.

This is no longer an issue with the vSphere client not working with a pre-release product, but that the client does not work with a fully released, readily available version of Windows. An estimate of when they will be providing support would be nice.

[gdfghdfhggt]

Yes. This is wholly unacceptable. While I would say the blame rests on Microsoft for causing the issue, there is no excuse for this to still exist over 6 months after discovery. Fix the damn software. We pay a crap load of money for this stuff.

[Dave338]

I'm in the same problem.

Is incomprensible how the client works well in windows Vista and now in Windows 7 (wich is supposed to be more compatible) doesn't work. I installed yesterday windows 7 in my computer and has found many things that worked in Vista and now fails. Bad from Microsoft too....

salu2

[gdfghdfhggt]

Well, specifically, the issue is with a the new revision of .NET we get with windows 7. It appears there is a linking issue in one of the DLLs. I would definitely say Microsoft dropped the ball here, but thats nothing new for .NET. On the other hand, Since this has yet to be patched, and other software seems to be fine... maybe vmware screwed up some how. Hard linked to an ordinal maybe?

That being said... EMC/VMWARE is a big company. Microsoft listens when they talk. This should have been addresses when it was discovered back in april!!

[TheSparrow]

I do find it interesting that the only even somewhat recent application I have found that will not work in Windows 7 is the VI client. I was involved in the Tech Beta for Windows 7 and Microsoft was very insistent on asking for people to report any application or driver incompatibilities so that they could either fix the bug on their end or work with the vendor to get the code fixed. MS specifically did not want to go down the same path of Vista and have a product that launched with compatibility issues. I have to commend them for making this concerted effort. It resulted in amazingly compatible OS. Based on this experience I am amazed that VMware seems reluctant to fix their bug. Yes Microsoft changed .net, but lets face it .net is theirs to change, and the changes didn't seem to break anything else, so it points to bad code on the part of VMware.

I guess the thing that is so astonishing to me, is that the Win7 beta was out and readily available to anyone at the time, long before the flawed VI client was released. How could they have ignored the issue? The final version of Windows 7 has been out and readily available for over a month now. It may not have shipped to consumers yet, but lets face it, the bulk of ESX customers have an SA agreement and have Windows 7 in their hands. The most likely people to run Windows 7 on their desktops are the same customers VMware courts for ESX (early adopting techs) VMware needs to seriously get their act together and release a patch, this is getting absurd.

Half my job is assuring people that VMs are reliable and robust, I jokingly refer to myself as a VM evangilist. It's hard enough to "sell" the idea of VMs to reluctant old-school techs, but having blatant incompatibilities does not help me instill confidence in the product.

[KennedyESX]

Running the vSphere Client on Windows 7

• Copy System.dll (%SystemRoot%\Microsoft.NET\Framework\v2.0.50727\) from a non-Windows 7 system with Microsoft .NET 3.5 SP1 installed to the Windows 7 system.

• Place the file in C:\Program Files (x86)\VMware\Infrastructure\Virtual Infrastructure Client\Launcher\Lib\.

• Edit the VpxClient.exe.config file (C:\Program Files (x86)\VMware\Infrastructure\Virtual Infrastructure Client\Launcher\). Add the following: <runtime> \\ <developmentMode developerInstallation="true"/> \\ </runtime>

• Add the DEVPATH variable via Control Panel → System → Advanced System Settings → Environment Variables to both the User Variables as well as the System Variables. DEVPATH=C:\Program Files (x86)\VMware\Infrastructure\Virtual \\ Infrastructure Client\Launcher\Lib

• Launch the vsphere client (may have to be admin).

[gdfghdfhggt]

This is NOT a fix, and I recommend that everyone avoid this solution. Do not mess with .net if you value your time. Manually staticly lnking in .NET dlls from mixedversion is a recipe for disaster. 3.0 was never designed to run under 7, and 7 was never designed to expect it.

The only possible enterprise deployable fix here is to get virtual center properly compiled.

In the mean time I'm running old xp virtual machines to handle management.

[KennedyESX]

Well, if you base your application managment off of fear than you may want to listen to post, or you can put on your "Big boy" pants and go with logical, well tested work around which is the answer to the question ask.

[TheSparrow]

I tried that fix and it seemed unreliable and flaky. The workaround is nothing more than just a workaround. It is not a real solution to a real problem. Running the VI client off of a VM or using RDP to another Windows machine is every bit as viable of a workaround and is actually supported and not in the least bit risky. That to is merely a workaround not a solution. Either MS needs to fix the backward compatibility issue that only exhibits itself in the VI client (something I am guessing isn't going to happen, since we all know MS was keenly aware of the issue with the VI client long before RTM and chose not to change it), or VMware is going to release an updated version of the VI client. The question still warrants a "Why so long?"

[jarends3]

This is not a "logical, well tested workaround" and not something I would do in a production environment.

Anyone who wears "big boy" pants is not going to use an unsupported workaround for managing their production environment. I think it is unacceptable VMware has not addressed this, but until then, older versions of Windows will need to suffice.

If you want to play with this stuff at home that is fine, but that is not an appropriate fix in my opinion.

If you wish to do it, that's your choice, but I disagree with your statement that he is basing his reluctance to use that workaround (if you call it that) out of fear. I'd say he's the one wearing "big boy pants" by being conservative about this.

Anyway, VMware needs to fix this like yesterday.

[bshacklett]

I must agree that that is a very poor workaround. One of the steps involves making a modification to system-wide environmental variables. That's not something I'm willing to do to band-aid an issue with a single application.

Why is VMWare not showing any effort to resolve this problem? The buzz in the streets is that Windows 7 is going to have a very high deployment rate. Pretending it doesn't exist is not an option.

[obsidian009]

VMware -- when can we expect the vSphere client to be fully compatible with Windows 7? The RTM version of Windows 7 has been available to Enterprise for MONTHS and it's even available to consumers now.

[JamesSykes]

Vmware is shambolic. VDR is complete donkey sh_t and you can't even get a Windows 7 client out when you would have had access to the RC versions and RTM many months ago.

I have to RDP into a vista box just to do my damn work.

[andrebrownjm]

Windows 7 is now out to the public. When will we see vSphere Client fixed to work properly with it? This is a wholly unacceptable situation.

[officeglen]

I think we're being a little hard on VMware here... ESX isn't really their bread and butter and it doesn't make sense that they rush to meet the needs of their early adopting customers. We must understand that they have much more pressing priorities.

We should all be glad VMware Fusion 3 will be released tomorrow with Windows 7 support. This is truly where their prized R&D dollars should go. Not to fill the needs of a bunch of their keen early adopting customers.

Does anyone else find it funny that the only place VMware acknowledges Windows 7 is in the VMware Workstation or VMware Fusion space?

[obsidian009]

Uhm...what are you smoking? Give me a break! Get out of the ESX forums and go back to the fusion forums then.

I could see not having Windows 7 support during RC or before the official consumer launch date....but they should certainly have it by now. Honestly, they had well over a year to test this and make it work if you go through betas, etc. Why do you think Microsoft releases tech previews, betas, RCs, etc? It's for this very reason...so other companies can be prepared for when the product officially launches, their software will work with it. Most good companies have their software up-to-date BEFORE official launch dates. VMware has failed here.

VMware got where it is today by being lightyears ahead of the competition. They face some massive competition now...and if they want to keep their lead they need to stay ahead of the curve. This is not ahead of the curve...it's slow and reactive.

P.S. Fusion is VMware's bread and butter, not vSphere?!

[JamesSykes]

"Uhm...what are you smoking? Give me a break! Get out of the ESX forums and go back to the fusion forums then." "P.S. Fusion is VMware's bread and butter, not vSphere?!"

Ever heard of sarcasm? Shit man it wasn't exactly subltle.

[officeglen]

Maybe I should have used some <sarcasm> tags...

I fully agree with you obsidian009. It is absolutely absurd that this discussion even exists. VMware has really dropped the ball on this.

Combined with this issue and my EMC CX300 SAN not being on the HCL I'm really beginning to sour to VMware. It feels like VMware is turning there back on their core customer base when they need us the most. It feels like they released vSphere is May and have been partying ever since.