--
In Part 10 of this series we configured the VUM DSN in preparation for installing VUM. Pre-staging the proper directory with the trusted SSL certificates makes the installation easier since no post install work is required to replace certificates. In case you don't like pre-staging or already have VUM installed, Part 12 covers changing the VUM SSL certificate post-install.
1. If you didn't use my pre-staging script earlier in the install process, then we need to pre-stage your trusted SSL certificates now. To do this copy the rui.key, rui.crt and rui.pfx files from your D:\Certs\VUM directory to:
C:\Program Files (x86)\VMware\Infrastructure\Update Manager\SSL
2. Start the vSphere Update Manager installation from the vSphere 5.1 main menu.
3. Select vSphere Update Manager and click through the wizard until you get to the following screen. If your system is on the internet then leave the box checked, so that you will have all of the latest patches. If you are on a disconnected/secure network, then uncheck the box so it doesn't try to access the internet.
4. On the next screen enter the FDQN of your vCenter server and the username that VUM will use to access vCenter. In this case I just re-used the vCenter service account, since I don't see a reason to have yet another service account just for VUM. But you certainly could, assuming you gave it appropriate rights in vCenter. Note: If the install hangs at this point, I've seen an issue using the FQDN vice the IP address. Should it hang you can kill the process called vciInstallutils.exe and try again with different credentials, hostname, or IP.
5. If the DSN is properly configured then it should be listed on the next screen.
6. In the drop down change the setting from the IP address to the FQDN.
7. I would strongly urge that you use a different drive for the patch repository, as it can get big and you don't want it filling up your C drive.
8. Sit back and wait for the installation to complete, which shouldn't take very long.
9. Depending on how you configured the permissions on your SQL database, you may need to change the account which the VUM service uses. In my case I needed to reconfigure it to use the vCenter service account, since that had permissions to the VUM SQL database. Restart the service.
In Part 12 I show you how to replace the VUM SSL certificate, in case you didn't use the pre-staging method or want to use different certificate at a later date. If you used the pre-staging method, you can skip directly to Part 13 for some VUM configuration recommendations.
I've finally gotten to this stage , thanks to this blog!!I have however hit a problem installing (upgrading from 5.0 to 5.1) update manager.It won't accept any credential in the vCentre Server Location and credentials box.The service account that has been used all along and that has administrator rights in vCentre.
ReplyDeleteThere seemes to be a few other people having this issue - http://communities.vmware.com/thread/418281?tstart=0
I'm about to open a case with vmware for this issue and see what they come back with.I have changed the server details from FQDN to actual IP to 127.0.0.1 and nothing is working.Computer says no or just hangs.
This is a total clusterfu$k by vmware.At a workshop last week where they told us all that it was seamless.I'll update any developments that come my way.
Conor: According to the above-referenced VMware Community thread the Update Manager installation hangs when third-party or enterprise CA and SSL certificates are installed on the vCenter server. This is the case with us. I did find that the installation succeeded when I changed the FQDN of the vCenter server to 127.0.0.1. We have a small-scale VMware setup, and all the vCenter-related services are running on a single host. Thanks for posting any new information on this. A couple of days ago one of the posters to the community thread said he was opening a tech support case with VMware. Perhaps we will hear the results of that in due time. Thanks. Jeff.
DeleteI did an install of VUM using the 5.1.0B media and this issue STILL exists! I had a support call with VMware on this and the support techs still weren't aware of the issue internally, had no bug identifier, no KB's for it, and couldn't say when it would be addressed. They ended up finding the issue for me via the Communities thread. The thread begins back in September so its not a new issue! QA and bug fix for the whole 5.1 release have been horrible! I can't remember any prior release that caused me so many headaches. :(
DeleteI found another workaround.
ReplyDeleteIf you got VUM on a standalone server you get the install hang due to CA certs on vcenter. Aparantly a bug.
The workaround that worked for me, was to add a DNS entry in DNS that pointed to vcenter IP with another FQDN than the vcenter got.
Than it installes fine, and I get no cert error.
BTW great Blog posts, helped me alot this week..
Best regards
Jorgen
Gents,
ReplyDeleteI had tried all of these suggested workarounds with no avail. Finally, after contacting VMware support and spending an hour troubleshooting, the key emerged.
As vCenter was installed with SSO mode enabled - the VUM wants to validate that this is working; thus, the only credential which work (at least in my case) are those of a domain user who has Administrative rights on vCenter.
Once this users credentials were entered, the install completed without further issues. (I simply used 'shane', as opposed to 'DOMAIN\shane' or 'shane@domain.com')
Sharing,
-Shane
Hi all,
DeleteIn my case, I have a small VM environment and using the same box for vCenter and VUM. When using the FQDN and a valid user account, VUM wasn't able to validate the creds, I'm guessing this is the DNS bug. Using 127.0.0.1 as the ip address/hostname and using any user accounts who has Administrator rights in Vcenter, the installation went through without a hitch.
Btw, a big thanks for Derek who has spent time and effort in creating this blog.
Thank you,
Michael
So taht link above to the KB, it seems the best workaround is to point the installer to either "localhost" or some new DNS FQDN for vCenter not tied to the names on the certificate.
ReplyDeleteie: cert for vCenter is vcenter.domain.com and vcenter
So create a dns entry for vcenter-nossl.domain.com and tell VUM install to use that entry.
btw, Derek this is an AMAZING series of guides you put up. Thank you x10.
@Jeff: Thanks! I spent a TON of time trying to get everything right, in spite of the lack of VMware documentation at the time I wrote it. Glad it helped you out!
DeleteHey Everyone--What is the recommended practice for selecting the role that your vcenter service account runs under? Does it really need to be an administrator or in this case, would an account with the Register Extension permission be good enough?
ReplyDeleteThanks again for the help! This tutorial is amazing! :)
@Anonymous: The vCenter Service account does need local administrator access on the vCenter server(s). It does NOT need domain admin.
DeleteHi Dere,
ReplyDeletethanks for that awesome tutorial!
if someone has installed sql express 2012 you have to install sql 2008 native client to get the update manager installation working!
bye
@Anonymous: Last I checked, any edition of SQL 2012 is NOT supported. While it may appear to work, VMware will not support you.
DeleteTo pass step 4) I had to:
ReplyDelete- Add the vCenter service account to the Administrator role ( Administration > Access > Role Manager ). The "AD-based group" was already there and was added following step 4) & 5) from part 9 of this install series tutorial. With this step I bypassed the error "Setup failed with an unknown error. vCenter credentials could not be validated." as explained here: http://www.getshifting.com/wiki/vum51#error
- Add a new hostname entry in the DNS server that pointed to vCenter IP. With this step I bypassed the "the vcenter server entered is not reachable" screen.
Under Role Manager --> Administrator, I have my vCenter_Administrators active directory group listed in this role (from the SSO Users and Groups tab).
DeleteOnce I put my vCenterService account in my AD vCenter_Administrators group it validated without issue. No domain\user or username@domainname required.