In my role as a Technical Architect I have spoken to many customers on Microsoft technologies over the last 25 years and In the last year I have seen a renewed interest in companies looking to outsource their Windows device management. There are multiple reasons driving this interest which might simply be a move to concentrate on their core business or because the pace of change within technology is something they find difficult to keep in line with and maintain skills. Whatever the reason, when outsourcing your device management platform this introduces opportunities for service providers to influence the customer when modernising their systems and develop a modern cloud native solution. The increase in divestments and acquisitions has also driven the same story and lets face it cloud managed device management is no longer a new approach. Some early adopters are now looking to either expand their capability or migrate away from their initial MDM and maximise their investment with Microsoft M365 licenses. At the same time Microsoft Intune has improved so much it is now an industry leader.
There’s a great argument for switching to Intune not least the financial savings you can get from infrastructure, IT management, improved security and greater scalability. With technology moving so quickly companies are under pressure to plan their move to the cloud and it’s clear that new features and capabilities are being directed and made available on modern management solutions, at least first.
The culmination of these factors has influenced companies to consolidate their Windows platforms into using Microsoft Entra ID (MEJ) (Formerly Azure Active Directory) with a Microsoft Intune MDM architecture. In many cases this means either migrating from an existing on-premise Active Directory (AD) approach to an Entra ID identity meaning devices move from being AD joined to MEJ-joined. Alternatively and in many cases it could mean moving from Hybrid Microsoft Entra ID joined (HEJ) to a Cloud first MEJ-Joined approach.
So what does this mean and how do companies approach this. Well many people have written on this topic before and there are toolsets and scripts out there to assist you. At the same time there are many knowledgeable IT admins still left wondering about the correct way to architect this. Let’s face it if you have 10,000 to 50,000 devices or more it’s a significant change and potential disruption which could eat into your budget very quickly and therefore needs to be carefully planned.
In my experience all companies have their own unique drivers, time line to deliver and specific requirements when planning this, and so it’s important that the right steps are taken to be prepared.
In this blog I want to explore the different high level options available when migrating from an on-premise AD platform directly to Microsoft MEJ-joined where Windows devices authenticate directly with Entra ID.
PLEASE NOTE: I do not look at or consider what it means when migrating other services here such as Office 365, Files servers and Databases etc from on-premise (or hosted elsewhere) to Azure. In most cases this will need to be completed before you adopt and deploy your modern device management strategy. It is worth raising the point that to move to a cloud native approach does mean that the end user loses access to on-premise device authenticated services and group policy. There is a path to ensure this architecture can still provide access to on-premise printing, file servers, intranet web servers but this is another topic and assumes you still want to maintain your on-premise AD infrastructure which may not be part of the plan. With this in mind here are my high level options to consider when migrating. You will naturally see a common theme here for many of the tasks as you would expect but each option includes its own notable differences.
Option 1 – Hardware refresh option
Probably the easiest route you can take is to develop a hardware refresh approach where you purchase and deliver new laptops or desktops for end users. This allows you to take the opportunity to switch to Autopilot enrolment and go directly to a Cloud-native Entra ID build. It also works when introducing this for new starters or when gradually introducing replacement machines. In many ways this is probably the cleanest path and has the smallest impact on end users. The one downside is that it introduces additional logistical tasks like collecting and either recycling or disposing old devices. It can also take the longest period of time to complete. When selecting this option the high level tasks to deliver include:
- Create and configure your new Azure tenant - Prepare Intune and Autopilot with the appropriate enrolment, compliance, configuration, security and applications - Verify all applications are compatible with Entra ID before beginning the migration process - Complete Tenant customisation as required - Synchronise your identities from AD to Entra ID using toolsets such as Azure AD Connect - Register new Windows devices Hardware Hash-ID’s into Intune - Assign policies, profiles and applications to the right users and groups - Deliver the new device to the end user with instructions and perform an OOBE Autopilot enrolment.
With this option the user will lose their profile settings unless you backup your files and data first or use tools like Transwiz or FastMove. Implementing OneDrive in your current estate is often advisable to move user data across in advance. When it comes to the User state migration tool (USMT) from Microsoft they have stopped further development and this does not support migrations to Entra ID. Take a look at the details for ESR here: Enable Enterprise State Roaming in Azure Active Directory – Microsoft Entra | Microsoft Learn
Option 2 – Microsoft recommended approach
Alternatively you can take the Microsoft recommended route when migrating existing Windows devices. This is the only Microsoft official route supported. The top level tasks are:
- Create and configure your new Azure tenant - Prepare Intune with the appropriate enrolment, compliance, configuration, security and applications - Verify all applications are compatible with Entra ID before beginning the migration process - Complete Tenant customisation as required - Synchronise your identities from AD to Entra ID using toolsets such as Azure AD Connect - Harvest Windows hardware hash-id’s and import into Intune - Assign policies, profiles and applications to the right users and groups - Wipe or reset existing Windows devices and enrol into Intune using Autopilot.
While this is a logical route to take as it means the device gets a clean start, there is a down side and this path doesn’t always suit all circumstances and company budgets. Having a clean and fresh built device means that settings for example with the registry updated by Group policy over time could impact how software and policies are deployed using Intune, installed and run following a migration. You ideally also want to reduce end user device issues and support tickets so having a fresh start with a device makes lots of sense. BUT it’s important to know that when taking this approach the end users profile and settings for apps, desktop and browsing data will be lost. If you have a hybrid identity deployed you can overcome this by enabling ‘Enterprise State Roaming’ within the Entra portal. For AD joined devices this would mean configuring HEJ first on your devices which may be a step too far. Another options would be use scripts or group policy to turn on OneDrive Known folder move for moving Windows Known folders (Desktop, Documents, Pictures, Screenshots and Cameral Roll) to OneDrive for users.
One final point to raise here for this option is that this method means if you are using BitLocker to secure your Windows device you won’t need to migrate this and can start afresh using a BitLocker policy deployed with Intune.
Option 3 – Manual process for migration
Where budget is tight you may want to follow a manual process for completing your migration. This approach assumes that the Windows device is configured in such a way that you don’t need to wipe or reset the device. The thing to consider here is whether the extra effort taken to carry this out outweighs the cost of employing an automated toolset approach which has to be worked into the migration budget . You may want to consider also what tasks have to be taken by the end user and the time they are not being productive or if the end user generally is technically capable of performing the tasks. The top level tasks are:
- Create and configure your new Azure tenant - Prepare Intune with the appropriate enrolment, compliance, configuration, security and applications - Verify all applications are compatible with Entra ID before beginning the migration process - Complete Tenant customisation as required - Synchronise your identities from AD to Entra ID using toolsets such as Azure AD Connect - Harvest Windows hardware hash-id’s and import into Intune - Assign policies, profiles and applications to the right users and groups - Manually disjoin the windows device from the domain using a local script or running a command locally - Turn on OneDrive Known Folder move (if required) - Remove the SCCM or other management agent from the device using a provided script or running a command locally - Enrol the device into Intune through Windows > Settings > Accounts > Access work or school Login with migrated identity to Intune and accept MDM enrolment - Once enrolled deploy a ‘Proactive Remediation’ script using an Intune policy to recover the existing BitLocker recovery key (if required).
Using this approach means you are not reliant on any toolsets other than AAD Connect (included with M365 licensing) to migrate your Windows device. Let’s be clear though this is not a clean fresh start and runs the risk of policies deployed through Intune running into issues further down the line. There is also the reliance on end users performing some of the actions even if it means running a script provided through IT Admins. Using this approach does however preserve the users local data as they haven’t reset the device. Despite this, it is advised to ensure that OneDrive Known folder move has been switched on as the users profile is associated with the Domain the device is connected to and will need to be updated. If the device is protected with BitLocker, there will be a time period during the migration where should the device encounter an issue access to the BitLocker recovery key will not be available meaning the device will have to be reset anyway. This is not a preferred route to migrate and could take 2-3 hours to complete per PC. It is also not a recommended or supported route from Microsoft.
Option 4 – Using Semi-Automation to assist with the migration
The 4th option I have here is a way of introducing some automation to the table. Automation will look to remove some of the reliance on the end user and ensures the migration can happen in a more timely fashion. This route again means the device is not reset so the users profile is again preserved or at least the users local data. Like option 3 its definitely not the cleanest process as remnants of the domain join may still exist such as registry entries or settings. This option certainly becomes a viable choice for small to medium scale migrations and uses third party tools. To deploy this approach follow these steps.
- Create and configure your new Azure tenant - Prepare Intune with the appropriate enrolment, compliance, configuration, security and applications - Verify all applications are compatible with Entra ID before beginning the migration process - Complete Tenant customisation as required - Synchronise your identities from AD to Entra ID using toolsets such as Azure AD Connect - Harvest Windows hardware hash-id’s and import into Intune - Assign policies, profiles and applications to the right users and groups - Create a windows provisioning package (.pkgg) using the Windows Configuration designer tool to automate the AAD join of the device. - Create a deployment package using automation tool such as Immy.bot or Forensit Profwiz and inject the .pkgg package into the Profwiz deployment wizard as part of the automation file. The end result is an .EXE file which can be deployed to the devices using SCCM or GPO - User to run run the deployment file. - Once enrolled deploy a ‘Proactive Remediation’ script using an Intune policy to recover the existing BitLocker recovery key (if required).
While the above method does take some preparation I do think it’s a viable and proven route companies can take despite requiring a small budget to purchase/use the toolsets. It is also a more effective way to migrate where the end user community has very limited technical know-how.
The end result is that the application will migrate the device profile from the local device into Entra ID retaining the settings and desktop data. This will also remove the device object from AD and disjoin it. The machine will then be joined to Entra ID. Its worth noting that without the use of the provisioning package you will still need to disconnect the device from the local domain and join the computer to Entra ID.
Take a look at the great blog by Sean Bulger as an alternative here for a semi-automatic migration. Migrating AD Domain Joined Computer to Azure AD Cloud only join | (modernendpoint.com)
Option 5 – Automated Migration approach
In order to strike a balance here I thought it would be right to also include one migration method that provides comprehensive automation as my last option. Quest is one of these and is an industry recognised toolset that can be used for small to large-scale management and migrations. Their ‘On Demand Migration’ suite of capabilities includes an Azure AD device Join solution which includes support for both on-premise as well as Hybrid Domain join scenarios. The On demand steps also preserves user profiles and file/folder security permissions. When it comes to pricing it may not be the cheapest option but will provide a simple and secure path to your migration and includes a comprehensive dashboard allowing you easily plan and keep track of all migrations and their state. The key factors here are really the risk and time you build into you migration and whether using a more expensive fully automated route outweighs these when compared to using a manual or semi-automated option.
Summary
Migration from AD to Entra ID for your Windows estate is certainly something you need to take seriously and consider the right approach for your company. As mentioned this will be determined by your timescales, size of migration and where you are in your Cloud migration Journey. I definitely haven’t covered all the possible routes and considerations here that will you need review as this will depend on your specific environment and the data you need to migrate.
I hope this helps you better understand some of the options available to you for your circumstances.
References
Immy.bot – Immybot – Deploy Workstations in Minutes
Forensit Profwiz – ForensiT Domain Migration
Microsoft transition to the cloud – Road to the cloud – Move identity and access management from Active Directory to an Azure AD migration workstream – Microsoft Entra | Microsoft Learn
Quest – Office 365 Tenant-to-Tenant Migration Tools | On Demand Migration (quest.com)
One comment