What the heck is this all about... "vSphere Client requires Windows XP SP2 or later. vSphere Client cannot be installed on a domain controller."
We have several (i.e. 30+) smaller clients where they have two physical servers - one with 2008R2 as a DC (with tape drive attached to backup VMware with BackupExec 2012), and one with ESXi 5.x (with virtual AD server too). If we can't install the 5.5 vSphere Client on the 2008R2 DC, then what are we suppose to do to manage the ESXi server after a boot up or when it is in maintenance mode? Installing it a local PC is not an option (in a few cases, the customer use thin clients to connect to XenApp which is on the ESXi host). I should clarify - there is no vCenter at these sites, thus no Web Client, and the ESXi version is either Standard or Enterprise edition.
At this point - I might as well just migrate these customers to Hyper-V instead... Come on VMware - what where you smoking when you thought this up? If we are going to do this to small customers, we might as well back to licensing by memory too which was another great idea you had to drive away the smaller customers...
why not deploy a management VM and install your management software on it? Or avoid the fat install all together and use the Web Client.
Come on VMware - what where you smoking when you thought this up? If we are going to do this to small customers, we might as well back to licensing by memory too which was another great idea you had to drive away the smaller customers...
Why would you use a Domain Controller as a Remote Workstation?
I think your customers should be able to afford a management PC. The vSphere Client needs 1 CPu with 500 MHz, 500MB RAM and 1,5GB Hard disk.
If your clients can't afford that, how are they paying you?
Troy - nice idea, but you missed taking into account when the host is in maintenance mode. The vMA is not going to be running. Yeah I know we can use the CLI and PowerShell to do things.
Schepp - fine - perhaps you can explain how you handle small sites and maybe we can all take something away from your explanation. Explain how you are going go to a customer that never needed to have an additional box and tell them then need to fork out cash for one now. We are not talking fortune 500 customers here - we are talking customers that want to run their hardware for 6+ years to save a penny (not a dollar - a penny).
I have no issue with the move to a web only interface for vCenter, but for those who don't have (or need) vCenter there needs to be an alternative - even if it is not a full alternative. I just fail to see why they would have blocked it on a DC.
I missed something in my previous reply that Troy mentioned... Is there a Web Client for 5.5 without having vCenter? That would suffice.
Ok, so deploy a virtual Management VM as Troy said, configure it to autostart on Host start. If the host is in maintenance mode ( why would it be in maintenance mode anyway? ) you can go to the console and exit the maintenance mode. VM comes back. Problem solved?
Correct me if I am wrong, but **if** a host is configured to auto-start VMs, and it is in maintenance mode (i.e. installing patches), upon reboot, it will initially attempt to start the VMs, and fail because of maintenance mode. Exiting maintenance mode after this automatic start occurs does not result in the host attempting to restart those VMs it already attempted to start. You are also assuming the operator has access to the host's console either physically or via iLO / DRAC, etc - otherwise you are right back to having to using SSH / CLI / PowerShell (in our case - all the servers at our client locations are HP and have iLO Advanced licenses, so it is a muted point in this particular argument).
Further to that, on page 9 of vsphere-esxi-55-single-host-management-guide.pdf, it clearly states "Install the vSphere Client on a Windows system to connect to and manage single ESXi hosts."
I'm sure I'm not the only individual out there that is going to be complaining about this.
I get your frustration and wouldn't know why it can't be on a domain controller, because that of course is the real issue.
***warning - use the information present here at your own risk - I accept no responsibility for anything that may or may not occur as a result of following this information***
fyi... If you use the command line switch /VSKIP_OS_CHECKS="1" to install the vSphere Client, it will install on a 2008R2 domain controller (i.e. VMware-viclient-all-5.5.0-1281650.exe /VSKIP_OS_CHECKS="1" ) The msi's LaunchCondition table contains:
Installed Or (MsiNTProductType<>2 And VersionNT > 501) Or (MsiNTProductType<>2 And VersionNT = 501 And ServicePackLevel >= 2) Or SKIP_OS_CHECKS="1"
I did not try this on a production machine, although I did try it on a dummy DC in my test lab - it does not appear to have broken anything. Looking at the installer, I don't see anything obvious as to why they made this change either.
Another option I have used in the past is to ThinApp the vSphere client. I've also done this with the View client to allow me to run it on the view server for network troubleshooting. I imagine free software (such as portableapps.com) would be successful too.
Thanks for the fix. I can also confirm this works on w2012 DC's as that is what I have in my LAB, not production. I too wonder why the VI client is not supported on DC's?
I just got a response from a member of VMware's Integration Engineering... Here is the exact quote:
We did this deliberately to enforce a Microsoft standard that our guys agree with - don't install software on a DC, but they made that decision in isolation. Nothing more than that. So use the workaround safely and hopefully we can undo this in the future.
So you can safely use the /VSKIP_OS_CHECKS="1" on your DCs after all.
I wonder what Microsoft standard that is? It's not like it's Office or Adobe CS. Following that logic pretty much leaves you with Server Core (plus a desktop license)
Anyway, glad this thread was the first result Google returned. Thanks!
I agree with DCC's frustration and sentiment.
This "No VI-Client on DC" limitation is not logical. I understand not installing roles/services on a DC but an application???
VMware: Please undo this restriction.
I am in absolute agreement with dcolpitts. While I certainly realize what I'm about to describe is not your typical use case scenario, it's what I do at home, and other that I know have copied my setup. So, most of us have a home lab, whether it's for learning, playing, or we just like to run applications out of our homes. Either way, some are bigger and more complex than others, but I say that to say this: my desktop is a domain controller. That way, I have a physical machine that I'm going to pay the power bill on anyway that when the power goes out, I can make sure core services are on first. I certainly realize that it is no way best practices, but the setup works and I would be hard pressed to be pleased with anything that breaks it.
...funny thing is that it works fine to play games on as well.
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.