Lots of Exchange on-premises updates to install

Microsoft launched Exchange 2016 on October 1, 2015. Five-and-a-half months later Exchange 2016 has its first cumulative update (CU1) along with a batch of other updates – Exchange 2013 CU12, Exchange 2010 SP3 RU13, and Exchange 2007 SP3 RU19. It’s all very exciting, at least so it seems to those who might have started to doubt whether Microsoft had any more interest in updating the on-premises server, which of course they do. At least for now.

The updates are available as follows:

The installation procedure for CU1 and CU12 will update Active Directory as necessary. You can go ahead and apply the changes beforehand by running the setup program with the /PrepareSchema and /PrepareAD switches. Exchange 2016 needs both; Exchange 2013 just needs /PrepareAD.

Apart from the lagged database copy improvements in Exchange 2016 CU1, there isn’t any really new functionality included in these updates. However, some interesting details exist.

First up, an updated SHA-2 compliant S/MIME control is available for Outlook Web App (OWA). The older SHA-1 standard is no longer considered secure in the eyes of those who care about these things so it’s good that the control is being brought up to the SHA-2 level, which is now the standard used for browser certificates. Some communication is necessary to acquaint users with the need to update the control because they will have to install the new version.

The need to move from SHA-1 to SHA-2 is the reason why updates are provided for Exchange 2010 and Exchange 2007. Remember, these versions are now in extended support so all you get are security updates.

Next, Microsoft has decided to standardize on ISO format updates for Exchange 2016 cumulative updates. The new ISOs replace the older self-expanding packages and the logic here is that Windows 2012 and later servers have the ability to mount ISO files, so you might as well use that capability. ISOs are over three times larger than the previous update packages but it is reckoned that this should not be too much of an issue given that networks are faster and better able to copy large files. Although I don’t have any heartburn about this change and doubt that problems will be encountered, those who are at the end of an extended connection might not enjoy the opportunity to download the 6,291.05 MB ISO so much.

As previously flagged, Exchange 2016 CU1 will not use the new scheme for mailbox anchoring for remote PowerShell and Exchange 2013 CU12 will revert to the previous mechanism. Microsoft will continue to figure out how to achieve the intended outcome (to connect to servers running the latest version of Exchange and therefore equipped with the latest PowerShell cmdlets) without breaking installations and preventing administrators doing work.

Another item that received recent coverage was the undesirability of putting .NET Framework 4.6.1 anywhere near an Exchange 2013 or Exchange 2016 server. That situation pertains but Microsoft says that they are near to resolving the issues that prevent them supporting 4.6.1. with Exchange. Plan to see this support in the next cumulative updates for Exchange 2013 (CU13) and Exchange 2016 (CU2) in three months’ time.

In the meantime, the Exchange team’s blog notes that sometimes the .NET Framework makes installing Exchange longer than it should be. This is probably well known in the installed base (who, after all, hasn’t been told that their binaries needed to be recompiled?) and we’re assured that the .NET team is busily working on a fix. In the meantime, if you’ve installed KB3097966 on your Windows 2012 R2 servers (which you should have, because it’s a security advisory), the potential exists that it can take much longer to install Exchange than before because existing code integrity data is rejected. Microsoft therefore recommend that you run the command shown below on all Windows 2012 R2 servers before applying updates to either Exchange 2013 or Exchange 2016:

C:> %windir%Microsoft.NETFramework64v4.0.30319gen.exe update

Oh... Lots of NGen errors to view

The experience to date is that this command invariably signals many warnings such as “failed to load dependency” for various .NET assemblies. Seeing a stream of error messages scroll by might be a source of discomfort. Who can be happy when a command provokes a flood of warnings? However, according to Microsoft, you can ignore any warnings and errors as long as the final status code is 0 (zero). Another good outcome is when your “compilation targets are up to date”. I never experienced success with this procedure on any server I updated. Mostly I saw a -1 status after typing the command:

C:> Echo %ErrorLevel%

You don’t have to run the NGen command before you upgrade a server. Upgrading Exchange will still work, even if it is a little slower because the various assemblies used by Exchange need to be recompiled. The same is true if NGen exits with an error status – just go ahead and upgrade and all will be well (eventually). Processing the mailbox role seems particularly slow, perhaps because of the dependency on the .NET Framework that exists for large components such as the Information Store. I usually see the advice to reboot the server after updating Exchange 2016 to CU1, so expect that too.

Remember that if you operate a hybrid environment based on Exchange 2013 or Exchange 2016, you won’t get much change from Microsoft if your servers aren’t kept at the latest CU level or one prior. This means that you need to run Exchange 2013 CU11/CU12 or Exchange 2016 RTM/CU1.  The same requirement applies when you use Exchange Online Archiving with on-premises servers. Why is Microsoft so strict on this point? Anything that involves cloud and on-premises servers communicating to get work done is complex enough without throwing obsolete software in the mix. You can run older versions of on-premises software if you really want to, but expect no support if you run into issues.

For more information about how to apply cumulative updates to Exchange 2016, see Paul Cunningham's write-up.

As always with updates, make sure to test the new code thoroughly before going anywhere near your production environment. Microsoft has gotten pretty good at churning out quality updates for Exchange, but who wants to be the first to expose an obscure bug in production?

Follow Tony @12Knocksinna