Moving from Exchange 2010 to Office 365

There are a lot of articles on the Internet on how to create a hybrid environment, where Exchange 2016 is connected to Office 365. Now that’s fine, but when you’re running Exchange 2016 you most like are NOT going to move to Office 365 anytime soon I guess. If you are running Exchange 2010 chances are that you will move to Office 365 (soon), but there aren’t that much articles about moving from Exchange 2010 to Office 365. And a lot of the articles available don’t have the right approach I’m afraid, and will result in you (the customer) having to pay way too much money to your system integrator.

In this article, I’ll try to outline the recommended approach when moving from Exchange 2010 to Office 365 in a hybrid scenario. With Azure AD Connect for synchronization purposes. Cliffhanger: I’m not going to install Exchange 2016 into the existing Exchange 2010 environment Smile

Existing Exchange environment

Our organization is called Inframan and they have their own on-premises Exchange 2010 environment which they have been running for 5 years now without too much issues. There are internal Outlook clients using Outlook 2010 and higher, and there are external clients using Outlook Anywhere. There are also mobile clients using ActiveSync to connect to their Mailboxes. Of course, there is Outlook Web Access, but POP3 and IMAP4 are not used.


Figure 1. Overview of the Inframan Exchange 2010 environment.

On the internal network there are also applications and multi-functional devices that are relaying SMTP messages through the Exchange 2010 server. These messages are sent to recipients on the Exchange 2010 server, but also to external recipients through a dedicated Receive Connector on the Exchange 2010 server.

The fun part starts here. The NetBIOS domain name is Inframan, but the FQDN of the Active Directory (single forest, single domain) is Inframan.local. As such, users login using Inframan\J.Brown, the Inframan organization never used the UPN and this is set the default value, which is J.Brown@Inframan.local.

For message hygiene, an Exchange 2010 Edge Transport server is used using a Realtime Blocklist (RBL) from SpamHaus, Recipient Filtering is configured and some custom words are using in the Content Filtering module of the Edge Transport Server. And yes, this has been working for years.

Prepare for Office 365 and Hybrid Exchange

Inframan has approx. 500 Mailboxes and estimated that a migration to Office 365 will take over 6 months. In these 6 months, they need coexistence, and the user accounts are kept in the on-premises Active Directory an Exchange 2010 hybrid scenario will be implemented.

Note. Usernames and passwords will be synchronized with Office 365 and this is sufficient for now. Single Sign-On via ADFS (Active Directory Federation Services) is not implemented in the Inframan environment at this moment.

Directory Synchronization

Azure AD Connect will be used to synchronize user accounts and passwords from the on-premises Active Directory to Azure Active Directory which is the underlying directory for Office 365 and Exchange Online.

Run IdFix

To make sure your on-premises Active Directory is ready for Azure AD synchronization Microsoft has a tool called IdFix which analyses your Active Directory for any inconsistencies or issues that might cause problem with Azure Active Directory. Well known in this respect are a non-routable UPN suffix, duplicate items or non-routable email addresses. The IdFix DirSync Error Remediation Tools is the official name and can be downloaded here:

When you run the IdFix tool it shows a list of issues in your Active Directory on the console, but you can also export it to a CSV file for analysis in Microsoft Excel for example.


Figure 2. Issues in Active Directory found by the IdFix tool


Figure 3. The same issues exported to a CSV file and imported into Microsoft Excel.

In this environment there are some strange (diacritic) characters that need to be fixed, but also the UPN is configured incorrectly and some email addresses with a .local TLD exists.

A prerequisite for Azure AD synchronization is that the User Principal Name or UPN needs to have a routable domain name as the UPN suffix. So, the Inframan.local cannot be used and the domain name needs to be used. It is strongly recommended to use the same name for the user’s primary SMTP address and the UPN. In this scenario the user’s Email address will be like and the corresponding UPN will be as well.


Figure 4. Adding a routable UPN Suffix using Active Directory Domains and Trusts

Once added you can use the Active Directory Users and Computers to quickly change the UPN suffix for users. Navigate to the correct Organizational Unit, select all users and select properties.

On the Account tab check the UPN suffix check box and use the drop-down box to select the proper UPN suffix.


Figure 5. Select the correct UPN Suffix for the users

Another issue in our environment was that all users have an @inframan.local SMTP address. This is caused by the default Email Address Policy that still holds a @inframan.local entry so all users that were created still received the @inframan.local email address.

The easiest way to remove these additional Email addresses is using a simple PowerShell script, something like:

