Ambiguous URLs and their effect on Exchange 2010 to Exchange 2013 Migrations
Published May 23 2013 11:31 AM 182K Views

 

With the recent releases of Exchange Server 2013 RTM CU1, Exchange 2013 sizing guidance, Exchange 2013 Server Role Requirements Calculator, and the updated Exchange 2013 Deployment Asistant, on-premises customers now have the tools you need to begin designing and performing migrations to Exchange Server 2013. Many of you have introduced Exchange 2013 RTM CU1 into your test environments alongside Exchange 2010 SP3 and/or Exchange 2007 SP3 RU10, and are readying yourselves for the production migrations.

There's one particular Exchange 2010 design choice some customers made that could throw a monkey wrench into your upgrade plans to Exchange 2013, and we want to walk you through how to mitigate it so you can move forward. If you're still in the design or deployment phase of Exchange Server 2010, we recommend you continue reading this article so you can make some intelligent design choices which will benefit you when you migrate to Exchange 2013 or later.

What is the situation we need to look for?

In Exchange 2010, all Outlook clients in the most typical configurations will utilize MAPI/RPC or Outlook Anywhere (RPC over HTTPS) connections to a Client Access Server. The MAPI/RPC clients connect to the CAS Array Object FQDN (also known as the RPC endpoint) for Mailbox access and the HTTPS based clients connect to the Outlook Anywhere hostname (also known as the RPC proxy endpoint) for all Mailbox and Public Folder access. In addition to these primary connections, other HTTPS based workloads such as EAS, ECP, OAB, and EWS may be sharing the same FQDN as Outlook Anywhere. In some environments you may also be sharing the same FQDN with POP/IMAP based clients and using it as an SMTP endpoint for internal mail submissions.

In Exchange 2010, the recommendation was to utilize split DNS and ensure that the CAS Array Object FQDN was only resolvable via DNS by internal clients. External clients should never be able to resolve the CAS Array Object FQDN. This was covered previously in item #4 of Demystifying the CAS Array Object - Part 2. If you put those two design rules together you come to the conclusion your ClientAccessArray FQDN used by the mailbox database RpcClientAccessServer property should have been an internal-only unique FQDN not utilized by any workload besides MAPI/RPC clients.

Take the following chart as an example of what a suggested configuration in a split DNS configuration would have looked like.

FQDN Used By Internal DNS resolves to External DNS resolves to
mail.contoso.com All HTTPS Workloads Internal Load Balancer IP Perimeter Network Device
outlook.contoso.com MAPI/RPC Workloads Internal Load Balancer IP N/A

If your do not utilize split DNS, then a suggested configuration may have been.

FQDN Used By DNS resolves to
mail.contoso.com External HTTPS Workloads Perimeter Network Device
mail-int.contoso.com Internal HTTPS Workloads Internal Load Balancer IP
outlook.contoso.com Internal MAPI/RPC Workloads Internal Load Balancer IP

In speaking with our Premier Field Engineers and MCS consultants, we learned that some of our customers did not choose to use a unique ClientAccessArray FQDN. This design choice may manifest itself in one of two ways. The MAPI/RPC and HTTPS workloads may both utilize the mail.contoso.com FQDN internally and externally, or a unique external FQDN of mail.contoso.com is used while internal MAPI/RPC and HTTPS workloads share mail-int.contoso.com. The shared FQDN in either situation is ambiguous because we can't look at it and immediately understand the workload type that's using it. Perhaps we were not clear enough in our original guidance, or customers felt fewer names would help reduce overall design complexity since everything appeared to work with this configuration.

Take a look at the figure below and the FQDNs in use for some of the different workloads. Shown are EWS, ECP, OWA, CAS Array Object, and Outlook Anywhere External Hostname. The yellow arrow specifically points out the CAS Array Object, the value used as the RpcClientAccessServer for Exchange 2010 mailbox databases, and seen in the Server field of an Outlook profile for an Exchange 2010 mailbox.

image
An Exchange 2010 deployment with a single ambiguous URL for all workloads.

Let us pause for a moment to visualize what we have talked about so far. If we were to compare an Exchange 2010 environment using ambiguous URLs to one not using ambiguous URLs, it would look like the following diagrams. Notice the first diagram below uses the same FQDN for Outlook MAPI/RPC based traffic and HTTPS based traffic.

