Q
Problem solve Get help with specific problems with your technologies, process and projects.

How do Outlook clients know mailbox moves are done?

I'm migrating Exchange 2010 mailboxes to Exchange 2013. How will Outlook clients know the mailboxes moved after the migration?

In the pre-2007 era of Exchange Server and Outlook, Outlook clients needed to communicate with their old server...

after the mailbox moved or migrated, to be automatically reconfigured for their new server.

Exchange 2010 and Exchange 2013 use a Mailbox Replication Service that the New-MoveRequest cmdlet from the Exchange Admin Center or the Exchange Management Shell invokes. This service performs an incremental synchronization without having to lock the mailbox, allowing end users to stay logged in to Outlook during the move.

Once the move completes, the Outlook client must log off and back on to the system. Should a situation arise that requires you to delay the move's completion -- to avoid disrupting a work day, for example -- you can with the CompleteAfter or PreventCompletion parameters. With the Autodiscover feature, first introduced in Exchange 2007, Outlook clients automatically locate their new mailbox location during the sign-in process by internally querying Active Directory (AD), which is the default, or by querying the domain name system (DNS). External clients will query DNS.

The mechanics of Autodiscover are quite interesting. Outlook 2007 and higher clients on an internal network can locate the Autodiscover service on Client Access Servers (CAS) by performing a query against AD. When CAS is installed, it automatically publishes a Service Connection Point provided to clients' discovery requests. The AutoDiscoverSiteScope property of each CAS is used to determine the appropriate number of CAS for each client request. By default, this value is the AD site name the CAS is located in.

Once the proper number of CAS is determined, the following process takes place:

  1. The client posts an HTTPS request to the Autodiscover service with an XML request.
  2. The Autodiscover service parses and validates the request and identifies the type of client making the request, also known as the provider type.
  3. The Autodiscover returns requested info to the client in an XML file.

Providers for Outlook are either EXCH (RPC) or EXPR (RPC over HTTP(S)); in Exchange 2013, both of these providers use HTTP(S) connections. External clients can also benefit from Autodiscover, but they'll query a DNS record for Autodiscover.SMTP_DOMAIN.TLD where the SMTP domain is equal to the end user's email address.

During a migration from Exchange 2010 to Exchange 2013, a few configuration choices will ensure that Autodiscover works properly during coexistence. Brian Day hosted a session at the Microsoft Exchange Conference 2014 on deploying Exchange Server 2013, including the following recommendations to prevent certificate- and Autodiscover-related issues during a migration to Exchange 2013:

  • Verify that Active Directory Sites and subnets are correctly configured.
  • Optionally create a temporary deployment site in AD for Exchange 2013 CAS so they can be properly configured before moving them into production sites.
  • Verify that the Exchange 2010 and 2013 CAS have the correct AutodiscoverServiceInternalUri defined.
  • Verify that the Exchange 2010 and 2013 CAS have the correct AutoDiscoverSiteScope configured.
  • Enable Outlook Anywhere on all legacy CAS roles.

About the author:
Richard Luckett is a consultant and instructor specializing in messaging and unified communications. He's been a certified professional with Microsoft since 1996 and has 20 years of experience in the public and private sectors. He's a Microsoft Certified Trainer with more than 15 years of training experience with the Microsoft product line and received the Exchange MVP award in 2006, 2007 and 2008. He's also an expert in deploying and integrating Exchange Server and Lync Server. He leads the Microsoft training and consulting practice at LITSG.

Next Steps

Watch out for these Exchange 2013 migration gotchas

An Exchange 2013 migration in 12 steps

Essential Exchange 2013 migration prep steps

This was last published in June 2015

Dig Deeper on Microsoft Outlook

PRO+

Content

Find more PRO+ content and other member only offers, here.

Have a question for an expert?

Please add a title for your question

Get answers from a TechTarget expert on whatever's puzzling you.

You will be able to add details on the next page.

Start the conversation

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

-ADS BY GOOGLE

SearchWindowsServer

SearchEnterpriseDesktop

SearchCloudComputing

SearchSQLServer

Close