$Mailboxes = Get-Mailbox -ResultSize Unlimited -OrganizationalUnit Accounts
ForEach($Mailbox in $Mailboxes) {
  $Mailbox.EmailAddresses |
  ?{$_.AddressString -like '*@inframan.local'} |
  %{Set-Mailbox $Mailbox -EmailAddresses @{remove=$_}

This will create an array with all Mailboxes in the OU=Accounts Organizational Unit, and remove every Email address to contains the @inframan.local suffix.

When running the IdFix tool again only two more issues remain, two Distribution Groups still contain an @inframan.local email address, but this can be solved manually using the Exchange Management Console.


Figure 6. Only two more issues exist in our Inframan environment

Once these two last issues are resolved our on-premises Active Directory is fine to connect with Azure Active Directory.

Install and configure Azure AD Connect

Microsoft Azure AD Connect is the tool that’s used to connect and synchronize your on-premises Active Directory to Azure AD, the underlying directory for Office 365.

Azure AD Connect uses service accounts both in the on-premises Active Directory and the Azure Active Directory. In the on-premises Active Directory the service accounts need to be a member of the Enterprise Admins security group, in Azure Active Directory the service accounts needs to be a Global Administrator account.

Note. There’s no need to assign the service account an Office 365 license.

You can install Azure AD connect on a dedicated server (my preference and recommendation) but it can also be installed on a Domain Controller. The downside of this (I think) is that you end up with Domain Controllers with different configurations, something that I’d like to avoid.

Install a new Windows 2012 R2 server, install .NET Framework 4.5 and install all available patches. After downloading the Azure AD Connect software from the Microsoft website ( you can start the installation.

Before you can install and configure Azure AD Connect your Office 365 tenant needs to be enabled for Directory Synchronization. Logon to your tenant using tenant administrator credentials and click on the Admin tile.

In the left-hand navigation menu click on the user icon and select Directory Synchronization in the More dropdown menu.


Figure 7. Select Directory synchronization in the drop-down menu

The directory synchronization wizard is started, and you can just follow the wizard. During the Deployment Readiness Check you can start the Azure AD Connect setup application, and the wizard will guide you through the setup of Azure AD Connect.


Figure 8. Use a service account to connect to Azure Active Directory.

Tip: The password of the service account in Azure Active Directory will expire every 90 days without notifying you as the administrator. Use the Set-MsolUser -UserPrincipalName <service account>@<tenant> -PasswordNeverExpires $true command in Azure Active Directory PowerShell to set the password to never expire. Check the Manage users in Office 365 using PowerShell article for more details.


Figure 9. The domain is verified, the inframan.local domain is not used (and cannot be added).


Figure 10. Make sure you check the Exchange Hybrid Deployment checkbox.

When Azure AD Connect is installed you can continue with the Directory Synchronization wizard. Click Finish when everything has been setup.


Figure 11. Click Finish to close the Deployment Readiness Tool.

Azure AD Connect will automatically start and perform a full synchronization. When you check the Office 365 Admin Center you’ll see the users from your on-premises Active Directory appear. Please note that they are unlicensed at this point.


Figure 12. Users from on-premises Active Directory will appear in the Office 365 Admin Center.

You can use the Office 365 Admin Center to assign a license to all synced users from on-premises Active Directory. Filter all unlicensed users, select all users that need a license and in the actions pane select Edit Product Licenses to assign the appropriate license.

At this point your users can login to the Office 365 portal and check out all available services. Is there a Mailbox in Office 365? No, not yet. All Mailboxes in the on-premises Exchange 2010 environment has a corresponding Mail-Enabled user in Office 365. You can easily check this when logging in to the Exchange Admin Center:


Figure 13. The on-premises Mailboxes appear as Mail-Enabled users in Office 365

The next step is to implement the hybrid configuration with Exchange 2010 and Office 365. This will be discussed in my next blogpost.

24 thoughts on “Moving from Exchange 2010 to Office 365”

  1. Hi Jaap, thanks for maintaining this blog, your articles are very clear and helped me out quite some times.

    What is your opinion of phasing out onprem Exchange altogether? After a cutover migration maintaining an onprem Exchange server feels a little redundant, although it’s quite handy managing Exchange Online.
    In my scenario ADConnect is in place, most of the management options are locked.

    Liked by 1 person

    1. Hi Nick,
      I never recommend decommissioning the last Exchange server on-premises. This one is needed to manage your mailboxes in Exchange Online. While this can be done with ADSI Edit it’s pretty complex, prone to error and not supported.


    1. Hi Justin,
      there are several vendors that sell provisioning solutions, some of them originate from selling hosting solutions, but these work in a hybrid environment as well. I agree, it still is frustrating and confusing. The only thing I know is that Microsoft is working on it, but it’s rather complex.


  2. Hi Jaap,
    I receive the error HCW8001 – Unable to determine the tenant Routing Domain.
    Are you ever see this error?


    1. Salut Stéphane,
      I know this is old, but did you resolve this error? And if so, do you remember the solution? I’ve got the same problem.

      And Jaap, if you have any further insights, they would be most welcomed as well. How do I check what you’re suggesting in your comment?


  3. Hi Jaap. I have a site with one exchange 2010 with 200 approx users, we are going to migrate to 365 in the hybrid scenario. How do we keep an exchange server at the end. I dont want to keep the 2010 server as it is getting old. Can I add another server for management? Also wondering if you are putting part 3 up 🙂


    1. Hi, after moving all mailboxes you can upgrade your Exchange 2010 server to Exchange 2016. Install the new server and configure it accordingly, should not be a big deal since there are no mailboxes on it. Once configured you can download and run the HCW on Exchange 2016 and you’re good to go.


  4. Hi Sir,
    Do you have any migration document for migratiing exchange 2010 dag to office 365.please advice me on this query.
    I am learning migration of exchange.
    kind regards


    1. Hello Joseph,
      I’m sorry, I don’t have this available. The only thing I have is my blog post. For learning I propose to build a lab environment with a trial tenant in Office 365


  5. Hi, very nice guide!
    I have some trouble understanding WHY we need an onprem exchange if all the mailboxes are moved to o365?
    Is it possible to just move the mailboxes? We plan to keep our DC(This is connected to azure with aadconnect)

    I have tested this setup and in “” I can manage the recipients mailboxes, but is this because the onprem exchange is stil connected?


      1. Hi
        If you have directory synchronization in place then you have to manage users and mailboxes on-premises. You cannot edit mailbox properties in Exchange Online in this scenario (well, for most properties this is). All changes are made in Active Directory and Exchange on-premises, and these changes are replicated to Exchange Online.
        In the article you mentioned here, the Azure AD Connect is removed, and the accounts in Office 365 are changed to ‘cloud identities’ which are fully managed in the cloud, and not in your on-premises Active Directory. In this scenario, there’s no connection between Active Directory and Office 365 anymore. Does this help?


  6. Hello,

    Echoing other posts here, very helpful guide.

    Although a bit late, but we’re finally making the jump to Microsoft 365 from Exchange 2010. I would like to follow up on Martin’s post about running Azure AD Connectt with a slight twist.

    We plan on opting for the Cutover migration path, removing the Exchange 2010 post a successful migration, but also plan (and need to) on retaining our on-prem DCs.

    As of June 2020, is this a supported configuration?

    If so, would this mean we would need to have Azure AD Connect running on of one our on-prem servers?

    If not, what are my options for an on-prem DCs and AD, but NO on-prem Exchange Server configuration?

    Any information would be greatly appreciated.


    1. Hi Pete,

      Why do you think this is a supported configuration as of June 2020? At this moment I’m not aware of any change in supportability, but it is always possible that I missed some information.
      You are not the only one on this path, I am very busy at the moment with customers moving away from Exchange 2010, but to Exchange 2016 and Exchange Online, or both.
      But at this moment an Azure AD Connect configuration without an on-premises Exchange server is still not supported, you need this server for management purposes (I also see customers rely on SMTP relay functionality of this Exchange server). You can work without an Exchange server, but then you need something on-premises to manage your recipients. This is possible with ADSIEdit or a 3rd party solution, but still not supported.
      I have written three other blogposts about this:

      Hope this helps, and if I missed something please let me know.


      1. Thanks for the reply.

        I guess what led me to think that opting for a “Cutover” migration while retaining the on-prem AD functionality is possible is because I kept finding documentations that made no mention of requiring an on-prem Exchange Server. In other words some sort of documentation or guide that states “cutover migration” requires “cloud only identity model”. I was being hopeful.

        It seems that even the official Microsoft docs makes no mention of an on-prem Exchange Server requirement for the Hybrid Identity model.

        For example I found these:
        View at

        I do have one follow-up regarding your other (very informative) blog posts about this issue:

        Toward the end of the posts, it mentions… “to change the primary Email address for user BWesselius it’s a matter of adding the Email address to the mail property in Active Directory users and computers and wait for synchronization to happen (or force directory synchronization)”

        Does this imply that if we run force the directory synchronization every time we make changes on the on-prem AD (since we only have about 60 mailboxes to manage) that this still might be a workable solution?

        Thanks again for your assist.


      2. Hi,
        The Exchange server is tied to the Azure AD Connect, that’s the problem.
        You can run this without an Exchange server and the Email attribute in AD is just an example. You can force directory synchronization or just wait for 20 minutes or so, but it will work. it’s not supported, but it will work, no problem


Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s