Recently I have been working with a global charitable organisation that has offices throughout the globe and thought it would be a good idea to share some of the challenges I have faced getting them to Office 365.
Global charitable organisations often wish to use a single Office 365 tenant to be able to collaborate more effectively and commonly have their own infrastructure hosted in regional offices. Getting these organisation to Office 365 can bring about some challenges for the organisation:
Multiple Active Directory forests:
The organisation has two Active Directory forests. The first challenge was getting both the Active Directory Identities synchronised to Office 365.
To provision multiple Active Directory forests identities into a single Office 365, Azure AD Connect will be used however, you cannot use multiple Azure AD Connect servers to synchronise each forests identities to Office 365. So how do we mitigate this when you can only use a single Azure AD Connect server? Here you have two choices:
- Provision Azure AD Connect in one forest and create Active Directory forest trusts to the other forests you need to synchronise to Office 365. Using this method requires VPN connections between the forests and no overlapping IP ranges. Azure AD Connect will be configured to synchronise each forests user identities, via the forest trusts, to Office 365.
- Provision a cloud-based Infrastructure as a Service (IaaS) such as Microsoft Azure and host Domain Controllers for each organisation along with the Azure AD Connect server. Using this method does not require Active Directory forest trusts between the organisations however, it does require a VPN circuit to the cloud-based IaaS from each organisation and DNS forwarding rules to be setup for the domains. Domain Controllers and Azure AD Connect are provisioned into the IaaS service and Azure AD Connect is configured to synchronise the forests user identities to Office 365.
We chose to the cloud-based infrastructure method with Azure IaaS in our case as the organisation did not wish to setup VPN connections and Active Directory forest trusts between the organisations. We setup the Azure IaaS service, terminated the VPNs between Azure and the organisations endpoints and proceeded to provision the Active Directory Domain Controllers. Once we had setup the Domain Controllers, we then setup the DNS forwarding between the forests so the Azure AD Connect server knows how to contact the Domain Controllers.
Cloud Identity Authentication Methods:
Choosing a Cloud Identity authentication method also brings some challenges to the organisation. Microsoft currently support a number of authentication methods to Office 365:
- Synchronised Cloud Identity – The identities are synchronised to Office 365 however, the user authenticates to Office 365 using a separate password to that of their domain password. This can cause confusion to the user base as users must remember multiple passwords.
Synchronised Cloud Identity with Password Hash Synchronisation – The identities and hashed domain passwords are synchronised to Office 365. This method allow the user to use a single password however, some organisations prefer not to synchronise their passwords to Office 365 for security reasons. - Synchronised Cloud Identity using Pass-through Authentication – The identities are synchronised to Office 365 and the authentication request to Office 365 is passed to the Azure AD Connect server to authenticate against the Active Directory. This method can mitigate the security risk to the organisation by synchronising the hashed domain passwords, although does not provide the organisation with a seamless sign-on method to Office 365.
- Synchronised Cloud Identity using Pass-through Authentication and Seamless Sign-On – The identities are synchronised to Office 365 and the authentication request to Office 365 is passed to the Azure AD Connect server to authenticate against the Active Directory. Domain-joined clients are configured to seamlessly sign-on to Office 365. Again, this method can mitigate the security risk to the organisation by synchronising the hashed domain passwords and provide a seamless sign-on to Office 365.
- Federated Cloud Identity – The identities are synchronised to Office 365 and the UPN domain is federated with Active Directory Federation Services (AD FS). This method requires AD FS infrastructure to be deployed and if using an Active Directory forest trusts it can be accomplished using a single AD FS instance however, for organisations that do not wish to create Active Directory forest trusts, AD FS instances must be deployed for each organisation. By using AD FS the organisation can also control the access to Office 365.
We chose to use a synchronised cloud identity with password hash synchronisation as the organisations wished to use an Exchange Hybrid migration method and directory synchronisation is required for this type of migration. Although this could be changed later to Pass-Through authentication or a federated Identity. We setup the Azure AD Connect server in Azure to synchronised both forests, using password synchronisation to Azure AD. Now we have the Office 365 identities provisioned.
Migrating Mailboxes to Exchange Online:
Once we’d got the identities and authentication setup with Office 365, another challenge presented itself. How do we migrate mailboxes to Office 365 for the organisations? Well, that’s quite easy:
- Microsoft Exchange 2003 and greater Organisations – You can use cutover migration method to preform mailbox migrations to Office 365. This method supports up to 2000 mailbox migrations and requires Outlook Anywhere to be presented to the internet and a third-party SSL certificate on the service, but does not allow for a rich coexistence experience. All the organisation mailboxes are migrated at once to Exchange Online. If Directory Synchronisation is enabled in the Office 365 tenant it must be turned off for this method.
- Microsoft Exchange 2003 and 2007 Organisations – You can use a staged migration method to preform mailbox migrations to Office 365. This method requires Outlook Anywhere to be presented to the internet and a third-party SSL certificate on the service, but does not allow for a rich coexistence experience. All the organisation mailboxes are migrated in batches using CSV files to Exchange Online. This method requires directory synchronisation.
- Microsoft Exchange 2010 SP3 and greater Organisations – You can hybridise the multiple Exchange organisations to Exchange Online and preform mailbox migrations to Office 365. This method is supported by Microsoft and allows organisations to have a rich-coexistence between Exchange and Exchange Online however, the organisation must be using Exchange 2010 SP3 or later.
- Other Mail Providers – You can use IMAP to migrate the mailbox data from non-Exchange systems to Office 365. This method is supported by Microsoft however, some additional considerations need to be undertaken as the method will only migrate mail items not calendar or notes. The calendar and notes can be migrated using a PST import and export procedure.
Here we chose an multi-Exchange Hybrid for the organisations which had Exchange, using Exchange 2010 SP3 and Exchange 2016. After we had presented Exchange Web Services and Autodiscover using an SSL certificates which covers the namespaces, we presented both services to the internet. Running the Hybrid Configuration Wizard on each Exchange organisation sets up the Exchange Hybrid between each organisation and Exchange Online creating Organisation Relationships and secure mail transport. We also opted to use the non-centralised transport option using Exchange Online Protection to send and receive messages to the internet. MX records for the organisations were changed to point to Exchange Online Protection to complete the multi-Exchange Hybrid setup.
Once we had setup the multi-Exchange Hybrid, migrating the mailboxes to Exchange Online was rather easy. We identified the delegate permissions and migrated both the user and delegate mailboxes in the same batch to avoid any issues with permissions across the organisations.
Now came the harder part of migrating the other regional offices who use Gmail as their mail provider.
We created the Active Directory users accounts and using the Enable-RemoteMailbox cmdlet created the Exchange Online Target mailboxes. Migrating to Exchange Online from Gmail involves an IMAP migration method. We removed the MFA and security options from the Gmail service, as this can get in the way of the migrations, and setup IMAP migration batches with the email address and passwords to the Gmail mailboxes and migrated the mailboxes. In the midst of migrating the mailboxes, the regional IT representative deployed Office Pro Plus to all the clients, so they were ready to use the migrated mailbox. The setup can be summarised in the image below:
Licensing the mailboxes in Office 365:Once we had accomplished the mailbox migrations, the next challenge was getting the licenses added. You only have 30 days from the date the migrated mailbox was migrated before the data is removed from Exchange Online. It can also affect client access to the migrated mailboxes. We chose to license the mailboxes as soon as they were migrated to avoid any complications. To license the mailboxes., we ran an Office 365 PowerShell script to look for the migrated mailboxes and add the E3 licenses.
Administering the Office 365 Tenant:
Another challenge the organisation faced was who will administer the Office 365 tenant? Well, that’s quite easy! Both organisations can administer the Office 365 tenant. Global and Billing administrators were added for both organisations and Exchange Online Roles Based Access Controls were used to add the already created Active Directory security groups to the Admin Roles in Exchange Online, allowing both organisations to administer Office 365 and Exchange Online.
Following the mailbox migrations, the organisations deployed Skype for Business, SharePoint Online and OneDrive for Business to allow the organisations to collaborate.
