Remove Stubborn PSC or vCenter Appliance from an SSO Domain

While attempting to decommission one of our vCenter sites, I ran into an issue removing one of the PSCs. This site consisted of two PSCs and one vCenter appliance. I removed the first PSC from the SSO domain successfully, and then removed the vCenter appliance. Things became a little tricky during the removal of the final PSC. This PSC did not get removed even after running the cmsso-util command. This article will detail the steps I took in decommissioning the site, as well as removing the stubborn PSC.

First, we need to check if vCenter is currently using the PSC we plan on decommissioning. If it is, we need to use the cmsso-util command to redirect vCenter to a different PSC. Instructions for redirecting vCenter can be found here: https://kb.vmware.com/s/article/2113917?language=en_US

To check what PSC your vCSA is currently pointing to, browse to the Advanced Settings for the vCSA in the vSphere Web Client. Filter by this key: config.vpxd.sso.admin.uri

To remove a PSC or vCSA from an SSO domain, connect to a PSC via SSH and run these commands:

To remove a PSC from the vSphere SSO domain:

cmsso-util unregister --node-pnid psc01.ad.vcplab.local --username administrator@your_domain_name --passwd vCenter_Single_Sign_On_password

To remove a vCSA from the vSphere SSO domain:

cmsso-util unregister --node-pnid vcsa.ad.vcplab.local --username administrator@your_domain_name --passwd vCenter_Single_Sign_On_password

After running these commands, delete the virtual appliances. You can also verify the appliances have been removed by browsing to Administration > System Configuration > Nodes in the vSphere Web Client.

If cmsso-util fails to remove any of the nodes, you can use this command to force the removal:

vdcleavefed -h vcsa.ad.vcplab.local -u Administrator -w Passw0rd!

Upon successful completion, you should see something like this:

/usr/lib/vmware-vmdir/bin/vdcleavefed -h vcsa.ad.vcplab.local -u administrator
password:
vdcleavefd offline for server vcsa.ad.vcplab.local
Leave federation cleanup done

When specifying the username, use the SSO admin (administrator). However, do not use the full UPN (administrator@vsphere.local). Doing so will cause the command to fail.

Exchange 2016 Hybrid Deploy Check - Username or Password Invalid

These days, it seems every Microsoft product comes with its own unique set of head scratchers. Microsoft Exchange Server is no exception to this. I was installing Exchange 2016 earlier today, to be used as a hybrid configuration server for Office 365 (no local mailboxes). I downloaded the self depackaging executable from Microsoft, and attempted to install it. If you currently have a hybrid configuration (which we did, with Exchange 2010), the Exchange 2016 installer will detect this and run some tests to verify that the Office 365 tenant is ready for Exchange 2016 (more info here: https://technet.microsoft.com/en-us/library/ms.exch.setup.hybridconfigurationstatuspage(v=exchg.160).aspx). You’ll be prompted for Office 365 credentials (the user must have the Organization Management role). Seems simple enough, right? Wrong.

After typing in the username and pasting the password into the password field, setup came back with an error message stating the username or password was wrong. I then clicked the back button, and it crashed. I ran through this process a few more times, all with the same outcome. I even rebooted the server, which (in my opinion) should never be the resolution to a software problem. I looked through setup logs and found no indication of what the problem could be…



It was on the fourth try that I typed in the password, and this seemed to work. I didn’t receive any error messages about the credentials being wrong. The Exchange setup seemed to continue on successfully. However, it then failed with a different error:



I again looked through the setup logs and found that this error happened anytime setup tried to run the “Get-OrganizationConfig” cmdlet. After troubleshooting for a little while, and no resolution in sight, I turned to Google. One of the posts I came across said that this is a bug in the Exchange installer, and to try and use the Cumulative Update installer instead. Apparently, with Exchange 2016, the Cumulative Update installer’s include all of the Exchange binaries, not just the updated binaries. I downloaded the installer for CU7 (all 6 gigabytes of it…) and successfully installed Exchange 2016. Hope this helps anyone out there struggling with this.

Enable SNMP in ESXi 6.5 via SSH

I was trying to enable SNMP on a few stand-alone ESXi 6.5 hosts the other day. Unfortunately, when attempting to enable this service using the vSphere Host Client, I received a very unhelpful error:

 



I wasn't able to find any helpful information in the logs that could help identify the cause. Interestingly enough, enabling the service through SSH worked. Here's how I did it. First, you'll need to connect to your host via SSH (you will need to enable the SSH daemon first).

Once connected, type in "esxcli system snmp get" to see the current snmp configuration.



To enable SNMP, we first need to configure the community strings. To do that, type in "esxcli system snmp get --communities=<community strings>". Then, enable the service by typing in "esxcli snmp set --enable=true".

You can then verify the new configure by typing in "esxcli system snmp get" again.



Now refresh the vSphere Host Client, and the service should be running.