I recently needed to decommission a VCSA and external PSC. Following the VMWare KB 2106736 I proceeded to decomission the servers usign the cmsso utility.
Decommission vCenter — connected to the PSC it is registered with and:
Now to connect to the PSC that will be staying online and decommission the other PSC
I proceeded to use vdcrepadmin to check out the replication partners which is only vcenter-sb-psc.redacted.lan from my PSC that will be staying online:
Then I checked the actual servers:
We see both PSC’s as expected. Finally I removed the PSC that is to be decommissioned:
Error again. Some googling led me to techbrainblog’s excellent page on using these utilities and also the solutions to some common but cryptic errors. Very useful. The solution to this error in particular is to simply shut down the old PSC. It needs to be offline before the command is ran.
Good to go!
The VCSA has it’s own CA built in. It uses that CA to generate certs for all the various services. There are two options available to ensure that the certificate is trusted in the browser:
- Generate a CSR for the cert and submit to a CA who can generate the cert.
- Use Microsoft Active Directory GPO to push out the VCSA’s root CA cert, thereby allowing the workstations to trust the cert already installed.
I went with the second one because the VCSA is using vcenter.mydomain.lan and is only accessible from inside my network which also means only machines on the domain will be connecting to the web interface. This was very simple to make happen…
On the DC:
To distribute certificates to client computers by using Group Policy
- On a domain controller in the forest of the account partner organization, start the Group Policy Management snap-in.
- Find an existing Group Policy Object (GPO) or create a new GPO to contain the certificate settings. Ensure that the GPO is associated with the domain, site, or organizational unit (OU) where the appropriate user and computer accounts reside.
- Right-click the GPO, and then click Edit.
- In the console tree, open Computer Configuration\Policies\Windows Settings\Security Settings\Public Key Policies, right-click Trusted Root Certification Authorities, and then click Import.
- On the Welcome to the Certificate Import Wizard page, click Next.
- On the File to Import page, type the path to the appropriate certificate files (for example, \\fs1\c$\fs1.cer), and then click Next.
- On the Certificate Store page, click Place all certificates in the following store, and then click Next.
- On the Completing the Certificate Import Wizard page, verify that the information you provided is accurate, and then click Finish.
- Repeat steps 2 through 6 to add additional certificates for each of the federation servers in the farm.
Once the policy is setup, you will need to either wait for machine reboots, or for the GP tp update. As an alternative, you can also run gpupdate /force to cause the update to occur immediately. Once complete, you can verify the cert was installed by running certmgr.msc and inspecting the Trusted Root Certification Authorities tree for the cert. It was my experience that the machine still required a reboot due to the browser still not recognizing the new root CA and therefore still displaying the ugly SSL browser error. After a reboot it was good to go.
Ran into some issues with the ssl certs on the vCenter server when trying to run the Migration Assistant. Notes on the will follow, but first links to articles on the actual upgrade:
The issues I ran into with the migration assistant complained of the SSL certs not matching. Upon inspecting the certs I found all were issues for domain.lan except for one which was issued to domain.net. I followed the following articles to generate a new vCenter cert and install it:
- Generate SSL cert using openssl: https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2074942
- Install and activate cert: https://kb.vmware.com/selfservice/search.do?cmd=displayKC&docType=kc&docTypeID=DT_KB_1_1&externalId=2061973
As the Appliance Installed reached Stage 2 of the install where it copies the data to the new VCSA, I received the following error (note the yellow warning in the background along with the details in the foreground):
To resolve this error, I followed the following articles:
- Upgrading to VMware vCenter 6.0 fails with the error: Error attempting Backup PBM Please check Insvc upgrade logs for details (2127574): https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2127574
- Resetting the VMware vCenter Server 5.x Inventory Service database (2042200): https://kb.vmware.com/selfservice/search.do?cmd=displayKC&docType=kc&docTypeID=DT_KB_1_1&externalId=2042200#3
Which essentially had me reset the inventory service’s database due to corruption. I had noticed the vSphere client slow in recent weeks, this could be a side effect.
- Additional more generic docs for tshooting vCenter upgrades: https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2106760
Attempting to join a freshly deployed VCSA server to a AD domain can be problematic if SMB1 is disabled. In my case it was 5.5 but I believe this issue persists in 6.x. SMB1 was disabled on the DC as it should be as it is broken and insecure. The problem lies in the fact that VCSA doesn’t support SMB2 and this causes the error. The VAMI (web interface) might report something like the following when attempting to join the domain:
Additionally, on the VCSA, /var/log/vmware/vpx/vpxd_cfg.log contains entries like the following:
Of course DNS resolution of the VCSA’s hostname should be validated before continuing, but assuming everything else is in working order, the fix is to enable SMB2 on the VCSA.
Verify SMB2 is disabled (note the Smb2Enabled key is 0:
Restart the lwio service:
Log out of VAMI web interface, log back in and retry joining to the domain.