ERROR vCenter 5.5U2 upgrade to vCenter 6.0U2a: 1603, A change must be made to this systems time and many others

Recently I had several problems upgrading vCenter server 5.5U2 to vCenter server 6.0U2a. Luckily all has been solved now and I owe a huge thank you to  Ciaran McE from VMware Support who has stood by me and helped me to solve this vCenter upgrade problem.

Below I am listing a handful of the errors we have seen, how you can spot them and how you can solve them.

Error 1: Error 1603.

Because SSO appeared to be somehow corrupt [As a test to check if SSO was intact I deleted of a local SSO group resulted in the unavailability of SSO as a whole], I had to install a new external SSO server,  remove and reinstall vCenter server and re-point vCenter, the web client and Inventory services to this new SSO server. Initially I had the impression all was fine, but then I noticed error 2.

Error 2: The web client Task pane shows no tasks but instead shows that there is an error with the task pane.

To solve this I had to reinstall the web client on the vCenter server.
From here i tried to upgrade vCenter 5.5 to vCenter 6.0U2a again and then error 3 was displayed.

Error 3: A change must be made to this system’s date and time

“The SSL certificate off the remote system is not valid for the current date and time. A change must be made to this system’s date and time or the remote system’s certificate before the install can continue.


This usually means you have 2 different time sources.  But that was not the cause in my case. The time difference between both servers, even when using the same NTP source was about 10 to 15 seconds after each reboot. The solution to solve this and get this time as little as possible is to modify the NtpClient settings in the registry. Set the SpecialPollInterval on both the vCenter server and External SSO server to 1  ( original value in my case was e10 = 3600) to get the sync time with the NTP source as little as possible.


Unfortunately that still did not solve my problem.

It appears that VMwareTools in rare occasions can cause an upgrade to fail because it somehow messes with the time source. The solution is to remove VMwareTools and configure a E1000 network adaptor. After this the upgrade succeeded.

Error 4:  Corrupt Network settings after installing VMware Tools again

By removing the E1000 and replacing it with a VMXNET3 adaptor, the vCenter server refuses to take settings, and Windows Control panel does not allow me to enter the settings for the network adapter. Instead the Control Panel hangs.

The solution for this was to install VMwareTools manually by using the VMTools 10.0.9 source. Installing VMwareTools from the vSphere client used the VMwareTools from the host which is still ESXi 5.5.  After replacing the E1000 with VMXNET3 from VMwareTools 10.0.9 all works again.


Isn’t life wonderful?







Be the first to comment

Leave a Reply