As any other environment, my lab needs some maintenance from time to time. I use a Windows 2012 R2 VM with the Windows Server Update Service (WSUS) role to keep my Windows VMs up to date. Like many others, I was surprised by KB3148812 (Update enables ESD decryption provision in WSUS in Windows Server 2012 and Windows Server 2012 R2), which broke my WSUS. But the fix was easy: Uninstall KB3148812 and reboot the server.
While upgrading a rather old (but very stable) Veeam Backup & Replication 6.1 installation to 8.0 Update 3 (with intermediate step to 6.5), I ran into a curious error. Right after the welcome screen, this error message
Patrick Terlisten/ vcloudnine.de/ Creative Commons CC0
appeared. A closer look into the BackupSetup.log (you can find this log in the %temp% dir. Just enter %temp% into the Explorer address bar) resulted in this very interesting log entry:
This issue is described in KB2971270 and is fixed in CU6.
I ran a couple of times in this error. After applying changes to SSL certificates (add, replace or delete a SSL certificate) and rebooting the server, the event log is flooded with events from source “HttpEvent” and event id 15021. The message says:
An error occurred while using SSL configuration for endpoint 0.0.0.0:444. The error status code is contained within the returned data.
This is not a brand new issue and it’s well discussed in the VMTN. After applying the ESXi 5.5.0 U2 patches from 15. October 2014, you may notice the following symptoms:
Some Citrix NetScaler VMs with e1000 vNICs loses network connectivity You can’t access the VM console after applying the patches VMware has released a couple of patches in October:
ESXi550-201410101-SG (esx-base) ESXi550-201410401-BG (esx-base) ESXi550-201410402-BG (misc-drivers) ESXi550-201410403-BG (sata-ahci) ESXi550-201410404-BG (xhci-xhci) ESXi550-201410405-BG (tools-light) ESXi550-201410406-BG (net-vmxnet3) More specifically, it’s the patch ESXi550-201410401-BG that is causing the problem.
Today I observed a strange behaviour of several VMs at a customer. Several VMs in a cluster showed an alarm, but neither on the alarm tab of the VM, nor the alarm section at the bottom of the C# client showed an error.
Patrick Terlisten/ vcloudnine.de/ Creative Commons CC0
The customer still uses vSphere 5.0. An upgrade to 5.5 is on the roadmap. The symptoms:
not all VMs in the cluster were affected all, except one VM, were running on one specific host the alarm on a VM disappeared after a vMotion no trigger for the alarm could be found vSphere HA status “protected” The similar behaviour could be observed, if a VM is moved to another cluster using VMware vMotion technology.
