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.