There are many articles on the web about how to create a hybrid environment where Exchange 2016 is connected to Office 365. Well, that's fine, but if you're running Exchange 2016, you'd rather NOT switch to Office 365 anytime soon I think. If you're running Exchange 2010, you'll probably be moving to Office 365 (soon), but there aren't many articles out there about moving from Exchange 2010 to Office 365. And many of the articles available don't have the right approach, and I'm afraid it will lead to that that you (the customer) have to pay your system integrator far too much money.
In this article I will try to outline the recommended approach for moving from Exchange 2010 to Office 365 in a hybrid scenario. With Azure AD Connect for synchronization purposes. Cliffhanger: I will not 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 trouble. There are internal Outlook clients using Outlook 2010 and later and external clients using Outlook Anywhere. There are also mobile clients that use 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.
In the internal network there are also applications and multifunction devices that route 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 Active Directory (single forest, single domain) FQDN is Inframan.local. Therefore users log in with Inframan\J.Brown, the Inframan organization has never used the UPN and this is set to the default which is J.Brown@Inframan.local.
For message hygiene, an Exchange 2010 Edge Transport server is used with a SpamHaus Realtime Blocklist (RBL), recipient filtering is configured, and some custom words are used in the Edge Transport server's content filtering module. And yes, this has worked for years.
Prepare for Office 365 and Hybrid Exchange
Inframan has around 500 mailboxes and estimates 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 local Active Directory, an Exchange 2010 hybrid scenario is implemented.
note. Usernames and passwords are synced to Office 365 and that's enough for now. Single sign-on via ADFS (Active Directory Federation Services) is not currently implemented in the Inframan environment.
Directory synchronization
Azure AD Connect is used to sync user accounts and passwords from on-premises Active Directory to Azure Active Directory, which is the underlying directory for Office 365 and Exchange Online.
Run IdFix
To ensure your on-premises Active Directory is ready for Azure AD sync, Microsoft has a tool called IdFix that analyzes your Active Directory for inconsistencies or issues that could cause problems with Azure Active Directory. A non-routable UPN suffix, double entries or non-routable e-mail addresses are known in this context. 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 problems in your Active Directory on the console, but you can also export it to a CSV file to analyze it in Microsoft Excel, for example.
Figure 2. Active Directory issues 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 corrected, but also the UPN is misconfigured and there are some email addresses with a .local TLD.
A requirement for Azure AD sync is that the User Principal Name or UPN must have a routable domain name as the UPN suffix. Therefore Inframan.local cannot be used and the domain name Inframan.nl must be used. It is strongly recommended to use the same name for the user's primary SMTP address and UPN. In this scenario, the user's email address is J.Brown@inframan.nl and the corresponding UPN is also J.Brown@inframan.nl.
Figure 4. Adding a routable UPN suffix with Active Directory domains and trusts
Once added, you can use Active Directory Users and Computers to quickly change the UPN suffix for users. Navigate to the correct OU, 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 correct UPN suffix.
Figure 5. Select the correct UPN suffix for the users
Another problem in our environment was that all users have an @inframan.local SMTP address. This is caused by the default email address policy still containing an @inframan.local entry, so all created users still received the @inframan.local email address.
The easiest way to remove these extra email addresses is to use a simple PowerShell script, something like this:
$Mailboxes = Get-Mailbox -ResultSize Unlimited -OrganizationalUnit AccountsForEach($Mailbox in $Mailboxes) { $Mailbox.EmailAddresses | ?{$_.AddressString -like '*@inframan.local'} | %{Set-Mailbox $Mailbox -EmailAddresses @{remove=$_} }}This creates an array of all mailboxes in the OU=Accounts OU and removes any email address that contains the @inframan.local suffix.
Running the IdFix tool again only two other issues remain, two distribution groups still contain an @inframan.local email address, but this can be resolved manually using the EAC.
Figure 6. There are only two other problems in our Inframan environment
Once these last two issues are fixed, our on-premises Active Directory can be easily connected to Azure Active Directory.
Install and configure Azure AD Connect
Microsoft Azure AD Connect is the tool used to connect and synchronize your on-premises Active Directory with Azure AD, the underlying directory for Office 365.
Azure AD Connect uses service accounts in both on-premises Active Directory and Azure Active Directory. In on-premises Active Directory, the service accounts must be a member of the Enterprise Admins security group, in Azure Active Directory, the service accounts must be a global administrator account.
note. There is no need to assign an Office 365 license to the service account.
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, which I want to avoid.
Install a fresh Windows 2012 R2 server, install .NET Framework 4.5 and install any available patches. After downloading Azure AD Connect software from 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 must be enabled for directory synchronization. Sign in to your tenant using tenant admin credentials and click the Admin tile.
Click the user icon in the left navigation menu and select Directory Sync from the More drop-down menu.
Figure 7. Select Directory Sync from the drop down menu
The directory synchronization wizard will start and you can just follow the wizard. During the deployment readiness check, you can launch the Azure AD Connect setup application and the wizard will guide you through the Azure AD Connect setup.
Figure 8. Use a service account to connect to Azure Active Directory.
Tip: The service account password in Azure Active Directory expires every 90 days without notifying you as an administrator. Use theSet-MsolUser -UserPrincipalName <service account>@<tenant>.onmicrosoft.com -PasswordNeverExpires $trueCommand in Azure Active Directory PowerShell to set password to never expire. Check theManage users in Office 365 with PowerShellarticle for more details.
Figure 9. The domain inframan.nl is verified, the domain inframan.local is not used (and cannot be added).
Figure 10. Be sure to check that outExchange hybrid deploymentcheck box.
With Azure AD Connect installed, you can continue with the directory synchronization wizard. ClickEndwhen everything is set up.
Figure 11. Click Finish to close the Deployment Readiness Tool.
Azure AD Connect starts automatically and performs a full synchronization. Checking the Office 365 admin center shows the users from your on-premises Active Directory. Please note that they are not licensed at this time.
Figure 12. Users from on-premises Active Directory 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 who need a license, and select Edit Product Licenses in the Actions pane to assign the appropriate license.
At this point, your users can sign in to the Office 365 portal and review all available services. Is there a mailbox in Office 365? No, not yet. All mailboxes in the on-premises Exchange 2010 environment have a corresponding mail-enabled user in Office 365. You can easily verify this by logging into the Exchange admin center:
Figure 13. The on-premises mailboxes appear in Office 365 as mail-enabled users
The next step is to implement the hybrid configuration with Exchange 2010 and Office 365. I will go into that in my next blog post.