Moving your On-Prem AD to Cloud

Back in 2010 when vBridge started we created a brand-new on-premises Active Directory to support the corporate side of our business. We’ve used it ever since, but that is about to change.

Our dependence on cloud-services has increased in recent years to the point where we realised the overheads of maintaining an on-premises Active Directory (AD) outweighed the benefits. Therefore we decided to simplify our environment, reduce our management overheads while also reducing our Information Security exposure. Sounds good eh.

So this is something I’ve been working on over recent weeks and in this blog I share my experience so far. This isn’t an in-depth account but it might be useful to you if you’re thinking of heading down this same path. There are 3 main steps:

Step 1: Remove your dependence on your local infrastructure

A Microsoft 365 subscription is what really made this possible for us – particularly getting rid of our on-premises Exchange server (which we completed 18-months ago), and migrating our files to SharePoint Online, which we completed last year. The latter turned out to be a fantastic thing to do by the way and we wouldn’t go back to mapped drive letters if you paid us. SharePoint search works very well, and once your files are in a document library, doors open to other opportunities such as enhanced metadata capabilities, contextual information views, and Microsoft Power Automate (ex-Flow).

The questions once we got to this point were: 1) do we need a print server – which we decided we didn’t, and 2) could Microsoft Intune could replace our use of GPOs – yes it does. So, we made the decision to proceed.

Step 2: Join your computers accounts to Azure Active Directory (AAD)

AAD Connect (the Microsoft service that links AD to AAD) registers local AD computer accounts in the cloud but more work is needed to make these computers ‘Azure AD joined’. This is necessary for Intune to work.

As a relatively small organisation, we just did this manually – the overall process being:

Remove our computers from the local domain
Logon as local administrator
Join each computer to Azure Active Directory
Logon as Azure AD account and restore each user’s profile

The hardest part is step 4, because Microsoft has no easy solution to do this – you can either require your users to recreate their personal configurations (which people really dislike) or use a user profile (user state) migration tool. We chose profwiz (User Profile Wizard by ForensiT). The (free) Personal Edition supports 1-off manual migrations but if you want to migrate all your profiles or make the process fully automated then Professional and Corporate editions are available. This tool worked well for us.

Step 3: Promote your users to cloud native

Once the above steps are complete you can finally remove the link between your user accounts and your local AD. This is where I’m at so far in our own migration, and I plan to complete this over the coming week or two.

Achieving this requires some knowledge of an AAD user property called ‘ImmutableID’. Essentially, when AAD Connect replicates an AD user to the cloud it sets an ‘ImmutableID’ property on each user object. If you remove this property, AAD will consider the account cloud native but you can’t do this until AAD Connect is disabled.

I recommend the description of ImmutableID in the 2016 article What is ImmutableID in Azure AD. After that, read the more recent August 2019 article ‘Convert synced users in-cloud only user’.

Overall, cloud migrations can be a complicated process with many potential gotchas. Your mileage may differ from my own and your organisation may have dependencies on AD requiring specific attention. If you’re taking this journey, I strongly recommend reading Microsoft’s own guidance and take it step-by-step.

Our good friends at Softsource are happy to help with this if you need it, and in Part 2 of this blog I will share how things turned out 😊