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

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: https://www.microsoft.com/en-us/download/details.aspx?id=36832

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 Inframan.nl 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 J.Brown@inframan.nl and the corresponding UPN will be J.Brown@inframan.nl 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 (https://www.microsoft.com/en-us/download/details.aspx?id=47594) 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>.onmicrosoft.com -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 inframan.nl 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.