image

If we were to then look at an environment not utilizing ambiguous URLs, we see the clients utilize unique FQDNs for MAPI/RPC based traffic and HTTPS based traffic. In addition, the FQDN utilized for MAPI/RPC based traffic is only resolvable via internal DNS.

image

If your environment does not look like the one above using ambiguous URLs, then you can go hit the coffee shop for a while or play some XBOX 360. Tell your boss we gave the okay. If your environment does look similar to the first example using ambiguous URLs or you are in the planning stages for Exchange 2010, then please read on as we need you to perform some extra steps when migrating to Exchange 2013.

So what’s the big deal? It is functional this way isn’t it?

While this may be working for you today, it certainly will not work tomorrow if you migrate to Exchange 2013. In this scenario where both the MAPI/RPC and HTTP workloads are using the same FQDN you cannot successfully move the FQDN to CAS 2013 without breaking your MAPI/RPC client connectivity entirely. I repeat, your MAPI/RPC clients will start failing to connect via MAPI/RPC once their DNS cache expires after the shared FQDN is moved to CAS 2013. The MAPI/RPC clients will fail to connect because CAS 2013 does not know how to handle direct MAPI/RPC connections as all Windows based Outlook clients utilize MAPI over a RPC over HTTPS connection in Exchange 2013. There is a chance your Outlook clients may successfully fall back to HTTPS only if Outlook Anywhere is currently enabled for Exchange 2010 when the failure to connect via MAPI/RPC takes place, but this article will help with the following.

  1. Ensure you are in full control of what will take place
  2. Ensure you are in full control of when #1 takes place
  3. Ensure you are in a supported server + client configuration
  4. Ensure environments with Outlook Anywhere disabled for Exchange 2010 know their path forward
  5. Help remove the possibility of any clients not automatically falling back to HTTPS
  6. Remove the potentially long delay when Outlook does fail to via MAPI/RPC even though it can resolve the MAPI/RPC URL and then falls back to HTTPS

Shoot… this looks like us. What should we do immediately?

First off, if you are still in the planning stages of Exchange 2010 you need to take our warning to heart and immediately change your design to use a specific internal-only FQDN for MAPI/RPC clients. If you are in the middle of a 2010 deployment using an Ambiguous URL I recommend you change your ClientAccessArray FQDN to a unique name and update the mailbox database RpcClientAccessServer values on all Exchange 2010 mailbox databases accordingly. Fixing this item mid-migration to Exchange 2010 or even in your fully migrated environment will ensure any newly created or manually repaired Outlook profiles are protected, but it will not automatically fix existing Outlook clients with the old value in the server field.

While not necessary as long as you go through our mitigation steps below, any existing Outlook profiles could be manually repaired to reflect the new value. If you are curious why a manual repair is necessary you can refer to items #5 and #6 in Demystifying the CAS Array Object - Part 2. Again, forcing this update is not necessary if you follow our mitigation steps later in this article. However, if you were to choose to update some specific Outlook profiles we suggest you perform those steps in your test environment first to make sure you have the process down correctly.

Additionally as we previously discussed in item #3 of Demystifying the CAS Array Object – Part 1, the ClientAccessArray FQDN is not needed in your SSL certificate as it is not being used for HTTPS based traffic. Because of this, the only thing you would need to do is create a new internal DNS record, update your ClientAccessArray FQDN, and finally update your Exchange 2010 Mailbox Database RpcClientAccessServer values. It bears repeating that you do not have to get a new SSL certificate only to fix an Ambiguous URL situation.

Ok, fixed that… now what about the clients we don’t want to repair manually?

Our suggestion is to implement Outlook Anywhere internally for all users prior to introducing Exchange Server 2013 to the environment.

Many of our customers have already moved to Outlook Anywhere internally for all Windows Outlook clients. In fact, those of you reading this with OA in use internally are good to proceed to the coffee shop or go play XBOX 360 with the other folks if you’d like to.

Now for the rest of you… sit a little closer. Go ahead and fill in, there are plenty of seats in the front row like usual.

In Exchange Server 2013 all Windows Outlook clients operate in Outlook Anywhere mode internally. By following these mitigation steps you will be one step ahead of where you will end up after your migration to Exchange Server 2013 anyways.

