Yesterday I had a scheduled update of his Veeam Backup & Replication installation with one of my customers. We planned to go from version 9.5 Update 4b (22.214.171.12466) to version 10 GA (10.0.0.4461).
As usual, I created an encrypted configuration backup before the update for safety reasons. How this works and why you should encrypt the configuration backup you can read here and here. I prefer to be a little more cautious at this point, before I have the trouble in hindsight. However, I did not need the configuration backup. The update went smoothly and without problems.
Since I carried out the update during the day, it was not possible, in agreement with the customer, to perform a complete backup run directly after the update. Therefore, I did a short functional test using the Quick Backup capabilities of Veeam Backup & Replication. There were no problems here either.
Today the customer called and reported about failed backup jobs. So I looked into it:
In one of their latest updates for macOS Catalina Apple has introduced some new requirements for the acceptance of SSL certificates. The changes are documented here: https://support.apple.com/en-us/HT210176. This means that pages without a corresponding certificate are no longer accessible in Google Chrome. Unfortunately, the default vCenter Server certificate is one of the affected certificates. Unlike other certificate warnings, this error cannot be easily bypassed using Advanced options.
In the following I would like to show you how you can temporarily work around this issue.
As every year, some of my customers use the weeks after Christmas to update their environments. Nearly all of them run their ESXi hosts with vendor-specific Custom Images that provide additional drivers or agents over the standard VMware image. Unfortunately there are almost always problems with conflicting VIBs when they are updated. Of course it was the same this time. In my case, this time it was about a custom image from Fujitsu.
To perform the update successfully the problematic VIB must be removed. The necessary steps for this I would like to point out below.
Last friday I struggled with some of our Dell EMC Datadomain (DD) Systems. I tried to establish a MTree replication between two identical systems. The first few steps worked without an issue, so I was confident to get into the weekend early. But then things changed.
But first things first. Let’s start with the step by step process on how I enabled the replication.
After the gerneral availability of ESXi 6.7 U3, I decided it is time to update my homelab. I used the integrated vSphere Update Manager (VUM) for my nested vSAN Cluster without any issues. During my VCAP-DVC Deploy preparation earlier this year I used an old Intel NUC system to deploy an additional vCenter Server Appliance (VCSA) in order to play around with Enhanced Linked Mode (ELM). I wanted to have the VCSAs in different Layer 3 networks, so I copied the design from the nested cluster and installed a nested router alongside with a nested ESXi host. The nested ESXi is used to host the second VCSA. Due to this design I can not use the integrated VUM of the second VCSA to update this standalone ESXi host.
The virtual machines (VMs) on the standalone ESXi host are not very important, so I decided to shut them down together with the VCSA and update the nested ESXi host via CLI. For details on how to update ESXi 6.x using the CLI, take a look at one of my previous blog posts here. I used this method quite some time so I was certain to have no issues with the update. But this time it was different, the update failed.