As we work through the effects of COVID-19, F1 Solutions would like to assure you that our current professional and hosting services are and will continue to operate. As we are assisting many of our clients with rapidly establishing remote working arrangements, we are experiencing higher than usual call volumes on our support phone lines. We would like to thank you for your patience and understanding during this challenging and critical time.
15 Jun 2017

Part 1 Recap

In our first part, we completed the following components:

  • Gathered Project requirements.
  • Assessed Pre-requisites.
  • Assessed Environment variables.
  • Installed ADFS and web application proxies.
  • Verified/setup exchange and DNS requirements.

 Find Part 1 here


Part 2 Overview

  • Installing Azure Active Directory Connect
  • Configuring Exchange Hybrid Configuration
  • Migrating our User Base


Azure Active Directory Connect

We needed to ensure that the following prerequisites had been met to install Azure Active Directory Connect (AADC). The prerequistes were:

  • Exchange is up to date.
  • ADFS and WAP are installed and confirmed to be working.
  • Office 365 tenant is configured and routing mail through EOP to on premise configuration.
  • A valid license is available.

Before running an Active Directory (AD) synchronisation we took the opportunity to clean up our existing AD. This entailed running a few scripts to gather unused accounts, computers and empty security groups. The following scripts were used to assist with this task:

Get-ADComputer -Filter * -Properties DNSHostName,LastLogonDate | Where-Object {$_.LastLogonDate -le (Get-Date).AddDays(-180)} | Select-Object DNSHostName,LastLogonDate,Distinguishedname | export-csv C:\temp\ADUser_LastLogon_180.csv

Get-ADUser -Filter * -Properties name,LastLogonDate | Where-Object {$_.LastLogonDate -le (Get-Date).AddDays(-180)} | Select-Object Name,LastLogonDate,Distinguishedname | export-csv C:\temp\ADUser_LastLogon_180.csv

Get-ADGroup -Filter {GroupCategory -eq 'Security'} | ?{@(Get-ADGroupMember $_).Length -eq 0} | select-object Name,Distinguishedname | export-csv c:\temp\ADGroups_Empty.csv

Get-ADGroup -Filter {GroupCategory -eq 'Security'} | Select-Object Name,Distinguishedname | Export-csv c:\temp\ADGroups_All.csv

After housekeeping was performed and all unnecessary objects removed we executed the idfix tool from Microsoft to confirm all our accounts in AD were ready to be synchronised with Azure. This tool goes through your AD attributes and confirms there are no issues with duplicate SMTP address or incompatible symbols, etc.

After this tool was executed and it was confirmed everything was in good shape, we were now ready to install AADC.

The AADC installation went very smoothly, although we identified two configurational issues during the process. These were:

  • DNS resolution. The Outside ADFS address could not be discovered and resolved. We simply granted the Sync Server DNS resolutions through the firewall.
  • Access over port 443 from the server to Office 365 domain was not allowed. Once again, we granted access through the firewall.

For more information on required ports please read the following.

Once the initial synchronization was completed, we confirmed that the AD object selected to sync during the wizard appeared in their respective Office 365 pages.

At this point if we attempted to sign into the Office 365 portal to confirm that we were re-directed to the Federation page for our company when our email address was detected. We then could confirm it was working by loging on with an on premise user and password, ensuring that we were successfully authorised into the portal.


Exchange Hybrid Configuration

The final step of the implementation was to configure the connection between the on premise Exchange and Exchange Online. This created the connectors and relationship so we could migrate content to and from both endpoints. As we were already running our mail through Exchange Online Protection, some of the pre-requisites were already met. Refer back to Exchange and DNS configuration for some of the prerequisites.

We accessed the ECP console for the on premise Exchange and launched the hybrid configuration wizard. This downloaded the hybrid configuration wizard which takes you through the various requirements. It was necessary to ensure that our security settings allowed the downloading of this tool, especially as it was running on the Exchange server. In this step disabling enhanced security may be necessary.

One of the issues we ran into when the tool attempted to enable federation trust was that it would keep failing to make the connection. The resolution was to enable access for the Exchange server out on port 443.

The following command was used to confirm that it was working correctly:



Final Steps

Now that all the components were in place, we verified the Accounts were syncing and we verified our ability to create a mailbox on premise using the 'Office 365 mailbox' option. It was then time to point mail flow at Office 365 using EOP. EOP is Exchange Online Protection and is included in all Office 365 products. To do this we needed to create an MX record in our authorative DNS zone pointing to the EOP address.

  • MX Record,