If you do not have Outlook Anywhere enabled at all in your environment, please see Enable Outlook Anywhere on TechNet for steps on how to enable it in Exchange 2010. If your company does not wish to provide external access for Outlook Anywhere that is ok. By simply enabling Outlook Anywhere you will not be providing remote access unless you also publish the /rpc virtual directory to the Internet.

It is suggested customers, especially very large ones, consider enabling Kerberos authentication to avoid any potential performance issues you may run into utilizing the default NTLM authentication. Information on how to configure Kerberos Authentication can be found here on TechNet for Exchange Server 2010 and the steps for Exchange Server 2013 are similar which we will have documentation for in the near future. However, please keep in mind Kerberos authentication with Outlook Anywhere is only supported with Windows 7 or later.

By default with Outlook Anywhere enabled in the environment your clients prefer RPC/TCP connections when on Fast Networks as seen below.

image

The trick we use to force Outlook Anywhere to also be used internally is via Autodiscover. Using Autodiscover we can make Windows Outlook clients prefer RPC/HTTPS on both Fast and Slow networks as seen here.

image

The method used to make clients always prefer HTTPS is configuring the OutlookProviderFlags option via the Set-OutlookProvider cmdlet. The following commands are executed from the Exchange 2010 Management Shell.

Set-OutlookProvider EXPR -OutlookProviderFlags:ServerExclusiveConnect

Set-OutlookProvider EXCH -OutlookProviderFlags:ServerExclusiveConnect

If for any reason you need to put the configuration back to its default settings, issue the following commands and clients will no longer prefer HTTP on Fast Networks.

Set-OutlookProvider EXPR -OutlookProviderFlags:None

Set-OutlookProvider EXCH -OutlookProviderFlags:None

You can prepare to introduce Exchange Server 2013 to your environment once all of your Windows Outlook clients are preferring HTTP on both fast and slow networks and are connecting through mail.contoso.com for RPC over HTTPS connections.

There are a small number of things we would like to call out as you plan this migration to enable Outlook Anywhere for all internal clients.

First, your front end infrastructure (CAS 2013, Load Balancer, etc…) must ready to immediately handle the full production load of Windows Outlook clients when you re-point the mail.contoso.com FQDN in DNS.

Second, if your Exchange 2010 Client Access Servers were not scaled for 100% Outlook Anywhere connections then performance should be monitored when OA is enabled and all clients are moved from MAPI/RPC based to HTTPS based workloads. You should be ready to scale out your CAS 2010 infrastructure if necessary to mitigate any possible performance issues.

Lastly, Windows Outlook clients older than Outlook 2007 are not supported going through CAS 2013 even if their mailbox is on an older Exchange version. All Windows Outlook clients going through CAS 2013 have to be at least the minimum versions supported by Exchange 2013. Any unsupported clients, such as Outlook 2003, do not support Autodiscover and would have to be manually with a new MAPI/RPC specific endpoint to assure they continue communicating with Exchange 2010 until the client can be updated and the mailbox migrated to Exchange 2013.

Note: The easiest way to confirm what major/minor version of Outlook you have is to look at the version of OUTLOOK.EXE and EMSMDB32.DLL via Windows Explorer or to run an inventory report through Microsoft System Center Configuration Manager or similar software. The minimum version numbers Exchange Server 2013 supports for on-premises deployments are provided below.

  • Outlook 2007: 12.0.6665.5000 (SP3 + the November 2012 Public Update or any later PU)
  • Outlook 2010: 14.0.6126.5000 (SP1 + the November 2012 Public Update or any later PU)
  • Outlook 2013: 15.0.4420.1017 (RTM or later)

If we were to visualize the mitigation steps from start to end we need to compare it between phases.

First, the upper area of the below diagram depicts the start state of the environment with internal Windows Outlook clients utilizing MAPI/RPC and ambiguous URLs for their HTTPS based workloads. The lower area of the diagram depicts the same environment, but we have now forced Outlook Anywhere to be used by internal Windows Outlook clients. This change has forced all mailbox and public folder access traffic over HTTPS through the mail.contoso.com Outlook Anywhere FQDN.

image

