Hybrid Migration Nightmare!
SUMMARY: Two separate companies, sharing the same ageing server, Active Directory and network infrastructure, migrated off onto their own separate Microsoft 365 tenants amidst a pandemic!
So I’m not a blogger but I thought I would post this onto my website in case it helps anybody else out as I scoured the net for help and advice and could find nobody else struggling with a similar situation.
We are two separate companies sharing the same building and network infrastructure (server, active directory, domain controller, Exchange server, wifi network, rooms, ports, cabling etc!). Long story. Let’s call us The-Charity and The-College. We are still sharing a building for a while (until The-College move buildings next year) but for various reasons now had a need to try to separate out our IT systems as much as possible and to also migrate us all off an ageing server which was on its last legs.
The server hosts virtual machines running Windows 2008 server and an Exchange 2010 server. For our emails we are both on this same Exchange 2010 server with our respective domain names The-Charity.co.uk and The-College.com. To further complicate matters our company rebranded a few years ago and our network domain still uses our old name, let’s call it Old-Charity which also propagates as Old-Charity.co.uk when joining PCs to our company domain. This old domain name still exists somewhere in the ghosts of our systems too and occasionally plays havoc with our autodiscover. To even further complicate matters this old domain name is now owned by The-College who use it as their Google G-Suite account. All of this combined makes it REALLY confusing for new staff of The-College when trying to explain that the instructions for them to get onto PCs and check emails are:
Email address is: YourName@The-College.com
Server address is: mail.The-Charity.co.uk
Network domain is: Old-Charity.co.uk
G-Suite account is: YourName@Old-Charity.co.uk
But that’s an issue for another day! Anyway, here are the steps I took in case they help anyone else out. I’m sure there was probably a much more efficient way to do this but I ran into so many unexplained problems along the way (I can only remember half of them and may add to this post as I remember more) and this is what worked for me so if you’re interested then read on!
1. SETUP OFFICE 365 (MICROSOFT 365) TENANT AND VERIFY THE DOMAIN NAME
I started by creating two separate free Office 365 accounts (now called Microsoft 365 as of April 2020), we would then later purchase whichever individual licences we required. One was a Microsoft Nonprofit Business Basic account (for The-Charity) and the other an Office 365 A1 account (for The-College).
NOTE: The nonprofit Microsoft 365 account I started for The-Charity is free for nonprofits of up to 300 users (you can also go for the E1 version if you are a larger nonprofit and need more users) and gives web versions of Microsoft Word, Excel, PowerPoint and Outlook (downloadable desktop app versions of Word, Excel, PowerPoint and Outlook are available by upgrading users from Business Basic to Business Standard for around £2.30 per user per month). Each user also gets a 1TB OneDrive storage and a 50GB inbox among a host of other things. The A1 education account is much the same although I have since discovered offers additional benefits for education (more on this later). The upgrade to A3 for desktop versions of the Office suite was slightly more (£2.85 per user per month) but checking now it seems that the desktop versions of apps seem to be available to the free A1 account. I’m not sure whether this is temporary due to the current crisis and so many schools and colleges trying to educate remotely so can’t say whether this will always be the case.
For both accounts there was a slight delay as each company needed to be verified (The-Charity as a nonprofit organisation and The-College as an educational establishment). This didn’t take long though and was achieved by entering the relevant details when setting up the accounts online (websites, DfE number, charity number, company number, VAT number etc.). Once an MS365 account is verified you also need to add and verify your domain name (or names) as a custom domain which can be done through the online setup wizard inside the Microsoft 365 account* (once logged in as an account administrator). This will involve adding some basic DNS records wherever you purchased and host your companies domain name. It’s a fairly simple process and the wizard walks you through it quite well with step-by-step examples for the bigger hosting companies.
*Eventually you will also need to point your domains DNS MX records towards MS365 which there is also support for in the online wizard but for now if you are still using an on-premise Exchange server then you need to leave this as it is!
So now the online accounts were ready to go it was time to migrate over some users. To the server!

