If you’re here, then you’re probably thinking, planning, or feeling ready to remove your Local Active Directory environment. Like many organizations, you’ve made the move to Microsoft Entra ID (formerly Azure Active Directory) and most likely a migration of email and files into Microsoft 365.
In this post, we’ll cover the following:
1. Why remove Local Active Directory and Convert to Cloud Based Entra ID
2. Considerations of Migrating Local Active Directory Network Services to Entra ID (formerly Azure AD)
3. Planning the Move from a Hybrid Local Active Directory to Entra ID
This post expands upon a video/post that we did a while ago, but we’ll go deeper in this post: /news/removing-local-active-directory-the-easy-way/
Why remove Local Active Directory and Convert to Cloud Based Entra ID
There is certainly a scenario where you may need to keep Local Active Directory around but want to reduce the overall usage of it. We won’t cover that in this post, but here at Agile IT we can help with that.
Let’s assume that you’ve spent the time, money, and organizational changes in migrating your email to Exchange Online, files to OneDrive/SharePoint/Teams, and your now even using Intune to manage your mobile and desktop devices. In this state, you also have a deployment of Azure Active Directory Connect (AADC) that is synchronizing your users and groups from Local Active Directory to Entra ID (Azure AD).
While this works, your organization is living the hybrid identity life, but with reduced needs and benefits. What you have is an active attack surface, ongoing costs (power, internet, A/C, Backups, Generators, hardware support, software licensing, etc.), and probably on aging hardware and Windows Server OS versions.
Thus, why we’re all here on this page together. So let’s jump into getting ready to make the transition.
Considerations of Migrating Local Active Directory Network Services to Entra ID (formerly Azure AD)
Local Active Directory often heavily influenced other networking configurations due to the requirements it has for services and clients to find and manage Domain Controllers.
There are often several Windows Servers in the environment that are also handling the following:
DHCP
DHCP provides local IP addresses to network devices. If your environment is using a Windows Server with DHCP, you’ll want to remove this to your local networking device that can handle this going forward. They pretty much all do it now, but you need to consider the following:
1. Document your static reserved address scope on the Windows Server so you can add the same into the network device when you do the transition
2. Test out the static IP addresses as you might not need them all (aka technical debt)
DNS
In almost all Windows based environments, there are Windows Servers handling the internal DNS services. This is often defined directly via DHCP and statically mapped on servers. This is needed so that Windows Servers and Clients can find a Domain Controller to authenticate and register itself into DNS. We’re not going to need that anymore.
Now that we’ll be getting rid of that as well, we’ll need to ensure that the updates to DHCP also include pointing DNS requests to a public IP address. This could be your local ISP or other public DNS service.
Over time, there might be static DNS records created within your Windows DNS service used by applications, internal applications, phone support and more. This is where the important but kinda boring work happens.
Printers
Printers are often overlooked, but an important areas to properly plan and transition. If all your printers are directly connected to and used by specific Windows Clients, then you’ll have less to handle.
If you’re using a Windows Server for Printer services, then you’ll need to plan for a different approach. First, I’d recommend Microsoft Universal Print. Keeping in mind that you’re already down the path of using Microsoft 365 services, this is a great option but may require an additional license but you could already have it!
If your printer currently (or with a firmware update) supports Universal Print, then the transition for printers will be less cumbersome. If they don’t then you’re still ok, but you’ll need to deploy a Universal Print Connector which is an agent that can go on a local Windows Client, Windows Server, or stick that agent on a Virtual Machine within Azure.
SMTP Relay
Printer/copiers have a feature to send items to an email address. In order for them to do this, they often point to an SMTP service. Commonly, this was sent to an Exchange Server. You might still have an
Exchange Server present to handle this task AND used for managing Exchange Online mailboxes that are associated to your Local Active Directory (more on that later).
As for the SMTP Relay, you’ll need to move this task to a different service. You can update the printer/copier, and sometimes internal applications, to send directly to Exchange Online. Depending on what your device or application can support, you might have to still have a local or Azure virtual machine handle this task, but you can still do this without a Local Active Directory environment, but make sure to set strict security settings to it doesn’t get hacked and abused.
Exchange Server
You might have had Exchange Server in your environment at some point. And you might even still have it to manage your Email configuration. This is often needed when you have user accounts in Local AD that have Email accounts in Exchange Online. Once we get rid of Local Active Directory, we won’t need this anymore, but we must consider its current configuration as part of the transition.
The Exchange Server could by in a Hybrid configuration or not. If it is in Hybrid configuration, you’ll want to evaluate it’s usage to ensure there is no more traffic flowing back and forth.
Server Applications (This is the replacing Local AD part of the story)
For applications that deployed internally that leverage your Local Active Directory environment is a huge topic by itself. This certainly is true with Windows servers, but Linux servers play a part here too as they might be using the LDAP connection for authentication
Part of your transition may include a “Lift and Shift” project where you’ll move your servers and their associated applications into Azure. We love it! Keep in mind that some of those servers may require a Local Active Directory environment. If it really does require Local AD, then a deployment of Azure Active Directory Domain Servers (AADDS) is great option. No, it’s not keeping your Local AD alive.
With AADDS supporting the directory services your application requires, you can still have your Local AD fully removed, but now it’s syncing the user and group information from Entra ID (Azure AD) directly. And you don’t have to back it up, patch it, and more because Microsoft is doing it. Again, a much deeper topic.
That said, your servers would still need to leave your Local AD and then join AADDS and it will be a different domain name (e.g. corp.mydomain.com). Some servers don’t like this, so you often need to deploy a new VM, join AADDS, deploy your application, and then migrate your data. So how does the server application know about the users since it’s a new “domain”, well it depends on how the application tracks this in the first place. Maybe it requires a Local AD, but it reads the user object based on the UserPrincipalName, mail, or SID. In that case, you’ll be fine. But again, this should be tested out. (Give us a call at Agile IT)
Other Networking Services
You might also other services that are leveraging Local Active Directory. They often leverage LDAP or RADIUS based services to support authentication.
Here are a few:
- VPN – Logging into a device at the office that allows users to leverage their Local AD accounts
- Remote Desktop – This could be a Remote Desktop Services environment. If so, you should look at Windows 365 or Azure Virtual Desktop as a replacement
Windows Clients
Local Active Directory and Windows clients (Windows 10 and Windows 11) have a trust relationship that must be broken in order to transition away from Local Active Directory. At the time of this post, there is unfortunately not a way to automate the process of a Windows client transitioning from Local Active Directory to Entra ID (Azure AD). While there are some tools that makes the process of “migrating” the local user profiles and some “faster” ways to join the Windows Client to Entra ID (Azure AD), it still requires local access to the device. And in a Remote work world, this can be challenging for many IT teams and end-users.
So what are we talking about here? OK, this is a super quick explanation of what needs to happen, but probably need to write another post on this topic that gives better details and options.
Before you start (per desktop):
1. Local Administrator Account - YOU need a local user account and password that has Administrator rights. I know what you’re thinking, “why can’t I just use a Domain Account or a role in Entra ID (Azure AD) that has local computer rights?” Great question, but the answer is no. You’ll see why later in the quick steps, but it’s because there will be a period of time that the Windows client doesn’t belong to either. There are several ways to
2. Disk Encryption – If you have your Windows clients using disk encryption, then first I’m proud of you! But now we need to think about how we’ll handle this during the transition. You have a few options
a. Disable/Remove encryption during the transition (no ideal, but you can enable BitLocker when you get to the other side)
b. If you have BitLocker enabled and it’s registered with Entra ID (Azure AD) already, then IT or user of the device can find this online if needed, but best to have that ready in case you DON’T remove it but you’ll have to type in a long string during each reboot
3. AnitVirus – While you don’t always need to disable this, you might if in the following steps you plan to use a tool that migrates the user profiles
Here is the high-level steps, but you need to test this out and adjust as needed to fit your environment:
1. Login to Windows Client with Local AD or Local Account that has local Administrator rights
2. Leave Local Active Directory (you might also be asked for username/password that has rights to do this via Local Active Directory)
3. Reboot – Now the Windows client is in a “Workgroup” and not bound to any directory service
4. Evaluate/Remove from Entra ID (Azure AD) and Intune
a. Once you remove the Windows Client from Local Active Directory, you’re Azure AD Connect might be configured to sync computer accounts as well, so you’ll need to wait or force a sync to have it removed in Entra ID (Azure AD)
b. You might need to manually delete that computer object in Entra ID (Azure AD) and in Microsoft Intune as well so that they objects don’t get duplicated or conflict
c. Again, test this all out. We’ve seen it not always behave the same for each tenant
5. Login as local user with Administrator rights
6. Join Entra ID (Azure AD)
a. Depending on how your Entra ID (Azure AD) configuration is set to allow users to join devices, you might have to do this with an account that has this right. Typically, this is set to all users to do this, so then join based on the authentication of the user that will be using this device
b. If you had to join based on an Entra ID that is NOT the user that will be using this device
7. Reboot – Now the device is an Entra ID joined device
8. Login – Login with the account you used to join the device to Entra ID (Azure AD) to validate all is good
a. If you did this with an account that is NOT the user that will be using the Windows Client, then you’ll now want to reboot (yes, you can just logout, but reboot just feels better)
i. If you DO want the user to also have local administrator rights, then run the following command from a Command Prompt in “Administrator Mode”:
net localgroup administrators /add “AzureADUserUpn
b. If you did this with an account that will be using the Windows Client, then you’re pretty much all set. If your Entra ID (Azure AD) has been configured to allow users to have local Adminstrator rights, then you’re all set. If not, then that’s fine too. But if you did want to add that in for the user, then run the command noted above
9. Migrating the Profile – The application shortcuts and other user profile information might want to be migrated from the previous user account that was bound to the previous profile that was bound to Local Active Directory. There are several tools on the market that can handle this. Here are a few to look at:
Planning the Move from a Hybrid Local Active Directory to Entra ID
a. PCMover from LapLink: https://web.laplink.com/product/pcmover-professional/
b. User Profile Wizard from ForensiT: https://www.forensit.com/domain-migration.html
At the end of the day, we just want to turn everything off. That’s right! We aren’t really going to uninstall servers, remove servers as members from the domain, uninstalling the Active Directory Domain Services roles from the Domain Controllers. We just power it off. But that’s ONLY once all of the other servers, applications, and clients are no longer dependent on it.
While there is a magical moment of turning off the servers, the good news is that you can slowly make the transition. However, keep in mind that there could be some BIG changes to users and devices that need to be well communicated as you move along.
1. Migrate your apps to SaaS or Servers in Azure
2. Migrate your files and data into Microsoft 365
3. New Windows Client should be directly Entra ID (Azure AD) from day one
4. Transition your Windows Clients to Entra ID (Azure AD)
5. Update Printers and Copiers to use Universal Print, send emails to Exchange Online direct or new SMTP relay that is not connected to Local Active Directory
6. Validate local networking equipment can perform the DHCP/DNS capabilities and load
7. Remove Exchange Hybrid configuration (if applicable)
8. Disable DHCP on Windows Server and enable on networking device
9. If you think you’re ready, turn off all the servers (but don’t disconnect from Azure AD Connect yet)
10. If no disasters after a few days, then you’re ready to finish it off. If not, then turn on servers, resolve issues, and start again
11. If all is well with he servers off, then the last step is to run a PowerShell command to break the connection between Local Active Directory and Entra ID (Azure AD). Purposely not listed here so you don’t get in trouble. Yes you can Bing/Google it, but then you’ll have to read a bunch of documents to find it which is what you should be doing.
12. Now you can delete your VM’s and scrap or repurpose the hardware based on your corporate policies (as your legal team)
Planning, testing, and a well communicated process will be key to making this change. While the steps and guidance defined here provides some insight, there is always something sneaky that could influence the order and timeline to achieve the end goal.
At Agile IT, we have a collection of services to help you in this journey you’re embarking on.
Published on: .
Sales@AgileIT.com