We now have all Windows Outlook clients utilizing Outlook Anywhere internally by levering Autodiscover to force the preference of HTTPS. Now that all Windows Outlook traffic is routed through mail.contoso.com via HTTPS, the ambiguous URL problem has been mitigated. However, you may have other applications integrating with Exchange whom are unable to utilize Outlook Anywhere and/or Autodiscover. These applications will also be affected if you were to update the mail.contoso.com DNS entry to point at Exchange 2013. Before moving onto the second step it may be most efficient to add a HOSTS file entry on the servers hosting these external applications to force resolution of mail.contoso.com to the Layer-7 Load Balancer used by Exchange 2010. This should allow you to temporarily continue routing external application traffic that needs to talk to only Exchange 2010 via MAPI/RPC while you work on updating the applications to be Outlook Anywhere compatible, which they will need to be before they can ever connect to Exchange 2013.

Having dealt with both the Windows Outlook clients and third-party applications whom cannot utilize Outlook Anywhere, we can now move onto the second step. The second step is executed when you are ready to introduce Exchange 2013 to the environment.

The below diagram starts by showing where we finished after executing step one. The lower area of the below diagram shows that we have updated DNS to point the mail.contoso.com entry to the new IP of the new Exchange 2013 load balancer configuration. Because of the HOSTS entry we made our application server continues talking to the old Layer-7 load balancer for its MAPI over RPC/TCP connections. Exchange 2013 CAS will now receive all client traffic and then we proxy traffic for users still on Exchange 2010 back to the Exchange 2010 CAS infrastructure. The redundant CAS was removed from the diagram to simplify the view and simply show traffic flow.

image

In summary, we hope those of you in this unique configuration will be able to smoothly migrate from Exchange 2010 to Exchange 2013 now that you have these mitigation steps. Some of you may identify other potential methods to use and wonder why we are offering only a single mitigation approach. There were many methods investigated, but this mitigation approach came back every time as the most straightforward method to implement, maintain, and support. Given the potential complexity of this change we invite you to ask follow-up questions at the follow Exchange Server Forum where we can often better interact with you than the comments format allows.

Exchange Server Forum: Exchange Server 2013 – Setup, Deployment, Updates, and Migration

Brian Day
Senior Program Manager
Exchange Customer Experience

29 Comments
Not applicable

This article still recommends against enabling Outlook Anywhere for internal use

technet.microsoft.com/.../bb123741(v=exchg.141).aspx    : "Note:  

Outlook Anywhere should be enabled only on Client Access servers that are exposed to the Internet. Do not enable Outlook Anywhere on internal Client Access servers.  "

Not applicable

@Frank, that suggestion is invalid when coexisting with Exchange Server 2013. It is a requirement to enable OA on all legacy CAS when Exchange Server 2013 and 2010 coexist and OA connectivity to the legacy servers is required.

Not applicable

Great article Brian!

Not applicable

Great Article Brian :)

Not applicable

@Brian, does the OA requirement on all legacy CAS servers hold true for CAS servers in a separate (non-internet facing) AD site?

Not applicable

Yes DirtyGoat, you need OA enabled everywhere to allow connections from 2013 to be proxied.

Not applicable

@DirtyGoat, when I was a couple years old I was once knocked down by a goat at a county fair. Are you one of his descendants? If so, tell him I'm now big enough to head butt him back. This TechNet article will eventually contain all of the steps necessary

for OA in a coexistence world. They aren't in it yet, but we're working on an update.

technet.microsoft.com/.../bb123741(v=exchg.150).aspx

Not applicable

Brian, I have internal OA setup, but do you mind recommending me go out and play XBox One.

Kidding apart, Great article and you are the best CAS out there.

Not applicable

@Sai Thanks, but truth be told there is a lot of work from a lot of folks that go into a post like this. The real king of CAS, who likes to wear shorts a lot, had a big hand in it. :)

Not applicable

Hi Brian,

I understand, when ambiguous URLs are implemented, that customers should follow the guidelines in this blog so all internal Outlook clients use OA to access Exchange 2010 mailboxes.

But what if you're not using ambiguous URLs and Exchange 2010 currently runs with outlook.contoso.com (mapi/rpc) & mail.contoso.com (https)? I assume you have nothing to do?

