Office 365 Migration Part One

The goal, the brief, the mission

The objective was simple, move our current highly available Exchange services to Office 365 Exchange online and provide access for staff to additional applications such as Microsoft Teams. This required the use of our E3 licensing that is made available from being a Microsoft Gold Partner. Whilst using Microsoft Teams was a significant motivation behind the switch, we also were able to reduce some of our onsite infrastructure with a longer term goal of moving other services e.g., SharePoint, Skype for Business, etc.

Phase 1 – Discovery & prerequisites

Discovery

The first part to any Office 365 migration is understanding the client requirements, their current pain points, the objectives and success criteria. In our case the immediate objective was to migrate to Exchange Online with Active Directory Federation Services (ADFS) so we could also provide Microsoft Teams access to the company. As Microsoft Teams is a cloud based service only, i.e. there is no on premise installation provided by Microsoft, we needed to provide a federated identity platform so that users could use a single logon to access Microsoft Teams and other internally hosted systems.

Additional components such as SharePoint, Skype for Business, Yammer etc. could be migrated or considered later after the migration was completed. As we are an IT company with collaboration being a very important part to our creativity solutions and problem-solving and our workforce is becoming more mobile and distributed, Microsoft Teams provided a strong story to assist with enabling our staff to be more productive, centralising information, whilst maintaining integration with our existing systems and toolsets.

Our current Exchange deployment consists of 2 Exchange servers operating in a highly available configuration. As we have less than 100 staff in our organisation, a cutover migration would be the preferred method. However due to security concerns and future business requirements we are implementing ADFS at the same time. As a result of utilizing ADFS, the deployment options for Exchange are different and as a result we implemented a hybrid configuration, i.e. a single Exchange server onsite for management whilst the core email services are being provided in the cloud.

ADFS provided us security by authenticating users against our own Active directory located on premise.

Prerequisites

The various prerequisites for our deployment were as follows:

• Office 365 Tenant and domain registered to this tenant
• Exchange running the latest or n-1 cumulative updates
• Active Directory prepped using tool such as idFix to ensure there are no conflicts in AD attributes
• Clean up Active Directory, e.g. disable users, computer and groups
• Setup ADFS Farm in the internal domain and setup web proxy farm in the DMZ

This can be done as part of the Azure AD Connect phase but we will be running AS FS 2016 and decided to install these components before hand

Before Datacenters were available in Australia, any tenant that was created with an Australian address would be created in the Asia/Pacific region and thus data would be stored in these regions. Unless you managed to opt-in to a data migration to the Australian Datacenters which was available only for 2 month during 3rd quarter 2016 (which was scheduled to take 12 months to complete), you cannot move your data from the Asia/Pacific region. This posed an issue as our security requirements specify our data needs to be located in Australia (Data Sovereignty).

We had lengthy discussions with Microsoft to see if we could get our account migrated however this was not possible. In the end we created a new tenant on the Australian datacenters and migrated the domain to the newly created tenant. Luckily we have not used our previously configured tenant for anything other than Exchange Online Protection (EOP) a few test accounts with Microsoft Teams and only stored a minimal amount of data, i.e. 30 MB. Had we utilsied our previous tenant on the Asia/Pacific region the migration to the Australian based tenant would have been significant.

As our existing EOP subscription was set up with our existing tenant we needed to perform the additional following steps:

• Replicate mail flow rules and settings to the new tenant
• Setup the exchange connectors on the new tenant
• Migrate the 100 E3 Licenses to the new tenant
• Remove Domain from existing tenant and register with new tenant
• Confirm mail flow

Phase 2 – Implementation

Active Directory Federated Services & Web Application Proxy

https://social.technet.microsoft.com/wiki/contents/articles/34162.ad-fs-4-0-discover-setup-and-publish-application-part1.aspx

We decided to co-locate our ADFS servers with our domain controllers. Prior to ADFS 3.0 this was not an option due to the requirement of IIS services. Now however this is not the case and it made more sense to co-locate these services in an organisation of our size. The Web Application Proxys were installed in the demilitarised zone (DMZ) and load balancing to the servers would be managed via DNS round robin.

ADFS 4.0 was installed on two Windows Server 2016 domain controllers in a farm configuration using an internally signed Certificate. We used a Windows Internal Database (WID) as the additional requirements of a SQL instance and database did not provide many benefits in our configuration. Some things to keep in mind is that there are limitations of using a WID which are as follows:

• Less than 100 RP Trusts
• 1-30 ADFS Nodes
• No SAML Artifact Resolution
• No Token replay detection

While WID replicates changes every 5 minutes from the primary server to the secondary servers you need to keep in mind also that if the primary ADFS server is out of action for any reason the secondary ADFS servers will not automatically make it’s WID the primary database and you will only be able to service existing logons that the secondary servers know about. You can manually set the primary WID by doing the following on the secondary server should you need to.

Set-ADFSSyncProperties -Role PrimaryComputer

When the primary comes back up you should either set back the new primary to the secondary or switch the old primary to the new secondary.

Set-ADFSSyncProperties -Role SecondaryComputer -PrimaryComputerName <internal_FQDN_of_the_new_Primary_Server>

We now had installed the ADFS server and started to test access to ADFS signon page. This proved to be an issue as we kept getting a message ‘An error occurred’ whenever we attempted to access https://ADFS.contoso.com/ADFS/ls/IdpInitiatedSignon. After some digging around we eventually found out that in ADFS 4.0 the sign on page is disabled by default. Executing the below command resolved the issue:

Set-ADFSProperties -EnableIdPInitiatedSignonPage $true

Two Web Application Proxies were also now installed in the DMZ using a wild card certificate for the domain. Communication had been opened between the Application proxy and ADFS servers on port 443. We setup a test Replying Party (RP) Trust to access the https://ADFS.contoso.com/ADFS/ls/IdpInitiatedSignon page externally. After successfully testing we confirmed that everything was running correctly and we could now move on to the Exchange and DNS configuration.

Exchange/DNS configuration

You can take a lot of Exchange configuration for granted as most functioning Exchange environments will meet all the prerequisites. That said, the following prerequisites are required:

• Update all Exchange servers to a minimum of n-1 CU e.g. latest CU is 16, minimum CU required is 15.
• Valid publically signed certificate assigned to the SMTP and IIS services.
• SPF record, TXT record, v=SPF1 include:spf.protection.outlook.com
• Auto discover record pointing to the external CAS server or Firewall IP.
• CNAME point at SMTP e.g. mail.contoso.com
• A record point at CAS or Firewall IP ~all

Before commencing the configuration, verify your Exchange web services are working correctly. This can be done using the following commands.

The Fully Qualified Domain Name (FQDN) listening in all the above commands should match your expected external URL e.g. Finally ensure the Mailbox Replication Service (proxy is enabled as this will be required to create an endpoint connection from Office 365 to the Exchange on premise installation.

Whilst our deployment showed the MRS proxy was enabled we were unable to create the endpoint connection during migrations. We ended up executing the following command to resolve the issue. Connect to Exchange on Premise PowerShell

Execute this command on all Exchange servers. Afterwards you should be able to connect. You can then test the move with the below command.

Test-MigrationServerAvailability -ExchangeRemoteMove -RemoteServer mail.contoso.com -Credentials(Get-Credential)

Part 2 of the migration focuses on the Azure Active Directory Connect and Exchange Hybrid Configuration and the actual migration. Click here to continue reading.