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!
I recently needed to change the IP address of my PSC. Unfortunately it was already inaccessible so I was unable to do it via the standard GUI methods. I SSH’d into the box and had a look but it pretty immediately becomes apparent you can’t just update things the way you would a normal linux box. Enter vami_config_net. I believe this utility is available on any of the VMWare appliances that utilize VAMI/photon but I could be wrong. As you may notice int he article it refers to this being for the vCetner Support Assistant, but it worked just the same for me on my external PSC.
In preparation for migrating from vCenter 6.5 w/ embedded PSC, to a external PSC I needed to validate the replication between my new external PSC and the embedded platform services controller. To validate PSC replication partners, the vdcrepadmin utility can be used. For more information see https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2127057
Note in the above commands, for the -w parameter, non alpha characters must be escaped with a \ otherwise you may get authentication failures.
I am now able to continue with the external psc migration as detailed here: docs.vmware.com/en/VMware-vSphere/6.5/co…
And finally, from the external PSC we can verify replication partners again to see that the embedded PSC has been decommissioned, and the external PSC is the only one listed:
I have used to below commands to recover from a failed PSC deployment. When trying to redeploy after the failed deployment, I encountered the error:
“Failed to run vdcpromo”
Following the below steps on the current PSC resolved the error and I was then able to successfully restart the PSC deployment.
Also, protip to avoid having to keep redeploying the appliance, take a snapshot right after phase 1 completes. Then you can simply restore the snap and access your vm via the web interface to try again.
Additional info: I also ran into this when trying to deploy an additional PSC that had a failed installation, but got a completely different error (see below). Going to Administration -> System Configuration in the flash vSphere web client also displays the failed PSC. Login to the live PSC and use the above commands to cleanup, then restart the new PSC deployment. Refreshing the System Configuration page once the vdcleavefed command was ran confirms the cleanup is complete and the failed install is no longer listed.
The error I received when deploying this PSC was:
Removing the failed deployment via vdcleavefed did not resolve the issue.
I decided to test LDAP connectivity to the PSC from the failed PSC deployment. I SSH’d into the box and did the following:
Edit: Additional semi-related data
Get machine’s guid
Get machine’s pnid (machine/host name?)
Get services in the directory