Outlook on the web offline access failure

There is a bug in Exchange Server 2016 CU6, CU7, and CU8 that prevents clients from using offline access for Outlook on the web. It was working properly in CU5.

In CU5, in Options, you select Turn on offline access and then another window pane is shown that asks whether you have exclusive use of the computer or not. In CU8 (also CU6 and CU7), that pane appears very quickly and then goes away. Basically the text flickers but it is removed right away. You can see a video of this behavior below.

I tested this with Internet Explorer, Edge, Firefox, and Chrome with consistent results. I also tested this using both Windows 10 and Windows Server 2016 as the client operating systems.

After trying everything I could think of for testing, I posted this issue to the Microsoft support forums and they confirmed that this is a bug and will be fixed in a future update.

• https://social.technet.microsoft.com/Forums/office/en-US/3fbc0750-4a4c-4860-a3cc-f8112e3eec8a/outlook-on-the-web-owa-offline-mode-fail?forum=Exch2016CM

Install-AntispamAgents.ps1 Fails for Exchange 2016 CU7 and CU8

Not many organizations enable the antispam agents on their Exchange servers since they're probably paying for an additional service to do spam filtering. However, if you attempt to enable it on Exchange Server 2016 CU7 or CU8, there is an error in the script that you need to run. As of right now, CU8 is the latest update available so, this may continue in later updates.

To enable the antispam agents in Exchange Server 2016, you run the Install-AntispamAgents.ps1 script located in C:\Program Files\Microsoft\Exchange Server\V15\Scripts. However in CU7 and CU8, you get an error like this:

There are several screens of error information, but the key part is:

A parameter cannot be found that matches parameter name 'EscalationTeam'.

If you open the script and go to line 50, you'll see the following at the end of the line:

If you delete the following text from that line, the script works properly:

-EscalationTeam "AntiSpam";

Please note that this script does have a digital signature. Editing the script invalidates the digital signature. So, to run this script ensure that your execution policy is not set to AllSigned. It will run fine with execution policy set to either Unrestricted or RemoteSigned.

All Certificate Names MUST be in Subject Alternative Names

This has been popping up for a while, but it's worth pointing out again. When you get a SAN/UCC certificate, the DNS name that you use for the subject (common name) also needs to be in the subject alternative names attribute.

For example:

• Subject:
• webmail.contoso.com
• Subject alternative names
• webmail.contoso.com
• exch1.contoso.com
• exch2.contoso.com
• Autodiscover.contoso.com

When you get your certificate from a public certificate authority (CA), most of them ensure that the subject is also added as a subject alternative name. However, some might not and you should watch for it.

It's important to note that the Microsoft CA does not automatically add the subject to the list of subject alternative names. So, make sure that you do it as part of your certificate request for your internal CA.

The reason you need to do this is because of how web browsers are processing subject alternative names. Web browsers are ignoring the subject if a list of subject alternative names is present. All web browsers seem to be enforcing this now. A few years ago, the web browsers would process both the subject and the subject alternative names.

Here's the quote from RFC 2818 from May 2000 (yes, that long ago):

If a subjectAltName extension of type dNSName is present, that MUST be used as the identity. Otherwise, the (most specific) Common Name field in the Subject field of the certificate MUST be used. Although the use of the Common Name is existing practice, it is deprecated and Certification Authorities are encouraged to use the dNSName instead.

As a slightly interesting side note. The subject field is optional when SANs are defined. However, some older software might still require the subject to be defined.

If you are configuring certificates in Exchange server, be aware that the Exchange admin console (EAC) does not properly differentiate between subject and subject alternative names. In the certificate shown below, webmail.adatum.com is in the subject and not in subject alternative names. EAC (Exchange 2016 CU8) is including the subject in the Subject Alternative Names box which can be misleading.