Exchange Ideas - Daniel Kenyon-Smith

I’m a Messaging consultant working for Microsoft Consultancy Services in the UK. Find out about all the latest technology, news, tips and tricks in the world of messaging and much more!

Office 365 and Autodiscover

Office 365 and Autodiscover

  • Comments 7
  • Likes

**This blog is based on Exchange 2010 SP1 and not using the Hybrid configuration wizard e.g. SP2**

I’ve had a few customers in the last few weeks ask me how autodiscover works for Office 365 so thought i’d write a post to try and help! (please see my other post for the namespaces required, as the correct autodiscover records will need to be created in DNS for on-premise and Office 365)

As you probably already know, Exchange 2010 includes a service called the autodiscover service, this service allows an Outlook profile to be automatically configured when using Outlook 2007, 2010 or a Windows mobile 6.1 or later device. The autodiscover service uses a user’s email address and password to automatically configure a user profile. This profile can be configured whether the mailbox is located on-premise or in O365 (for more detailed information about the autodiscover service please the published white paper on TechNet).

On-Premise

For on-premise users to use the autodiscover service (where a user’s mailbox resides on-premise) there needs to be an A host record (other options are available, see the white paper ) created in external DNS that points to the externally facing IP address of the configured listener on TMG for example(for more details on publishing Exchange 2010 with UAG and TMG please see the following white paper - http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=8946)

Office 365

For user’s who have a mailbox located in O365 there needs to be a CNAME record created for the service address space office365.company.com that points to autodiscover.outlook.com.

Example – autodiscover.office365.company.com --> autodiscover.outlook.com

When an on-premise mailbox is migrated to O365 their on-premise TargetAddress attribute will be updated to point to office365.company.com service namespace. Therefore when a user’s mailbox has been migrated to Office365 and Outlook attempts to autodiscover, Exchange will return the TargetAddress back to the user and Outlook will then lookup the autodiscover service at office365.company(which in turn points to O365) and will create the profile. See the diagram below for the process flow.

Note: That when a mailbox is migrated to O365 using rich coexistence there is no outlook reconfiguration or OST resync required after mailbox migration. Migrating mailboxes using rich coexistence supports full fidelity mailbox migrations.

 

O365 AutoD

Written by Daniel Kenyon-Smith

Comments
  • Well presented.

  • Hi Dan,

    Very good Documentation. I have a question.

    We are already running Office 2010 professional and there is an existing outlook profile which is pointing to our on-premises Exchange server. Soon we will be moving our users to O365. I know we cannot use the existing .ost file with O365, so the .ost has to be re-synched to new mailbox in the cloud.

    My Plan (Please correct me if i am wrong).

    1. Create a Cname record for Autodiscovery to O365

    2. I will create a new .MSP file with blank .prf and distribute this through GPO software installation (Please suggest what would be a better option here)

    3. Now when the user lauches outlook (who's mailbox is on O365), based on "TargetAddress attribute", Outlook attempts to autodiscover, Exchange will return the TargetAddress back to the user and Outlook will then lookup the autodiscover service at office365.company(which in turn points to O365) and will create the profile.

    Please let me know if there is anything else i should do to make this work seamlessly.

    Thanking you in advance and waiting for your reply.

    Regards,

    Lewis

  • Hi Lewis

    Thanks for the feedback.

    When you migrate a mailbox to O365 the mailbox GUID moves with the migration, therefore you do not need to create a new .OST file you use the existing one. If you run the hybrid configuration wizard (HCW) with Exchange 2010 SP2 (which is our recommendation to do so) you will now use a domain called TenantName.mail.onmicrosoft.com as the service domain and the HCW will create the relevant autodiscover and MX records for TenantName.mail.onmicrosoft.com, so there is no need for you to do this (as per your step one).

    At a high level this is what you will need to do:-

    1. Run the HCW (which sets up your environment and creates the relevant connectors and DNS records, as well a whole lot more, see here)

    2. Once the HCW has completed successfully you can try some test migrations (ensuring EWS is published as per my other blog article)

    3. Once a mailbox has been migrated the object on-premise will flip to a remote user and the target address of that object on-prem will be user@TenantName.mail.onmicrosoft.com. Therefore when the user opens Outlook and realises their mailbox is no longer on-prem it will start the autodiscover process. Since the HCW created the relevant DNS records the client will redirected to autodiscover. TenantName.mail.onmicrosoft.com.

    4. If you are also using AD FS (for authentication) then once the Outlook client hits the tenant they will be asked to enter their UPN. Once they enter UPN and password then the Outlook profile will automatically create for them (using the existing .OST).

    So all in all the HCW will do the work for you and the Outlook client will automatically redirect and create a profile which is now point to Exchange online (O365). Hopefully that makes sense

    Thanks

    Dan

  • Sorry here are a couple of hyperlinks that didn't carry across into the post above

    blogs.technet.com/.../office-365-hybrid-configuration-wizard-hcw.aspx

    blogs.technet.com/.../office-365-migration-issues.aspx

  • Dear Dan,

    Thank for your quick reponse, appreciated that. We are not going to do a Hybrid Migration as we are a very small company 130 users, so based on my assessment we are looking for a staged migration.

    so based on our scenario the steps that i had sent are they appropriate or there is still something under the hood.

    Steps Again....

    1. Create a Cname record for Autodiscovery to O365

    2. I will create a new .MSP file with blank .prf and distribute this through GPO software installation (Please suggest what would be a better option here)

    3. Now when the user lauches outlook (who's mailbox is on O365), based on "TargetAddress attribute", Outlook attempts to autodiscover, Exchange will return the TargetAddress back to the user and Outlook will then lookup the autodiscover service at office365.company(which in turn points to O365) and will create the profile.

    Thank you for your support.

  • Hi,

    Ahh in that case the process is different. With a staged migration we only support exchange 2003 & 2007, so I assume you don't have 2010... I also assume you have dirsync configured, otherwise it would be a cutover migration.

    Once you have enabled the relevant external access for a migration (e.g. rpc/https) and have migrated a user you will have a mailbox on-premise and in the cloud, so we recommend you convert the on-prem mailbox to a mail enabled user. This will then force the client into performing an autodiscover using the domain based on the script. Have a look here at the pre made script for 2007 -community.office365.com/.../845.aspx and here for the process for a staged migration - help.outlook.com/.../ff959224.aspx

    Cheers

    Dan

  • Thanks Dan for all the valuable information. Looking forward for a successfull Migration.

    Cheers

    Lewis

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment