Migrating away from your on-premise AD Server to Azure AD Joined devices is a common scenario for any business which no no-longer has the requirement for fast, low-latency access to data and is already invested in Microsoft 365.
This could mean that all company line of business applications are accessed through the web and information is saved and collaborated through platforms such as Microsoft Teams and SharePoint.
In this post, I am going to show you how you can migrate on-premise AD to azure step by step.
Here, we are going to discuss a hypothetical scenario of a business that wants to make this transition and go through the process. We will then detail the planning steps from start to finish which will enable the move to a modern work-based solution.
AD Migration Scenario
OurCloudNetwork has a single on-premises domain controller that also hosts the company’s main corporate file share. All company workstations are joined to Active Directory and they are already using Exchange Online from the Microsoft 365 suite for email.
It has been identified that their last on-premise accounting application can be moved to the cloud and access modernised to use a web browser experience and sign-on through single-sign-on with Azure Active Directory. As such, there is no longer any requirement for a client/server architecture.
Some other facts are also true in this scenario:
- The single Windows server runs Windows Server 2012 R2
- Some clients are running early builds of Windows 10 and some Windows 11
- There are minimal printing requirements and no shared printer, some users have their own USB desk-side printers
- Some custom group policies are used to manage local client utility applications
- Files saved on users’ desktops that are not backed up are a concern
- OurCloudNetwork would like to collaborate on projects with external companies
The Required End Goal
Basic on the current environment and requirements the following end goal has been proposed to modernise OurCloudNetwork’s infrastructure.
On-premise Server
The on-premise server will be decommissioned and identities from Active Directory will be synced to Azure Active Directory using the Azure AD Connect synchronisation tool.
Any group policies in place will be exported from the server and migrated to Microsoft Intune.
The existing file shares will be migrated to SharePoint and Microsoft Teams with permissions backed by Microsoft 365 groups.
Exchange Online will continue to be used as part of the Microsoft 365 suite.
User licensing in Microsoft 365 will be upgraded to Microsoft 365 E3 to accommodate for the required changes.
Client Workstations
All client workstations will be removed from the domain and joined to Azure Active Directory with Intune for device management.
Intune will also enforce policies across the machines and deal with update management for the Windows operating system.
Security
As compliance has been identified as a concern, device compliance policies are to be implemented backed by conditional access policies to enforce control.
Strong Multi-Factor authentication (Not SMS or Phone call) will be implemented for all users with the exception of a break-glass account which is to be monitored for use.
The Plan to Migration from On-Premise AD to Azure
Step 1
You should start by ensuring all of your users are licensed appropriately for the solution you are putting in place. In our scenario, we have selected the Microsoft 365 E3, Enterprise plan. This license provides us with all of the cloud services, security tools and management tools we need to build an effective and secure solution. Other enterprise plans can be viewed here: https://www.microsoft.com/en-gb/microsoft-365/compare-microsoft-365-enterprise-plans. You also have the option to go for an M365 Business Premium license if your organisation is under 300 users and does not require improved features like Exchange Online Plan 2, hybrid licensing, additional DLP and support.
You should look into the difference between each type of license available and make a decision based on business requirements such as; hybrid server requirements, security, compliance and data. endpoint management and support from Microsoft.
Step 2
It is likely (even if you do not agree with this statement) that your users have data saved onto their workstations that are not within your organisation’s backup scope or saved in the cloud. In any case, this step should involve you sanitising your company data and ensuring your user’s critical data (that they are often currently working on) is saved to their OneDrive (at a minimum).
Firstly, you should ensure the latest OneDrive client is installed on your client’s workstations. OneDrive can be downloaded here and you should follow the wizard on installation to ‘backup’ important data. I say back up as you are not traditionally backing up their data at this stage, but simply redirecting it into their personal cloud storage (OneDrive). A 3rd party backup solution should also be used alongside Microsoft 365, but we will cover this at the end.
You should also work through any data you have on local file servers and ready that data to be moved to Teams and SharePoint. Prior to making the decision to move to a modern work solution for your data, a feasibility study should have been conducted which determined SharePoint and Teams to be the correct solution. Often you will find that a Hybrid solution always works best, where large files needing low-latency access are saved to local server storage areas and that collaborative project documents work nicely in Teams.
This can often be the most time-consuming step of the project but is often an unloved process. So make sure you take your time at this stage and work with key stakeholders and data owners to decide the best plan and area to store such data.
Step 3
Once you have evaluated and sanitised your data, you should evaluate the use of Microsoft Teams. Microsoft Teams is a great tool for project-orientated work as it provides for users to work together in files, calls and meetings with real-time communication.
Microsoft Teams is predominantly backed by Microsoft 365 groups. When you create a Team, many other services are also created, such as a Microsoft 365 group, SharePoint Online Team site, group Exchange mailbox and a collection in OneNote.
It is also good to understand logically how Microsoft Teams is architectured with other Microsoft 365 services:
- Your personal files within Teams are saved to your personal OneDrive space.
- Shared files within Teams are saved to the SharePoint Online sites. This also means that you can access the files without having to go directly through Teams.
- Messages in Teams Channels are saved to the group Exchange mailbox
- 1-to-1 chat messages are saved in the individual user’s mailbox.
- Calendar information is saved in the individual user’s mailbox.
Step 4
Now you have planned your data strategy using SharePoint Online and Teams, you should implement Azure AD Connect on a member server or domain controller to synchronise your user passwords between their Windows logon and Microsoft 365.
Enabling password sync in with Azure AD Connect will simplify the user’s experience so they no longer need to remember multiple passwords, especially since you are now going to introduce services such as OneDrive and Teams which will ask to be logged in again. Commonly you will find, that if an organisation is not using Azure AD Connect, users will rarely remember their Microsoft 365 password, which just leads to being an administrative burden for your IT Team.
For guidance on installing Azure AD Connect, check out my post: How to install and manage Azure AD Connect.
Step 5
Migrating your data to SharePoint Online and Microsoft Teams should be your next step. You have 2 fantastic and free tools provided by Microsoft to achieve this:
- SharePoint Migration Tool (SPMT)
- SharePoint Migration manager
Use this helpful learn document from Microsoft Learn on specifics around migrating your file shares to SharePoint/Teams.
Once your data has been migrated, you should power off your file server for a period of time (or you can simply disconnect the network) to ensure nothing has been left behind.
Step 6
At this point, you should be at a stage where you have consistent user identities between your on-premise active directory and Azure AD. You should also have all of your data in SharePoint and Microsoft Teams.
As all of your critical systems are now in the cloud, we need to prepare your Microsoft 365/Azure tenant for the proposed solution of managing the devices through Microsoft Intune and using Auto Pilot.
You should ensure you do the following:
- Enable automatic enrolment for Microsoft Intune. This will ensure when devices are joined to AzureAD either manually or through the OOBE, they are enrolled into device management also.
- Add devices to the Windows Autopilot service
Step 7
Unfortunately, just enabling the management services is not enough to effectively use the Intune device management. There are some other settings you need to configure before you begin testing.
Configuration profiles – These are setting packages that you apply to your devices based on the user or device identity. For example, if you want to configure Windows Defender to be enabled on all devices, you would configure a configuration profile, with that setting enabled and assign it to all devices dynamically.
Compliance policies – These determine if a device is compliant with the defined standard within Intune. For example, if you require your Windows devices to use BitLocker and have it enabled, then you can specify this in your compliance policy and then your device will be marked either compliant or non-compliant. Compliance policies can work hand in hand with Conditional Access policies to block access to services if a device is marked as non-compliant.
Update rings – An update ring defines how Windows updates (and associated apps and drivers) are deployed to your workstations. You are able to configure feature and quality update deferral periods, Windows 11 upgrade or deferral, feature update uninstall periods, pre-release deployments, active update hours, automatic update behaviour and a lot more. This is a critical step to both ensuring updates are deployed on time and improving the user’s update experience.
Take some time to look through the Intune admin centre and review any settings which could drive value to your organisation.
Step 8
As our plan is to do a complete reset of each Windows device, any 3rd party applications (such as web browsers or utility apps) will need to be reinstalled. Thankfully, Intune allows you to deploy applications from the management portal, remotely to your device.
There are many types of applications you can deploy to your device, commonly used app types include:
- .MSI
- IntuneWin
- Office C2R (Click to run)
- APPX
- Store For Business Apps
Step 9
You are now in the testing phase. You should identify a device and user account that can be interrupted and conduct a pilot run of resetting the device through Settings > Update & Security > Recovery > Reset this pc.
The device should reset and take you to the first start-up (out of the box) experience. When you sign in with your corporate account, the device should register with the AutoPilot and Intune services, this should be apparent based on the settings you configured in each service and the experience you are having on the device.
While you are performing each step you should record the process, either through pictures or a video recording. Any step which requires user input should be carefully documented, especially if the end-user will be actioning such a step.
Once the device is logged on, check all of the required apps and configuration profiles have been deployed accurately and tweak any settings if required. If you are happy with the process, you can move on to the complete rollout.
Step 10
Once testing is complete you are ready to conduct the full migration for the remaining workstations. Depending on how many devices you have and how many different locations they are in, you could approach this in many different ways.
Likely if you have around 30 devices in a single location, you could easily manually reset groups of devices at once and tackle this work over the period of a few days or a week. However, if you have hundreds of devices, you should include testing some automation techniques and maybe delegating someone at each location to assist with the process. For example, you could enrol your devices in Intune/Autopilot through hybrid domain join and group policy, then reset the device through the management portal. Or you could use an RMM tool to reset the device. Your approach will depend on the size and complexity of your Windows estate.
Step 10
This can often be an overlooked step, especially if different locations adhere to different compliances and as it adds additional complexity to your already large project. However, implementing conditional access is a critical step to modernising your infrastructure.
You should evaluate which applications and users you wish to require certain controls such as requiring Multi-Factor authentication, session limits or even block controls.
In a perfect world, you should capture all of your estates in simply 1 or 2 compliance policies that target all users for MFA and all devices for compliance.
Follow my tutorial on How to create a Conditional Access policy.
Step 11
Lastly, after a defined period of time, usually around 2 weeks to a month. You should decommission your server infrastructure if required. In some instances you may be required to maintain a few Windows servers, however, if there is no longer that requirement, you should ensure they stay powered off for the above period of time and then decommissioned.
I wish I had found this post a month ago when I got thrown in at the deep end to help migrate a school’s on-prem AD to Azure AD!
Glad it helps Tony! I plan to do a review and update of it soon!
I’m in the process of trying to move our DC to Azure. Thanks. How long does this take? I also wonder if you do consulting.
Hi Kim,
That depends on your environment, but if you reach out to me via LinkedIn we can discuss consulting 🙂