We checked the record required by loging into Office 365 admin center with a global administrator enabled account and checking the setting > domains tab. The records required for the different products were available here.

Some other minor steps that were required to be performed were:

  • Assign licenses to our users.
  • Setup admin access to our technicians (note: avoid giving all admin staff 'Global Administrator' access).
  • Test mail flow to and from internal and external accounts, ensuring mail is routing through EOP back to on premise.


Phase 3 - Plan and execute your move



OK, now it was time to plan the migration of our users from on premise to Office 365. Even though we had run idfix and synced our user accounts, we still encountered some issues. Some of the issues we ran into were pretty straight forward whilst others were rather complicated.

An example was ”additional or mismatched SMTP address”. This meant that there should have been a primary SMTP address which needed to match the endpoint username and a corresponding '' SMTP address.

An example of a mismatch is if someone created and account John.Smith and then created a mail account There is no corresponding John.Smith in the mail account to match the Office 365 endpoint for the synced AD account.

Another thing we encountered was accounts with email aliases for another domain, if the domain is not registered to your Office 365 tenant then when the account is attempting to be moved you will receive an error about the domain not being authorized.

We used the following approach to move accounts:

  • Moved User accounts in batches (team based)
    This alleviated the pressure of too many people needing assistance or having issues
  • Moved Shared mailboxes
    Completed out of hours to endure that the end user did not notice any major changes, name changes a little.
  • Moved public folders
    Acknowledged to be rather complicated and not to be taken lightly.
  • Moved disabled users and converted to shared mailbox.
    Moving the disabled users basically just allowed us to remove their data from our internal storage and provide anyone who needs it access to their mailbox as a shared mailbox.



Once the plan was finalised, the first step to move any mail accounts was to create a migration endpoint. We connected the Exchange admin console in Office 365 and access migration endpoints from Recipients > Migrations. The Endpoint was connected to our MRS proxy address e.g.

Once the endpoint was created we performed a test migration. For this we selected a single technician’s mailbox in the migration wizard which was available in Recipients > Migrations. It was selected to synchronise automatically and we waited for it to complete succesfully.

Note, performing the migration will stop mail flow to the end user for about 30 minutes. Once the mailbox is marked as completed the end user will need to do the following.

  • Restart Desktop client
  • Delete any mobile 'Active Sync' Accounts
  • Add new account to mobile devices
  • Update Skype client with password to mailbox

As we run Skype for Business on Premise, the Skype mobile app requested a password for the exchange account to be able to reconnect to the new endpoint mailbox.

Mailboxes will take a little while to synchronize again to the localdecices, so end users may raise issues in relation to a slow inbox for the first little while.

When a disabled user is moved and mailbox is converted to a shared mailbox it does take a while for the mailbox to allow you access. For example we converted a shared mailbox, gave permissions and then restarted outlook. It took approximately 30 minutes before the mailbox was visibly present in Outlook client and then an additional few hours before we could even browse the mailbox.

Public folder migration is probably one of the most finicky things to move. Follow the link below to assist

Even though we followed this guide pretty thoroughly, we still ran into some issues. Most of the mail enabled public folder did not have a corresponding address so we manually added all these to the folders. Additionally there appeared to be some legacy configuration from a previous upgrade 2007/2010 > 2013 upgrade that was still left over, mostly to do with some orphaned folders. The error we encountered was something like there are 7 mail public folder(s) in Active Directory that were not linked to any public folder during migration. To resolve the issue we ran this against our Exchange server

Get-MailPublicFolder | Set-MailPublicFolder -IgnoreMissingFolderLink $true



As we have an onsite multifunction device (printer) that performs scan to mail we could leave it as is and route mail though the on premise Exchange, however we decided to change the setting to direct send to our Office 365 account. There were 3 possible options to achieve this:

  • SMTP Client submission
    Authenticate with a registered licensed account in O365
  • Direct Send
    Send from an authorized IP using an unregistered account
  • SMTP Relay
    Basically option 2 with external email relay

We used option 2 as we don't send email externally from our printer. As we already have connectors set up allowing all of our IP ranges into the Office 365 EOP range, it was as simple as change the SMTP connection.

And that’s it! We successfully completed our migration to Office 365 using a hybrid setup and ADFS. 

Our team have been performing incredibly successful migrations for some of our clients as well with an excellent reception. Contact us to see how we can assist with your organisation’s migration to one of the world's most popular business tools.


What's Next?

Migrating SharePoint will be our next project.

Subscribe to our newsletter here to keep up to date and get new blog posts like this straight to your mailbox.

Subscribe for more articles like this

* indicates required