2. PREPARE ACTIVE DIRECTORY FOR SYNC AND RUN IDFIX
Before starting to migrate there was a bit of cleaning up to do in our Active Directory. All users and groups were currently just in the one Organisational Unit called users so I started by creating two new OU’s, one called The_Charity and the other called The_College. I then moved across the relevant users into their respective OU (be aware that if you have policies setup on OUs then these may change when you move a user to a different OU – this wasn’t an issue for me). I didn’t move any security groups used for shared drive access or other reasons and I also didn’t move the administrator account, I only moved those users that would eventually have an account on Microsoft 365. This way all the various groups, security groups, system accounts and other bits were left untouched in the default ‘users’ OU and I had two new clean Organisational Units ready to be synced to the cloud.
The next step was to download and run the IDFix Tool from Microsoft. This tool checks accounts in your Active Directory for any issues that might prevent them from being migrated and either fixes them for you or helps you fix them. Common errors it might pick up may be accounts having a .local or some other address as the logon UPN instead of using the domain. The tool seeks these out and fixes them for you! For example all users on our server were set to have the UPN of Old-Charity.co.uk (a throwback from our old server – see our domain name confusions above) so I had to change the UPN for all our users from Old-Charity.co.uk to The-Charity.co.uk (and similarly change the UPN’s in the other OU to The-College.co.uk).
Once Active Directory has been prepared and cleaned up you should be ready to sync it with Azure and Microsoft 365…
3. PERFORM AN ACTIVE DIRECTORY SYNC WITH AZURE
I wasn’t sure how to handle syncing both companies with their respective 365 tenants and maintaining a hybrid migration but the workaround I came up with was to install the Microsoft Azure Active Directory Connect ADSync tool (you can also find instructions here) onto both our Exchange server, as this also acts as a domain controller and also our main domain controller. First I installed AD Sync onto our Exchange server and customised the settings to sync only the ‘The_Charity’ OU with The-Charity’s Microsoft 365 tenant. Part of the installation process performs an initial sync before letting you customise the settings so it initially synced over everything and I then had to customise the settings and perform another sync. The client syncs automatically in timed intervals but if you want to force a sync rather than wait then you can open PowerShell and run the following command:
Start-ADSyncSyncCycle -PolicyType Delta
I then installed a second instance of AD Sync on the domain controller and set this to only sync the ‘The_College’ OU with The-College’s tenant.
4. PREPARE EXCHANGE FOR A HYBRID CONFIGURATION
(OR UPGRADE AFTER UPGRADE BEFORE EVEN ONE MIGRATION!)
For the migration to work your Exchange server needs to have Outlook Anywhere functioning. This was already configured on our server but can be turned on in the Exchange Management Console.
Next I installed Microsoft’s Hybrid Migration Wizard onto the Exchange server. But WAIT! I needed to first update the server as it turns out the hybrid migration requires the server software to be on Windows Server 2008 SP2 or above and also to be running Exchange Server 2010 SP3 or above. Back to the Microsoft website to download and install the required updates.
Finally I installed and ran the Hybrid Configuration Wizard available from Microsoft (a link to download it can also be found in your MS365 Admin Center in the Exchange Admin Center and under the hybrid tab). This wizard goes through the steps to configure the Exchange server for a hybrid migration.
On a side note, the wizard didn’t finish for me due to what I think I eventually tracked down as some autodiscover errors mentioned above. I think this was due to our unique setup with our domain names and shouldn’t affect most people. From what I’ve read the Hybrid Configuration Wizard is usually pretty simple and goes through without any problems if you have prepared the environment in advance. I might write another post about our autodiscover issues but there was way too much to cover here!
I then checked through some user accounts in Active Directory to make sure they had the relevant information added to them. For me the Hybrid Migration Wizard didn’t completely add all the required information into the user accounts I was going to migrate. I believe this was to do with the accounts in question not automatically getting their settings from server policies. Frustrating! But not a massive pain. So I also had to add the relevant MS365 created SMTP addresses (usually along the lines of domain.mail.onmicrosoft.com) into those accounts.
Once the server was configured and ready it was time to migrate a test user or two so now it was back to the cloud. Come fly with me!
5. MIGRATE!
I know, I know. I was way too excited by this point and so I just went ahead and migrated my own mailbox without testing any users first. Everything worked fine and I absolutely don’t recommend doing this yourself! I did however then create test users in both our on-premise environment and the MS365 tenant in order to see how they worked together so let’s just ignore this whole paragraph and pretend it never happened.
The next step was to create some test users with email accounts in our on-premise Active Directory and Exchange server and also in the Microsoft 365 tenant. I wanted to test how they interacted and migrated so I created a few test accounts (with names such as LocalUser, RemoteUser, RemoteMailbox but feel free to use your imagination as long as you remember what they were created for!) using various combinations of creating them on-premise and syncing, creating on-premise with an MS365 created mailbox, creating in MS365 tenant, migrating to the tenant, migrating back to on-premise etc. I wanted to make sure there were no issues once I started migrating actual users and also with emailing and sharing calendars.
To perform and actual sync you login to the MS365 tenant as an administrator and go to the Exchange Admin Center (found under Admin Centers in the main Microsoft 365 admin login). Once in the Exchange Admin Center you go to ‘Recipients’ and then ‘Migration’. Click on the three dots (not the + sign) and select ‘Migration Endpoints’. A popup window should appear where you can create a new migration endpoint. Just follow the onscreen instructions and once you have a new endpoint you can then click on the + sign and ‘Migrate to Exchange Online’.
Follow the onscreen instructions and select the users to migrate. The migration process took quite a long time for me so select users in small batches. It will ask you to choose the endpoint you created above as part of the process. Leave it to run and keep your fingers crossed!
6. WAIT FOR A PANDEMIC TO HIT!
By this point I had migrated just my own mailbox and also a handful of test users into Microsoft 365. Everyone else was still on-premise waiting to be migrated. I had gotten the green light to order a new server for The-Charity (as part of the whole separating us from The-College plan) and so was waiting for this new server to arrive with the view that my plan now was to:
BUT… suddenly a pandemic hit whilst I was on annual leave and all staff found themselves needing to work from home at short notice. I cancelled my annual leave and gave everyone access to their MS365 accounts (remember they had been populated with users/logons by syncing our Active Directory through ADSync, it was just the Exchange emails and all server files that were not online).
And so began a period of getting everyone online with their new accounts, but using their old webmail, and collaborating through Microsoft Teams. I was able to VPN into the building and upload files people needed into relevant folder structures in Microsoft Teams/SharePoint and spent a few weeks with everyone populating their OneDrives with files setting up groups in Teams. Which brings us to…
7. ATTEMPTS TO CONVERT THE ACCOUNT LATER…
As remote working continued we decided we would have to start running some of our media programmes and courses online. This is when I discovered the main differences/benefits of setting up an educational Microsoft 365 account as oppose to a normal business (charity/nonprofit) one.
The educational account is better at separating out accounts by staff/tutor/faculty and by student. This makes it MUCH easier and safer to setup accounts for students without automatically giving them access to everything in Teams that staff also have access to. It made Microsoft Teams work much more like Google Classroom which would have been PERFECT for us! Unfortunately (at least at this time) it is impossible for Microsoft to convert an account from a standard or nonprofit account to an educational account. I understand the logic behind this I guess as there is a verification process that needs to be gone through but it’s still very frustrating. The only way for us to have an educational account would be to setup a new one and then transfer everything over ourselves, which would have been much easier to do a few weeks ago when nobody had actually started using their MS365 accounts. It was almost impossible now that everyone had spent weeks populating it with information and relying on it daily during a global pandemic!
I created a new educational Microsoft 365 A1 account anyway with a new domain I registered (The-Charity.online) with a view to having a separate domain for students and tutors to the domains core staff use. You can setup some limited sharing between tenants (so Teams users from The-Charity.co.uk can communicate with Teams users in The-Charity.online) but not as much as would be useful to us. I may have to revisit this once everything gets back to some sense of normality and possibly even migrate one account into the other. If so I’ll make notes and write another post!
It’s been a long few weeks for a lot of reasons and I’ve written this out as best I could remember. Next time I’ll make notes as I go along! I’ll probably add to it if I remember any other details but I hope it’s useful to someone.
UPDATE: I have since realised that the better option for us would have been to forget about AD Sync and perform a cutover migration (instead of getting us both stuck in a hybrid migration). Hindsight is a wonderful thing! If you would like to read how I resolved this problem and finally separated us both from the shackles of our old Exchange server hybrid then I’ve written a post on converting our hybrid users to cloud users.


2 Comments