CONFIGURING AD CONNECT FOR OFFICE 365

Before joining Spherica, Azure Active Directory was something that I had almost taken for granted. Someone else in the Identity Team (or the Active Directory team as they were known in the old days) setup a clever sync utility that allowed me to use my on-premise identity in Azure and Office 365. When I joined, the first thing I was asked to do was to migrate Active Directory Connect for a customer. The customer had AD Connect running on a single server in a traditional on-premise data centre and the new solution would be two servers running in Azure, one running as a primary server that exports changes to AD and AAD and one server running as a warm standby.

Migrate Active Directory Connect

On the face of it, this change seemed pretty simple. Microsoft does a great job of documenting these things. However, the documentation never really caters for a customer’s specific needs. After reading the documentation I installed the AAD client on the primary server and proceeded to start the configuration. This was tricky, there was no configuration documentation left from the original install so I had to deduce if there were any custom sync rules that the customer had implemented. I asked around to see if anybody knew if anything custom had been configured but nobody knew for definite. I decided to take a cautious approach and configure the server based on obvious settings from the old server. Once the install was complete, I disabled the sync engine and made sure that staging mode was enabled.

Staging mode in AD Connect allows you to Import changes from AD and AAD, perform a synchronisation but not export any changes to the directories; this happens by default every 30 minutes. This is really useful for verifying the configuration and high availability.

AAD Connect Config Documenter

I then used a tool called the ‘AAD Connect Config Documenter’. It works by comparing the configuration of the current production server with that of the newly installed server. Some of the output was very confusing but I did manage to work out that most of the changes could be attributed to the newer version of the AD Connect installed on the new server. I then did a good old-fashioned side by side comparison of the objects in the old server with the objects in the new server, I spot checked the attributes of 20+ objects and they all matched. The number of objects also matched. I now felt very confident that we could proceed.

Go-Live

The go-live procedure was the easiest part of the process. I enabled staging mode on the old server and disabled it on the new server. This gave us a ready-made backout plan should anything happen unexpectedly as we would just reverse the procedure; staging mode disabled on the old server and enabled on the new server. The export ran from the new server, the sync took a bit longer as it was the first one to export, I started to feel a bit worried that something had gone wrong as the update count was in the 5000’s rather than the 10’s. The all-important deletions number remained at zero though so I wasn’t in panic territory! When the export finished I had my team test logins and MFA. Everything was working as expected. Phew!

I then repeated the process on the second new server but left this in staging mode. This allows the customer to manually failover the sync service if required.

Identity in Office 365 is becoming very important to organisations, the improvements going into Azure AD at a rapid pace have the potential to replace traditional on-premise Active Directory domains. In this particular case, it was critical to the operations of the organisation, this is why we can’t take a big migration like this for granted and we had to be positive that everything was perfect before we made the switch. To learn more, contact us today to discuss your Office 365 Identity needs.