I have the same question regarding the design of a new Exchange 2010 environment. Exchange is designed conform MS best practices with outlook.contoso.com (mapi/rpc) & mail.contoso.com (https). Should internal Outlook 2007/2010 clients use MAPI/RPC or Outlook Anywhere (RPC over HTTPS)? I'm currently designing a new Exchange 2010 environment and there is some discussion about this. I know that with Exchange 2013 all Outlook clients use OA by default but that's a architectural change.

So, regarding Exchange 2010 and not using ambiguous URLs, does MS have any recommendations? Should internal Outlook clients use mapi/rpc by default or force OA? Are there any performance considerations (mapi/rpc clients directly access CAS Array FQDN & OA clients access RPC proxy endpoint)?

Regards, Martijn

Not applicable

@Brian

By enable Kerberos on the CAS Array on Ex2010 we also Register the SPNs for the Service Account. In a Migration Process we Change the URL from Ex2010 to Ex2013. What about the SPNs that reside on the Service Accounts? And how we configure RPC/HTTPs on Ex2013 to use Kerberos?

Not applicable

@Martijn, going with all OA in Exchange 2010 is perfectly fine. There will be an increase of connection counts due to HTTP being a unidirectional protocol unlike RPC and you may have to tweak the CAS a bit (or add more of them) depending on how many active connections your environment has. (See; support.microsoft.com/.../en-us)

@Steve, you will only need your HTTP SPNs in an Exchange 2013 environment. However, if your public folders are still on legacy Exchange versions I would not yet recommend going to Kerberos. Legacy Exchange versions do not support "negotiate" for authentication type, which is required for Kerb auth to work in 2013, and your PF connections will fail. You can utilize Basic or NTLM enabled until your PFs are on 2013, and then you can switch to Negotiate. The same kind of script of kerb is in the .V15Scripts directory. You may notice a warning when running the script that it says it wasn't tested with 620.29 (The RTM CU1 release), but it works fine.

Not applicable

I am in the process of transition from Exchange 2007 to 2013, OA is enabled on both Exchange 2013 and 2007 as well, should i configure the OA internal as NTLM and external as bsic authenticaation in both exchange servers. our domain name is contoso.local and externally we are registered with contoso.com. do you recommend to have internal and external url same in exchange 2013 for outlook any where like mail.contoso.com or should i use different internal and external url.

if i will enable ntlm for internal and basic for external and if outlook is configured to use basic then what will happen

Thanks

Not applicable

@ SKHATRI, there is currently a known issue with Outlook 2007/2010/2013 where they will use the "external" values for Public Folders, and I think auto-mapped mailboxes as well. If your have different settings internally and externally you may still see connections to thinks like PFs use your external settings even if the client is internal. The Outlook team is investigating a fix in the future to make sure all connections prefer Internal settings over External if they can connect to the Internal endpoint.

Not applicable

Thank you for interesting article.

Not applicable

Thanks for this article.

Just a question about how Outlook determine if it's on a slow or fast network?

Not applicable

@OA Switch, Outlook looks at the reported NIC speed to determine between fast/slow networks. Currently anything lower than 128KB is considered slow.

technet.microsoft.com/.../cc179067.aspx

Not applicable

@Brian Day [MSFT], Thanks but I still have some questions regarding this setting. Is this a fixed value based on the network card hardware and found in a WMI class or a computed value that may change depending on the network environnement? If so, how this value is determined?

It's a little off topic but I don't see any situation Outlook can determine is on a slow network(128 Kb connection is pretty rare now) however I noticed Outlook connecting through OA for exampe during a switch from Wireless to Lan.

What happen when both cases "Slow" and "Fast" are not checked: Does Outlook automatically try to connect using OA after failing to connect using RPC?

Not applicable

@OA Switch, a move from WiFi to LAN or vice versa could trigger an OA connection if momentarily Outlook is unable to connect via RPC. Normal network blips unrelated to changing physical network types can also trigger this to take place.

Not applicable

Do the set-outlookprovider commands suggested in the article have any effect in exchange 2013? We've have been exclusively Outlook Anywhere for years and I can't tell you how many times I've manually checked that box to connect using http on fast networks in order to speed up Outlook startup time. Wish I knew about this before. Can I -- should I issue those commands to make clients prefer http on fast networks in my 2013 environment? If so is the syntax the same? Thanks.

