vCenter 6.7 upgrade thumbprint mismatch

I had a rather frustrating experience the other day with a customers vCenter Upgrade. As many of you will know, there is a bit of prep work that goes into these upgrades, so having them not go to plan can be a little disheartening at times, especially when it’s something simple that you missed (Spoiler: it was not DNS).

To set the scene, I tend to do most of my work from an “admin workstation” which has all the tools I need installed. Here, I stepped through the wizard, verified and accepted the SHA1 thumbprints when presented and went onto stage 2 of the upgrade. Shortly after the pre-upgrade checks failed with an “internal error”. Upon checking the upgrade logs, I was presented with the following:

File "/usr/lib/vmware/cis_upgrade_runner/libs/", line 981, in _VerifyThumbprint
raise ThumbprintMismatchException(thumbprint, sha1Digest)
pyVmomi.SoapAdapter.ThumbprintMismatchException: Server has wrong SHA1 thumbprint:65abc597698285900c37f009a5c11ab45c03e123 (required) != ba4b9b745034c61785fdc33ee123d87397ea999c (server)
2019-07-12T23:16:36.999Z INFO root Exiting with exit-code 1

As most would, I did a sanity check in my browser to validate the certificate thumbprint and everything was matching up and I could not find the thumbprint that the installer was referencing. I did notice however that the proxy server had injected itself into the certificate chain, which reminded me of a new agent this customer had recently deployed to their fleet (this is getting more common, as it allows the company to inspect outbound SSL traffic). I checked the thumbprints again from a server that did not not have this agent and sure enough the thumbprint was what the installer was referencing (The correct thumbprint).

Logically, I closed the wizard and re-started stage 2 of the upgrade from the server that was getting the correct thumbprint. My frustration grew as I was presented with the same error message shortly after. There was a good hour spent on re-checking things and inspecting logs.

What I discovered was (may be obvious to some) that it appears that the upgrade wizard writes the thumbprints into the pre-check configuration from Stage 1 when the new appliance is first deployed. In stage two it then validates against this from the newly deployed appliance.

The fix is pretty obvious by now, restarting the upgrade from the server without the proxy agent saw the process go through smoothly. Pretty trivial, but something to be aware of.

TL;DR – Make sure there is nothing (enterprise proxy) injecting itself into your browsers certificate chain on the workstation you’re using the upgrade wizard on as it will throw out the SHA1 thumbprint.

Migrating Windows vCenter 5.5 to VCSA 6.5

So it’s that time again, evaluating how us vSphere admins are going to get our customers/employers up to the latest and greatest version. If you’ve ever done upgrades from previous versions to 5.5, you will immensely appreciate the work that the engineering team over at VMware has done to help us migrate over to 6.5. The Migration Assistant is really amazing and does a lot of the heavy lifting.

In saying that, there are a few things you’re going to have to validate and prepare for if you want to have a smooth migration. I recently went through the steps in a lab environment and will outline the steps I went through to both prepare for the migration and the migration itself. Yes – there may be blogs out there that go through the process already. However, I found that they only covered basic deployment models and this is also an opportunity for me to have some long overdue blog writing practice. Hopefully someone finds this useful.

If there is anything that I’ve missed, messed up or fat fingered please let me know in the comments below.

In the my scenario, vCenter was separated between two windows servers. One held the SSO, Inventory and update manager and web client services, while the other held vCenter. Autodeploy is also in the picture, but on it’s own server. Now, if you’ve been good and read through the upgrade documentation, you will notice that as the configuration currently stands, you won’t be able to start the migration. Here are links to useful aricles that got me started with planning out the upgrade.

Important info before upgrading to 6.5: KB2147548
Best Practices in migrating to vCenter 6.5: KB2147686
FAQ’s about the migraiton (Moving to 6.0 but still relevant and helpful): KB2146439
Preparing for migration blog
William Lam has a great collection of most links here:

Update: @emad_younis has a good summary here

Before I started anything else, I wanted to make sure my current deployment was re-aligned to a model which was supported by the migration assistant. The first thing that I needed to do was to get the Inventory service and update manger moved off the server with SSO installed and moved over to the vCenter server.

Moving Inventory Service

Moving the inventoy service is quite simple and this KB article outlines it quite well.
Tip #1 Make sure you have the right version of the 5.5 installer mounted. If this doesnt match your vCenter server you will have a bad time (I know this as I have made this mistake myself and spent too much time that I wish to admit in troubleshooting why my vCenter wouldnt talk to my inventory service after the move).

You may want to consider backing up your inventory service database and restoring it onto the vCenter server. See this link will give you instructions on how to do so. Tip #2 Make sure you have enough space available on the drive which you are creating the backup file on. The database in my environment was about 8GB, which almost filled up my system drive, oops.

Once you’ve re-installed it you will just need to re-point your vCenter to the inventory service with the below command.

cd C:\Program Files\VMware\Infrastructure\VirtualCenter Server\isregtool
register-is.bat vCenter_Server_URL Inventory_Service_URL Lookup_Service_URL
register-is.bat https://vc01.vkarps.local:443/sdk https://vc01.vkarps.local:10443 https://vcsso01.vkarps.local:7444/lookupservice/sdk  

Moving Update Manager

Next, we need to move Update Manager, This article sums up the process quite well. Tip #3 Remember that the DSN needs to be 32bit.

Current and Target State

So once things have been shuffled around, it should look something like this:

VM1: Single Sign On
VM2: vCenter, Inventory Service, Update Manager, Web Client

After the upgrade, VM1 will become the PSC and VM2 will become the VCSA.

Prep tasks

Before you go any further, make yourself a check list to ensure youve got everything ready for the migraiton. These are some of the things that I picked up during the planing phase and had in my check list. They are not in any particular order:

  • Give your colleagues and other teams who use vCenter a heads up, chances are that they are unfamiliar with the web client
  • Test your local administrative credentials on the source Windows servers, in case of roll back
  • Have your vCenter service account and SSO admin passwords handy
  • Validate that you have permissions to domain join permisions.
  • Validate that your vSphere component versions are supported by the migration (Hosts earlier than 5.5 are not) 
  • List out any 3rd party extensions to vCenter or anything that interfaces with it and their versions to confirm their support for 6.5. Ie. Backup software, storage plugins or orchestration software. It is likely that you will need to update these also. 
  • Prepare your sql database guide 
  • Check the size of your database to estimate the size your VCSA needs to be here
  • Estimate your migration time to 6.5 ( Will help with determining and justifying your outage window) KB214620
  • NTP is configured throughout the entire vSphere environment and is in sync.
  • Forward and reverse DNS records work for vSphere components
  • Target vCenter Cluster DRS setting cannot be set to Fully Automated, partial or manual will do.
  • Verify that certificate checking is enabled in vCenter here
  • Lockdown mode must be disabled on at least one host in the cluster which you’re deploying the appliances to
  • The vCenter service account has ‘replace process level token’ rights on the computer object or OU that your vCenter server resides. Policy Path: “Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment\Replace a process level token”
  • If you’re using DHCP for your vCenter address, ensure that the port group or vSwitch accepts mac address changes. ( This was not the case in my scenario but something worth pointing out)
  • Validate that you have enough free disk space on your source server as it will stage data as it extracts it. The Migration Assistant will call this out when it does it’s checks. This size will vary on your database size.
  • Fill out the required installation requirements which vmware has provided here
  • If you have another vCenter server in the mix with it’s own SSO domain, you may consider consolidating SSO domains prior to going to 6.5 as you won’t be able to later KB2033620.
  • Backups, backups and more backups

Deploying new PSC appliance

Alright, time to get the PSC appliance deployed so we can have it ready for migrating the SSO service.
On VM1, which hosts the SSO service, mount the 6.5 VCSA iso and launch the Migration Assistant. The migration assistant is located in X:\migration-assistant\VMware-Migration-Assistant.exe.

A console window will show up and ask you for your SSO password, afterwards it will begin to perform some pre-checks.

You should see something similar to the above. If you’ve missed anything in the pre-checks or something doesn’t stack up, it will let you know. I found that when I first ran this I didn’t have enough storage space for the migration. It should prompt you to enter another location for the migration data.
Have a read through it, as you may miss something important, I found its quite informative and notifies you of certain extensions you may have that will not work after the migration. If you’ve been paying attention, you will notice this screenshot if from a server which had the web client installed on it which will not work after the SSO service is migrated. (This is from another lab environment, but I was happy to not have the web client available during the migration). If all is well, you will see “Waiting for migration to start…”

Next from a workstation or server, mount the same ISO but this time launch the ui-installer (I haven’t had a play with the cli-installer, but that’s an option too for the ones who want to script the migration). Note that this can be run from Unix and OSX machines too!

Click on migrate and proceed to the next step.

Click Next, sign your life away and hit Next again.

Enter in the SSO server fqdn and the SSO Administrator credentials

Next you will be prompted to verify the thumbprint, which you can find in the Migration Assistant console. Make sure this matches up.

Next we will be defining where we wish to deploy our PSC to. Enter in your vCenter server name and credentials to an account which has administrative access.

Select the folder which you wish to place the new appliance

Select your target cluster/ESXi host

Supply your target appliance name and a root password. Note that the new appliance will inherit the OS name of the source server. This might not conform to your naming standard in the enterprise but in my experience I’ve found that it’s easier to have the VM object name the same as the name in the OS in large environments. The installer won’t let you name the VM object the same as your source server as it already exists, so you can either rename your source VM object or rename the appliance VM object later and perform a svMotion to make sure the vm files are consistent.

Select the datastore you wish to deploy to and check whether or not you want it thin provisioned

Now you will need to populate the temporary IP details that the appliance will use during the initial parts of the migration.

Next you will be presented with a summary page outlining the the steps we just went through. Make sure it all stacks up and hit Finish. The wizard will now deploy your new Platform Service Controller.

