VMware CPUID masks for AES-NI and PCLMULQDQ

Today I have been messing with with CPUID masks in ESXi/vSphere. Most people in my position wouldn't normally have to worry about this, but I work for a small company so the budget especially these days is necessarily lean so we chose go for vSphere 5 Essentials PLUS which does not include Enhanced vMotion Compatibility (EVC)

The problem I had was there were two servers that were brought at different times and as is often the case had slightly different specification based on the deals the vendors were offering at the time. Basically the Intel processors had slightly different capabilities Xeon E5530 and E5620 The problem came up when I tried to vMotion VMs from one box to the other, Virtual Center complained that the older server lacked the PCLMULQDQ and AES-NI CPU features:

Host CPU is incompatible with the virtual machine's requirments at CPUID level 0x1 register 'ecx'

So working my way through the KB articles on the VMware website I realised that we were not licensed for EVC so KB 1993 applied. It took me a while to get my head around what was going on but you need to tell the VM when it starts up to ignore the flags for those 2 CPU features so that it isn't using them, so it can happily be moved between host servers that do and don't support those CPU instructions. 

So down to the nitty gritty, how do you actually disable these features. Connect the vSphere client, to either your vCenter server or the ESX server itself. Right click the VM you wish to make more mobile and choose "Settings", then on the "Options" tab select CPUID Mask then click on the "Advanced..." tab. Scroll down to the "Level 1" section and for "ecx" the mask you need is (presented here for your copy and paste delight):

---- --0- ---- ---- ---- ---- ---- --0-

This was explained in the KB 1993 article but they refer to the "Level" as "a"  which is not mentioned in the ESXi 5.0/vSphere 5 configuration screens.

After I changed this setting all the VMs were happy to v|Motion back and forth between the servers.

Exchange 2007 certificate expired

Once a year Outlook starts to moan about the certificate on the Exchange server. This is because the certificate on the Exchange server was set to expire one year after creation.

To check weather this is actually your problem run the following command at an Exchange PowerShell prompt.

Get-ExchangeCertificate | list

This will show you a list of the certificates used by Exchange, the one we are interested in has IIS mentioned in it's list of services. The NotAfter field will tell you when the certificate expires. For me it shows a time about half an hour ago, so we need a new certificate. To create a new one run the following as an Exchange Server Administrator:

New-ExchangeCertificate

This command will ask if you want to overwrite the existing default SMTP certificate, answer yes to this. It should now display (along with other info) a thumbprint for the newly created certificate. Rather than have to re-type this, take a copy of it and use it to paste into the next command. We need to enable the newly created certificate for the IIS service, we do this with:

Enable-ExchangeCertificate -Thumbprint <thumbprint from previous command> -Service IIS

You can remove old certificates from the exchange certificate store with the following command:

Remove-ExchangeCertificate -Thumbprint <thumbprint of old certificate>

If you need a list of certificates details including their thumbprints re-run:

Get-ExchangeCertificate | list

After running the above I noticed that the certificate is now set to be valid for 5 years instead of 1 year. On further investigation it appears that Exchange 2007 SP2 changed the default for self signed certificates from 1 year to 5 years, woohoo!