KB Archives - VMtoday

Update: 10/26/2012 – a patch has been released to correct compatibility between View 5.1 and vSphere ESXi 5.1. See here for more: https://vmtoday.com/2012/10/vmware-view-5-1-x-now-compatible-with-vsphere-5-1/

VMware released vSphere 5.1 shortly after VMworld 2012. The new release of vSphere includes features that will be of great benefit to VMware View virtual desktop infrastructures such as the new Space Efficient virtual disk (.vmdk) format and a new virtual machine format (hardware version 9) that enhances virtual shared graphics acceleration. However, the current version of VMware View (5.1.1) is not compatible with vSphere 5.1. VMware has a knowledge base article (https://kb.vmware.com/kb/2035268) that explains that no current versions of View (up to View 5.1.1) are compatible with vSphere 5.1. The article advises customers to not upgrade vSphere above the supported versions listed in the VMware View 5.1 Release Notes. The article also notes that “vSphere 5.1 is in the process of being certified against VMware View.”

It appears that progress is being made in making vSphere 5.1 compatible with View 5.1. I subscribed to updates to VMware KB 2035268 via RSS and found that on 10/1/2012 an update was published on the article with information on an express patch for vSphere 5.1. The patch info is in the Confidential Information section of the KB article, so you won’t be able to read it and probably won’t get access to the patch. I wonder if the patch would be made available to customers with active SNS who had an itchy trigger finger on their vSphere 5.1 upgrade without reading release notes or checking VMware’s Interoperability Matrixes.

Confidential patches aside, don’t upgrade your View environments to vSphere 5.1 just yet. Wait for VMware to certify interoperability, then work up a good plan for your upgrade and for enabling new vSphere 5.1 features to enhance your VDI environment.

Microsoft today is pushing an update to Windows via Windows Updates that increases the bit length requirements for RSA certificates. With this update, Microsoft is requiring RSA certificates to have a key length of 1024 bits. Some applications do not yet use a 1024 or greater key length and could be impacted by this updated. Some examples:

Internal Microsoft Certificate Authority servers that were built with a less than 1024 key will not start after the update – this will make certification validation for internally generated certs fail (could impact Outlook Web Access, vCenter server, intranet sites, etc.)

Internet Explorer will not allow users to connect to sites secured with less than 1024-bit RSA cert

Installation packages signed with less than 1024-bits will not run without a ‘Unknown Publisher’ security warning being acknowledged.

Microsoft has a list of known issues for this update here: https://support.microsoft.com/kb/2661254

Be on the lookout for this update causing other issues as it is applied across your environments – I suspect the list of known issues is not complete. Many apps use lower strength keys to sign communications (e.g. – VMware View uses a 512-bit signed RSA cert for Java Messaging Service to communicate between Connection Servers. Note – I haven’t heard any issues specific to View and this update, just the first example I thought up).

There is a known issue with VMware vCenter 4.0 and KB 2661254. VMware covers the issue in their KB 2037082 – After installation of Microsoft Security Advisory update (KB2661254), connection to vCenter Server 4.0.x web services may fail. This is due to the vCenter 4.0 self-signed certificate having a key length of 512-bits. After MS KB2661254 is applied to the vCenter Server or to clients accessing the vCenter Server, connections to vCenter Web Services (Managed Object Browser, WebAccess) fails, redirection of http to https fails, (not confirmed – but I suspect is true) some plugins such as vCenter Update Manager that are signed by shorter bit-length certificates will be disabled, and other VMware components such as View Composer and View Connection Servers may not function correctly against a vCenter with an invalidated certificate. To correct the issue, you will need to replace the default Self-Signed certificate with a new certificate. The new cert can be a new Self-Signed, or can be issued from a CA (internal Microsoft Certification Authority or Commercial Third-Party).

vCenter Servers 4.1 and later are 2048 keys by default. However, if you upgrade from a previous version of vCenter and did not apply new certificates, the upgrade may have carried the old 512-bit certificate (which is now invalid due to Microsoft’s update). This means it is possible for vCenter 4.1, 5.0 and 5.1 to have invalidated certificates.