Not applicable

@Barebodkin, Exchange 2013 does not use those two Outlook Providers for Exchange 2013 based mailboxes, it actually dynamically generates its own providers (another article being written). Is there any chance somebody a long time ago set a GPO in the environment to configure your OA settings and it keeps reapplying to your user profile?

Not applicable

Hi Brian,

Brilliant article. Just want to confirm one point.

Is autodiscover URL considered an HTTPS workload, if my AutoD URI is same as my CAS Array, is that going to be a problem. ?

Not applicable

@Avi19, one of the first steps any migration to a new version of Exchange performs is to move Autodiscover URLs to the new version of Exchange. So in this case if you don't want to force OA internally for everyone I'd suggest changing the Autodiscover SCPs (Set-ClientAccessServer -AutodiscoverServiceInternalUri) so they can be moved to 2013.

Not applicable

Brian, thanks for your reply. I wasn't clear when I referred to checking the box "on fast networks, connect using HTTP..." many times - I meant that I check the box each time when setting up new profiles for users, which I've done many times. Once checked, the setting does stick. I've been able to incorporate that setting into Outlook 2013 using the office customization tool, but it's not available in the Outlook 2010 office customization tool. I would love to do just what I think you described; issue a setting server side through autodiscover which would implement the "on fast networks...use http" setting -- but in Exchange 2013 for all Outlook versions. If possible how do we do that?

Not applicable

Hi,

and what about following situation:

1. Single-server Exchange 2010 deployment with all roles installed.

2. No split-dns: internal namespace server.domain.local and external mail.externaldomain.com.

3. No Outlook Anywhere enabled externally or internally.

4. No CAS Array object configured, RPCClientAccessServer pointing to server fqdn.

Do I have to reconfigure my environment before migration? I think the only thing to configure is to enable OA on old Exchange 2010 server. Is it correct?

Not applicable

@Barebodkin, you can use the -OutlookProviderFlags:ServerExclusiveConnect parameter with Set-OutlookProvider cmdlet mentioned in the article to force that tickbox on. I don't remember exactly what client versions started respecting the setting so you'll want to make sure you are using at least the Exchange 2013 compatible client versions as they definitely do.

@Robert, you are not affected because your system was never setup with a proper CAS Array Object, thus you won't be moving the current server's FQDN to point at 2013. Your users will connect via MAPI/RPC to 2010 until you move their mailboxes to 2013. Once you move them the 2010 box will issue a ecWrongServer response and trigger a profile update.

Not applicable

Hi Brian,

A bit confused about the "normal" migration steps.

If we have correct URLS like Outlook.domain.com and mail.domain.com - then where in the migration process (coexisting period) will the Outlook automattically switch to rpc over http instead of rpc over TCP? and how?

As I read this blog, we only need the outlookproviderflag trick, if we used ambiguours urls.

Thanks

Not applicable

Looks like us! Only using Outlook 2010/2013. Our plan is to:

1. Change ClientAccessArray FQDN from mail.contoso.com -> outlook.contoso.com where outlook.contoso.com is only DNS resolvable on the internal network and change RpcClientAccessServer on DBs to reflect this new FQDN.

2. Force all clients to OA via Autodiscover and HOSTS-file on app servers.

Easy enough.

Once done, will the ClientAccessArray FQDN (outlook.contoso.com) will be used at all or it's just for "internal use", and once we're all-in E2013, we can remove this FQDN in the DNS?

Not applicable

Brian,

trying to implement this in a domain with many outlook online users.

"Set-OutlookProvider EXPR -OutlookProviderFlags:ServerExclusiveConnect" is working like a charm, but until now the authentication for outlook anywhere was Basic (only users outside TMG). So that will fire the loginbox for the outlook users.

I tried "set-OutlookAnywhere "*******Rpc (Default Web Site)" -ClientAuthenticationMethod ntlm", but it seems like outlook won't get these "authentication settings" from autodiscover before a succesfull logon to outlook.

Should this work, or is what I am expiriencing expected? Please advise

thanks

Carsten

Version history
Last update:
‎Mar 24 2020 01:54 PM
Updated by: