Exchange 2016 upgrade tips and tricks from the field (Part 2)

If you would like to read the other parts in this article series please go to:

• Exchange 2016 upgrade tips and tricks from the field (Part 1)
• Exchange 2016 upgrade tips and tricks from the field (Part 3)

Introduction

In part one of this article series revolving around best practice recommendations including general tips and tricks from the field when you, as a large Enterprise organization, face an upgrade to Exchange 2016, I provided you with a set of recommendations you should try to follow as closely as possible.

In this part 2, we will continue where we left off in part 1.

Let´s get going.

Getting Rid of Ambiguous Namespaces

A common critical showstopper that needs to be remediated prior to being able to upgrade your Exchange 2010 messaging infrastructure to Exchange Server 2016 is what we refer to as ambiguous URLs. Actually, this was a remediation activity for many customers upgrading to Exchange Server 2013. However, since many of the larger customers often skip an Exchange version, we have a new set of customers that have to deal with the ambiguous URLs issue. As a matter of fact, something like 90% of the customers I have upgraded to, or am in the process of upgrading from Exchange Server 2010 to Exchange 2016 have ambiguous URLs configured in their setup.

So what are ambiguous URLs all about then? The short version in the Exchange 2010 deployment days we had a lot of namespaces in play and in order to keep the number of namespaces at a minimum, many customers use the same URL for all Exchange client connectivity and then simply opened the ports for the respective protocols that are in used in the organization. This meant all HTTPS based URLs (OWA, EWS, OA, EAS, OAB and the internal autodiscover URL) use the same namespace which was perfectly fine from a supportability point of view and considered a best practice.

However, a portion of these customers also thought it was a good idea to use this same namespace as the end point for internal Outlook client connectivity, which with Exchange 2010 occurs over RPC to the RPC Client Access Array on the Client Access servers. Hey, it worked right and on top of this many customers were of the impression the RPC endpoint has to be included in the Exchange certificate and by using the same namespace, they could keep the cost down. Well, it worked so no issues as long as the customer stayed on Exchange Server 2010.

But then came Exchange 2013 and later Exchange 2016. Like it has been the case for many years now, one of the first activities you do when a newer Exchange version is deployed, is switch the namespace to point to the new Exchange servers and then let them down-level proxy or redirect as necessary. Imagine what will happen when you point the namespace used for internal Outlook connectivity to the Exchange 2013 or Exchange 2016? Yes, the Outlook client connectivity breaks as the Exchange 2013 or Exchange 2016 do not allow RPC connection directly from a client. With Exchange 2013 and Exchange 2016, internal clients connect to Exchange using the Outlook Anywhere protocol (RPC/MAPI over HTTPS).

There are three approaches you can use to remediate this issue, and you really only want to use one of them. You can change the RPC endpoint, which would mean you had to do a manual repair for all Outlook clients as this change will not be picked up automatically by the client. This is a “no go” in large organizations. Secondly, you could change the URL configured on all Exchange vdirs and the autodiscover internal URL. This would also mean introducing a new DNS namespace. This could break all kinds of things (EWS based line of business applications etc.), but would also mean you would need to communicate to the end users they needed to use a new URL to access their mailbox. Also a “no go” in a large Enterprise organization.

The last approach is to force internal Outlook clients to connect to Exchange using Outlook Anywhere instead of MAPI over RPC. This approach is relatively straightforward as you can do so with an organization-wide Exchange commandlet.

In Exchange 2010, you would need to run the following commands:

Set-OutlookProvider EXPR -OutlookProviderFlags:ServerExclusiveConnect

Set-OutlookProvider EXCH -OutlookProviderFlags:ServerExclusiveConnect

As already mentioned, this issue was identified back with the release of Exchange 2013 RTM and the Exchange CXP team did a great detailed blog post about it. But based on the number of customers that will upgrade directly from Exchange 2010 to Exchange 2016 and because of the number of customers I have seen had to deal with this issue, I find it important to bring it up once again.

Dealing with Exchange Kerberos Authentication

When Exchange 2010 SP1 RTW’d back in August 2010 (can you believe it´s been six years already?!), one of the things that the Exchange Product group had spent a fair amount of resources on getting into the product was a feature that made it possible for MAPI clients (usually internal Outlook clients) to connect to Exchange through a brand new service that in the end was named the RPC Client Access Service through which all clients including MAPI clients would connect to the respective mailboxes.

Previous versions of Exchange server supported Kerberos authentication since the MAPI clients connected to the mailbox server FQDN and not a FQDN pointing at a load balancer in front of a CAS array. With Exchange 2010 RTM, there was no way for MAPI clients to authenticate using Kerberos authentication. Fortunately, with the release of Exchange 2010 SP1, the team came up with a solution. Not a ‘run this single commandlet or checkmark this in the Exchange Management Console’ kind of solution, but a more manual solution that required multiple steps that you can read about here. Despite the cumbersome approach, many Exchange 2010 organizations enabled kerberos authentication for MAPI clients as this was a best practice recommendation in order to reduce the additional load on domain controllers that was caused by NTLM based authentication.

For this reason, there´s a good chance you have kerberos authentication enabled for MAPI clients in your Exchange 2010 infrastructure, which means you need to account for this configuration when upgrading to Exchange 2016. Even though the RPC Client Access service was removed with the release of Exchange 2013, it is still required to enable kerberos authentication for MAPI clients in Exchange 2013 and Exchange 2016 using a similar manual approach, which is explained here.

Bear in mind that if you have kerberos authentication enabled for MAPI clients in your Exchange 2010 infrastructure, you need to follow some specific steps when introducing Exchange 2016 servers in the environment. These steps have been outlined by the Exchange CXP team here. Remember to use two ASA credentials. The existing for Exchange 2010 and a new one for Exchange 2016 as you cannot use one for both versions.

Using different Internal and External URL for Outlook Anywhere

Up until Exchange 2016, we only had a single URL that could be set for Outlook Anywhere. With Exchange 2016, we now have an internal and external URL that can be set since we may want to have different settings for external OA clients and internal OA client. Remember internal Outlook desktop clients must connect to Exchange 2016 using OA or more specifically MAPI over HTTP(S).

If you use a split-brain DNS setup, where the same namespaces are used externally and internally just pointing to different IP addresses, you usually would set the internal and external URLs for OA identically just like the other Exchange virtual directories. However, if you have kerberos authentication enabled on Exchange 2016, you should use different URLs for the internal and external OA URLs. In addition, you should ensure the internal OA URLs is not resolvable from the Internet only in your internal AD DNS.

You should of course also ensure you do not register a SPN and enable kerberos authentication for the internal OA URL.

This concludes part 2 of this multi-part article series.

If you would like to read the other parts in this article series please go to:

• Exchange 2016 upgrade tips and tricks from the field (Part 1)
• Exchange 2016 upgrade tips and tricks from the field (Part 3)