If all went well, you will see the below screen and have a newly deployed PSC appliance.


Migrating to PSC

So far we have deployed the target PSC appliance but have not migrated anything. In stage 2 of the migration wizard we will be doing just that. When you hit next, so that the wizard can go off and connect to the source SSO server we specified earlier.

You will be prompted to enter in credentials of an AD account which has permissions to join the domain

Choose if you want to opt in or out of the Customer Experience Improvement Program

Review the summary and check the box at the bottom confirming that you have backed up your data.

When you click next, you will be presented with warning advising you that the soruce machine will be powered off during this process. You will have an outage from this point, so if you’re doing production make sure you are in your outage window before clicking OK.

Now the migration will kick off and hopefully finish succesfully in a short while. After you get the success message you will be given some URLs for your new PSC. They should something as follows:

You should now be able to hit the PSC client at https://pscname:443/psc

Deploying VCSA

Now that we have a new external PSC, it is now time to move on to getting vCenter migrated over to 6.5. Make sure that you have upgraded all your SSO servers prior to upgrading vCenter.

Firstly we need to deploy the new vCenter appliance which is quite similar to the steps we took with the PSC appliance. Launching the same ISO and starting the wizard as with the PSC, although this time around the wizard will prompt for the SSO and vCenter service account credentials. You might see a little more going on as the wizard performs it’s health checks as it is more than likely that you have some extensions hooked in with your vCenter (i.e.Update Manager, Backup or Storage software). If you’ve done your prep there should be no suprises here, right? :).
Once the migration assistant has finished and you’re happy to proceed, launch the UI installer from another workstation as in the previous steps. Enter in the required details for the source, target, name, etc. We will skip ahead to the deployment size part.

In this step you will need to select the deployment size of your new VCSA. Note that you can pick a storage size seperately from the compute resrouces. Go back to your checklist and see if your existing database size will fit within the default storage size for the deployment you’ve selected. In my case I needed to increase the size.

The next few steps are the same as before, specify a target datastore, temp IP details and wait for the wizard to finish the deployment. If it all went to plan, you should get a successful completion message. Go on and check out the appliance management page at https://tempIPyouProvided:5480.

Migrating to VCSA

Here is the part where most of the sitting around will happen while the wizard does the heavy lifting. From the previous completion page, click Continue and then next at the Stage 2 screen.

The wizard will now go through and do some pre-migration checks. If you got alerted about extensions in the migration assistant, you will get similar ones in the migration wizard. Have a good read of that’s there as there might be a few things that you may need to fix prior to proceeding. After you’ve acknowledged the warnings you will be prompted to specify AD Domain credentials.

Next you need to decide which data you want to copy over, in my case I wanted to copy all the historical data for no other reason but curiosity. If you have any auditing/compliance requirements in your environment, it might be a good idea to select the same.

The next page gives you a summary of the settings we chose along with a checkbox confirming you’ve performed all the relevant backups. Note that from here onwards the migration will start and shortly after your vCenter will be unavailable. So once again, if you’re in production make sure you’re within your outage window before proceeding. As before, the wizard will warn you of this:

Now it’s time for a well deserved coffee, so go off for a while and enjoy yourself. This part can take a few hours, depending on your source and your database size. You should have a rough idea from the calculations you did in the prep tasks. 🙂

Once it’s done without any errors you should have a smile on your face and be looking at a screen like below:

The new 6.5 VCSA should be up and running with all your configuration in tact. The wizard will display links to your new vcsa management pages:

vSphere Client: https://vcsa.vkarps.local:443/vsphere-client
HTML5 Client ( Partial features available): https://vcsa.vkarps.local:443/ui
Appliance Management:https://vcsa.vkarps.local:5480

Be sure to get familiar with all the clients, especially the HTML5 client which will give you a good idea as to what you will see more of in the future. Don’t forget to poke around the appliance management client. It now gives insight into what’s going on within the vPostgres database which I’m sure you will appreciate.


I’m hoping that everything went well in your migration, however things go do wrong. Fortunately this is one of the easiest rollbacks I’ve had to do in my experience. Due to the nature of the way the migration is done, rolling back is a matter of switching off the appliances and rejoining your windows machines to the network.

Here are the steps that I followed to rollback:

1. Power off the VCSA and PSC appliances
2. Power on your Virtiual Center and SSO servers
3. Logon as Local administrator
4. Ensure the VM is connected to the network
5. In an elevated powershell run the following command to reset the computer password on each server:

Reset-ComputerMachinePassword -Server <YourDomainController> -Credential <yourAdminusername>

6.Reboot both servers
7. Go do your health checks to ensure all services have started and that your VC deployment is back to where you left it.


The migration to 6.5 is one of the easiest ones to date in my opinion and I hope that I’ve done a good job in outlining what’s required and will help you out in your migration. Feel free to give me any type of feedback in the comments section below.

Get on it and #migrate2vcsa.