Skip to main content

Decommissioning vCenter and PSC 6.0 f

We have just consolidated all our work load in two data centres down to one data centre and using the cloud as our DR site. So as we now have only one site it was time to decommission the PSC (Appliance version) and vCenter (Windows version) in the old data centre.

Here are the steps I followed to remove vCenter and PSC from my lab environment assuming you are running at least vSphere 6.0 Update 1 otherwise the command "cmsso-util" will not be available by default. I followed KB article 2106736 but added some steps I took.

  • On the vCenter that you are going to decommission ensure that you have no more host managed by this vCenter. Check which PSC it is registered to by going to the web client. Select “vCenter > Manage > Settings > Advanced Settings” and look for “config.vpxd.sso.admin.uri”
  • Now log on to the PSC where the vCenter is registered to via SSH or console as user “root”
  • Run “shell.set --enabled True”
  • Then run “shell”
  • Run the command cmsso-util unregister --node-pnid vCenterServer_System_Name --username [email protected]_domain_name --passwd vCenter_Single_Sign_On_password. Replace "vCenterServer_System_Name" with your vCenter FQDN. For "[email protected]_domain_name" replace that with the vSphere domain SSO administrator details i.e. [email protected] and for "vCenter_Single_Sign_On_password" replace that with the password of the account you are going to use. Example "cmsso-util unregister --node-pnid vcenter6.myvmx.local --username [email protected] --passwd abcd123"
  • Once you run this command you will receive a warning message “WARNING This step is irreversible! Are you sure you want to unregister host vcenter6.myvmx.local?”. At this point you can still type “N” to quit otherwise if you are happy then go ahead then type “y”
  • It will run a command to unregister your vCenter with the PSC and this could a bit of time and you should get response messages of “success”
  • Once that command has completed and has been successful then you can power off vCenter as it is not part of the solution anymore. You can now delete the decommission the VM with your usual process
  • If you log into your vCenter. Go to "Administration > System Configuration > Nodes" you should see that the vCenter is not registered at all.

Our next step is to decommission our PSC as well from our environment. 

  • Log on to a PSC that you WILL NOT be decommissioning and has a replication relationship with the PSC that you are decommissioning. If you are not sure if it has a relationship then we can do the following 
  • Log on to the PSC via SSH or console
  • Run “shell.set --enabled True”
  • Run “shell”
  • Run “cd /usr/lib/vmware-vmdir/bin” which will take us to the directory where the replication admin command is
  • Run the command  "./vdcrepadmin -f showpartners -h Source_hostname -u Source_username -w Source_password" . Replace "source_hostname" as the PSC you are currently on, use the vSphere "Administrator" account as the "source_username" and use the password for this account. Example would be ./vdcrepadmin -f showpartners -h psc1.myvmx.local -u administrator -w abcd1234 
  • This will show the partners that is connected to the PSC that you are currently on
  • You can then run this command "./vdcrepadmin -f showpartnerstatus -h Source_hostname -u Source_username -w Source_password which will tell you the status of the partners with this PSC
  • Once you are satisfied that this PSC is a partner with the PSC you wish to decommission then we run same "cmsso-util" command on this PSC "cmsso-util unregister --node-pnid Platform_Services_Controller_System_Name --username [email protected]_domain_name --passwd vCenter_Single_Sign_On_password". Replace "Platform_Services-Controller-System_Name" with your FQDN of the PSC that you wish to decommission. "Change [email protected]_domain_name" with your vSphere SSO domain name. Example "cmsso-util unregister --node-pnid psc6.myvmx.local --username [email protected] --passwd abcd123"
  • Again you will receive a message that  "This step is irreversible!" and if you are happy to continue then press “y” otherwise “n”. Once this command is successful then you will see that the node of this goes from vCenter as well in "Administration > System Configuration > Nodes"

I did hit across one issue when I performed the above in my production environment. When I logged in to the web client. I was still receiving this message "Could not connect to one or more vCenter Server systems: https://vCenter_Server_Name:443/sdk"

I SSH back to my working PSC and ran the command "./vdcrepadmin -f showpartners -h Source_hostname -u Source_username -w Source_password"  (replace informatiion where needed) which showed that I still had a relationship with the old PSC. I found a command called "vdcleavefed" where you can use it to remove an offline server.

So as an example I used "./vdcleavefed -h vcenter6.myvmx.local -u administrator -w abcd1234". You will see it goes through the process to remove from the "federation" and once completed you may need to wait for a while for the replication to complete. After that I logged back in to vCenter and the message went away.


  1. Imagine you replace a vcenter by another.
    The old one is very slow (very very) and even if you have registred all hosts on the new vcenter, the old vcenter is unable to remove the host from inventory.

    What's happen if you remove the old vcenter from PSC (within the same site as the new one) ?
    Will it release the ESXI licence that belong to the old vcenter and provide them to the new vcenter (on the same psc) ?


    1. Hi, Usually if ESXi has been given an licence and you re-add the host to another vCenter it will ask if you would want to add that licence to the vCenter. The alternative way is to have the licences on the new vCenter and just reassign them to your ESXi host as you add them to the new vCenter


Post a comment

Popular posts from this blog

Rolling back a version of ESXi

There is an option in VMware where after you have performed an major upgrade of ESXi you can roll back to your previous version. The benefit of this is that you would not need to reinstall your ESXi and its configuration if you had issues with the new software. I had to do this on one occassion in my lab where I upgraded from 6.5 to 6.7 and my VMs would not run because the CPU was not supported in 6.7. Please remember if you are using ISO method to upgrade ESXi please ensure you select "Upgrade ESXi, preserve VMFS datastore". Selecting "Install ESXi, preserve VMFS datastore" does not mean preserving datastore means retaining ESXi as it will still do a clean install of ESXi. This method does not work for vSphere 7.0 as there are changes to the partitions on the boot device. Below are the steps to roll back to a previous version which is quite straight forward. As always perform an backup of your host configuration before you upgrade or rollback ( KB2042141 ). I have

Configuring ESXi 6 host to send logs to Syslog Server

In my previous post I talked about configuring VMware Syslog server for Windows which is installed and enabled by default on installation of vCenter 6 for Windows. I will now describe the basic configuration that is required on an ESXi 6 host to be able to send logs out to a syslog server using my vCenter as the example. 1) Navigate to your ESXi host within vCenter. Go to "Manage" tab and select "Settings" followed by "Advanced System Settings". Look for the settings "" and highlight this settings. Click the pencil icon to edit the configuration for this setting. 2) You can now add the host name or ip address of your syslog server/s. You can enter just hostname or IP address, use udp://hostname:514 or ssl://hostname:1514 to be more specific on the port and protocol to be used. If you have multiple hosts then you use the comma (,) to separate each server i.e. udp://,udp:// 3)We n

Custom ESXi Image - ISO using PowerCLI

There comes a time when you have purchased a new hardware to run your ESXi software and discover that the installable base media provided by VMware does not include the drivers or the drivers are out of date. In the world of Windows (Plug and Play) it would discover the hardware and prompt you to provide the drivers so that Windows would install/update the drivers for the hardware. For ESXi if the drivers are not present during load time then the hardware will possibly not work. VMware uses VIB (vSphere Installation Bundle) as a way for vendors to distribute their drivers. To install these VIBs you can either use Update Manager or command line (esxcli). Now this is all good but it does mean you have to first install the base ESXi then use one of the steps above to install/update the drivers.   Some people might feel that it is OK to update the drivers using the above methods but what if it was the network card that was the new hardware and you needed new drivers. Without the net