That's a bullshit answer. If there is a reason a simple client like the vSphere client can not run on a DC then that needs to be fixed. Nobody should have to set up and manage a separate machine just to manage VMWare.
Unsupported: edit the vSphere Client MSI with InstEd It! (freeware). In the left side select "LaunchConditions" and delete the row that has the error in it. Save MSI and execute.
How to get MSI? Just execute the exe and when the error displays go to %temp% and look for the extracted exe. Then extract that one again in the same way and you have the MSI.
With that MSI, the client will install and run on domain controllers ...
Photibias: Read dcolpitts's reply, much easier than that. Launch the client installer with /VSKIP_OS_CHECKS="1" and it installs and runs on a DC just fine.
dcolpitts, you are a f*ing genious! You have just saved me a ton of time and trouble. Thank you much for a quick and intelligent answer.
Not sure if this helps but I happen manage approximately 12 virtual datacenters for a single enterprise that contains over 100 VM Hosts and 1500-2000 VMs or so, not to mention a few other enterprise and much smaller environments for clients in the past.
1. Generally we rely on a VPN (static or client based depending on needs and security of your local management environment) to the individual location and then I just use a local client installed on each management workstation in our offices.
2. An alternative would be to run your own vSphere Desktop Client in your office or colo w/ a VPN connection to each client office. If terminal services host that has access into every client environment via static or client based VPN tools. Once the VPN is established you can run any client version you like, as well as make your terminal server any version you like (eg/ WinXP in a DMZ for nothing but management, Win7, Win8.1 or WIndows 2008 R2 (non DC).
3. Another alternative is to use the firewall to create a whitelist at each customer location and open the specific ports you require to reach the vcenter publicly, However if you can configure this you should be able to configure a VPN which would at least encrypt all communications. If you don't have any hardware to configure a VPN with I hope you have managed switches and can configure a public dvPortGroup to handle WAN traffic, then you can install a software firewall solution (there are many) that can provide you the secured access to the network without open access to vCenter, even if it uses its own SSL.
4. If for some reason you do not have a VPN to remotely manage each of your clients Virtualization environments and it requires you to travel onsite then I would expect you tend to bring along a laptop so you could use higher level tools for troubleshooting, and if so use your laptops to run the appropriate vSphere Desktop Client instead of their Domain Controllers.
Best Practices in any environment tends to be lock down your DC's (whether Active Directory for Microsoft or Identity Management for Linux) to run specific applications related to their functions, reduce or eliminate any amount of web browsing from them and limit dynamic applications like Flash, ActiveX etc. etc. etc. to non DC's. The more non directly related functions that get loaded the more often any staff (yours or the clients) decide that browsing and other applications are probably just fine to use. The few companies I know of personally who used DC's like workstations occasionally caused an issue with Malware, trojans and viruses. Unfortunately in the tech industry way too many do not see the major level Faux Pas this causes, your expected to be an expert and know much better than others what is acceptable and not. Being lazy may be a virtue when it comes to programming and engineering, but laziness when it comes to network and server security and not treating a server with high level security roles properly is not a virtue and never will be. I know I take a pretty hard line on these things but the loss of ones career or an important client is not worth the "simplicity" that other configurations provide.
I think that's irrelevant, there's no technical reason why it can't be installed on domain controller, so it shouldn't have that restriction.
I am running vsphere client 5.5 on DC 2012 R2. No issue.
Also, you can install vmware before dcpromo on your server, then you can run it just fine.
Just a thought.
You could do that, but realize it's an unsupported configuration