Setting up Active Directory isn’t just about clicking “Next” in a wizard. At its core, the process involves planning your network and domain structure, installing the Active Directory Domain Services (AD DS) role on a Windows Server, and then a final few clicks to promote a Domain Controller.
This is the moment you create the central brain for managing users, computers, and all the resources across your network.
Each environment is different and while sometimes a gorilla style approach is best, I have always opted for graceful migrations with all Active Directory configurations. Getting all your ducks in a row before taking the steps to promote a domain controller.
Before we get started, understand that replacing a domain controller is often done using an approach called a swing migration (building another server with a newer operating system alongside the current server and then swapping IP addresses).
Many Windows services including Active Directory do not handle in-place migrations well (simply upgrading Windows Server by running the installation media).
🔥Warning: Like everything in this article it is my personal experience, and you must take full accountability for making changes to your environment. With that in mind, I personally recommend the swing migration approach.
I’m stunned how many IT professionals still think that if you promote a domain controller and Active Directory breaks, they can restore a snapshot. This is how things go from bad to absolutely catastrophic.
Get your Active Directory recovery steps ready now. Ensure all System State backups are taken, ensure the Schema is un-altered, ensure you have all DSRM passwords reset and if you are like me and plan for the worst – do a full Authoritative AD restore before going anywhere near the steps below (obviously in a lab environment).
Creating a CR with extensive roll back steps is not just to shut your manager up, it is also one of the best indemnity protectors available.
If the environment was corrupt and you caused 10 million dollars in lost revenue, you want to make sure you were not being negligent. Having the concrete steps laid out in a CR and approved by others in the business gives you the protection to move forward without the fear of a lawsuit and moving back in with your parents.
Similarly, sending out a corporate wide email outlining the risks is a great way to protect yourself and give the business an opportunity to raise concerns.
If I have a perfect CR and the comms emails have gone out warning the business of potential downtime, expected duration etc, I have full confidence to proceed with the change.
This step is dependent on the size of the business and the appetite for risk. If the business wants the absolute highest chances of success no matter what the cost – this option is a gold.
Typically, an environment with multiple domain controllers, there is often one DC which becomes the “main” one. This is not always the Primary Domain Controller (PDC) but it may be the one physically closest to the bulk of the staff, with the highest priority site link (use Active Directory Sites and Services for this) or just the one that has the majority of the apps pointing to it.
The “main” domain controller may handle the majority of requests, and these could be coming from colocation datacenters, on-prem or multiple clouds. Once you promote a domain controller you want to be certain it’s configured identically.
LDAP is a good example where a “main” domain controller can become a problem. For LDAP queries you almost never use IP addresses (it breaks SSL/LDAPS), but rather the FQDN of the domain controller. This means that a swing migration where you build up another server and swing the contents to it, will result in a new host name and you guessed it – broken LDAP.
To enable DNS Logging: DNS Properties → Server → Properties → Debug Logging and choose the location where you want the DNS .txt file to live.
⚠️Warning: this is a very noisy file. Be prepared to see every single DNS query ever made to that domain controller.
Once this file is populating with DNS queries, you can make a copy and sort through the file to see which servers and applications are querying DNS to that particular Domain Controller.
Microsoft requires the following ports to be opened between servers.
More information on Microsoft port requirements: Configure firewall for AD domain and trusts – Windows Server | Microsoft Learn
A good tool to use is PowerShell Test-NetConnection. So after the new server is build, ADDS is installed, DNS is installed and the server is promoted (see steps below), you can fun commands like the following:
Test-NetConnection -ComputerName <IP of new domain controller> -Port 445Test-NetConnection -ComputerName <IP of new domain controller> -Port 88
⚠️ Note. The above commands won’t work for all ports until the new server has been configured because the services need to be installed and running before you will get a successful Test-NetConnection result. You might consider checking/testing your firewall rules from within the firewall first and use these commands later on.
This is heavily dependent on your environment, however a few words of caution. Cloud based domain controllers do not allow booting into DSRM mode, making AD recovery very difficult.
The best practice for Active Directory services is to use an on-prem or colocation server where you can boot into recovery mode if something goes wrong.
General server requirements:> 4 Cores> 8GB Memory> 120GB Storage> TPM 2.0> Secure Boot> Virtualization-based Security (VBS) support, including hardware virtualization extensions
More details here: Hardware Requirements for Windows Server | Microsoft Learn
Using Server Manager, install Active Directory Domain Services (ADD).
In Server Manager select Add Roles and Features.
Choose Role or Feature Based.
Choose Select a Server from the Server Pool.
Select Active Directory Domain Services and then Add Features.
Leave the Features section default, we do not need any additional features.
Click Next on the following screen.
Click Install.
There are different opinions about when and how to install DNS when promoting a domain controller. To get to the bottom of it, I raised a Microsoft support ticket and insisted on a concrete answer.
Microsoft performed the tests in their lab and came back with a clear response which included the following direct quote “the best practice is to install DNS server role before promoting the server to a domain controller”.
They were referring to the installation from the “Add Roles and Features” wizard and not during the “Promote this server to a domain controller” wizard.
Select DNS Server.
Select Add Features and then press Next.
Leave the default Features and click Next.
Press Next.
Check Restart the destination server automatically if required and press Install.
Once complete and the server has restarted, you may need to make additional changes. Most environments use AD Integrated zones, so the DNS zones will automatically appear once you launch the DNS manager.
If you are using only AD Integrated zones, confirm the following match the existing domain controllers in your environment:> All zones have replicated correctly.> All DNS root hints are the same (or in most cases the default).> All Forwarders are configured the same.> Scavenging, Debugging, Logging/SIEM integrations are all the same.
👉 A good idea is to create a new DNS record and confirm it replicates to all other domain controllers.
Domain controllers are generally tough suckers. Even trying to deliberately break them in a lab (yes I tried, yes I have no life) is difficult!
However, with the new features being added to modern editions of Windows Server, updates to IPv6 and out of the box features like NTLM Level 5, it’s becoming easier to break AD.
I have put together a few things I tripped across during the last dozen domain controller builds
A. NTLM version mismatch. I found myself in a situation where someone had pushed out LMCompatibilityLevel 2 where as a default Azure virtual machine (domain controller) was set to LMCompatibilityLevel 5. The versions and the differences are below, in a nutshell they need to be the same.
0 – Sends LM and NTLMv1 responses and accepts all authentication types (completely insecure).1 – Sends LM and NTLMv1 but uses NTLMv2 session security if the server supports it.2 – Sends only NTLMv1 responses (no LM), but still accepts all types on the server side.3 – Sends NTLMv2 only, while still allowing LM/NTLM on the receiving side for compatibility.4 – Sends NTLMv2 only and refuses LM authentication, but still allows NTLMv1.5 – Sends NTLMv2 only and refuses both LM and NTLMv1 (most secure setting).You can see how a server on level 5 and a PC on level 2 won’t work. What happened? An aggressive series of account lockouts across the environment – not fun!
B. NTP Issues.NTP is the timekeeper on the network. It sets the clock on the Primary Domain Controller PDC, and in most environments the workstations sync to that server. BUT, again a brand new server in Azure and AWS default to using their own clock.
You would think it doesn’t matter, but unbeknownst to me our last systems engineer had set one domain controller to AWS time, one to Azure time and critically the vCenter server to CMOS. This meant the domain controllers were not using the same time source.
The result? Half of the customer service team were unable to use a key application which was throwing error messages when they signed in.
C. DSRM Passwords.Once you promote a domain controller, there are strict steps to restoring a backup. You should no longer use snapshots, and you must decide whether to do an Authoritative or Non-Authoritative AD restore. Regardless of which option you decide, you must boot into DSRM/recovery mode and that requires a specific password. Unless you have personally set the password, I would strongly recommend using the PowerShell command to reset them.
D. Check Replication.Active Directory replication is literally critical before you make changes. Run the following Windows command to see replication status. repadmin /replsummaryYou should see a healthy replication status with no errors.
E. Check DC Health.Use the command below to see logs about the health of the domain controller. Note, you will almost certainly see a mess of errors if you are doing this step after recent changes, so don’t be alarmed. DCDIAG
F. Check Hypervisor Access.Especially when changing IP addresses or making major changes, you need to be certain you can get access to the server. You don’t want to find that RDP doesn’t work and you can’t remember the vSphere password at 1am. Get ready before the change.
G. Confirm Forest Functional Level and Domain Functional Level.Before you promote a domain controller, you must ensure your domain functional level and forest functional level are compatible with the OS. If the DFL is Server 2008, you will not be able to join a Server 2025 domain controller. Use the following commands to check, then upgrade if necessary. Get-ADDomain | fl DomainModeGet-ADForest | fl ForestMode
H. Check Schema Version.Before you promote a domain controller, be sure to check that the schema version is compatible. The following command will produce a numeric value which you compare against the table. Get-ADObject (Get-ADRootDSE).schemaNamingContext -Property objectVersion
I. DNS Preferences.Domain controllers handle DNS queries from most workstations and servers in the business. If a PC needs to find PC1.YourDomain.com it will first go to the domain controllers for resolution. If it can’t be resolved, DNS will use the Conditional Forwarders you setup earlier and if that fails it will use Root Hints.
However, when the domain controllers themselves need to do DNS lookups the settings should be configured in a specific way. DNS Entry 1: IP Address of Nearest Domain Controller.DNS Entry 2: Lookback IP 127.0.0.1
This is now Microsoft’s supported and recommended approach. Yes, it used to be the other way around, yes that’s annoying – don’t go their girlfriend. Check these settings before and after you promote a domain controller. My settings were perfect and only after the promotion did I find that the first entry was ::1 (the IPv6 loopback address – which is incorrect).
J. Check DNS LogsWe have covered this already, it is always a good idea to review the DNS queries getting sent to the domain controller you are working on before making any changes. Are specific server communicating with it? Are applications hard coded to the hostname like DC1.YourDomain.com? Review “3. DNS Logs (Optional)” for more details.
Once the pre-requisite checks are complete, networking requirements are met, your change request is airtight, you have sent company emails or notifications, and you are confident with your backup and disaster recovery – finally we can promote a domain controller.
🔥Note! Microsoft no longer recommend using the DC Promo command. Hence, we are will use Server Manager.
Open Server Manager and select Promote this server to a domain controller.
Select Add a domain controller to an existing domain.
Enter your domain name, enter an account with domain admin privileges, and press Select. Choose your domain from the menu and press Ok.
Select Domain Name System (DNS) server and Global Catalog (GC) and enter the DSRM password. Do your business a favor and add the DSRM password into a password safe.
Select Next on the DNS Options page.
Select Any domain controller and click Next.
Leave the default options for the NTDS paths and click Next.
Review selections and click Next.
Review the results and select Install. When you promote a domain controller, it is usually safe ignore the following warnings “A delegation for this DNS server cannot be created because of the authoritative parent.”“Allow cryptographic algorithms compatible with Windows NT 4.0”
Once you promote a domain controller and complete the wizard, the server will restart and you will be left with a new integrated domain controller.
Once you promote a domain controller, you should perform Active Directory health checks and domain controller health checks to confirm everything is healthy.
After you confirm the paths for the database, log files, and SYSVOL folders (the defaults are usually fine), the wizard runs a final prerequisite check. As long as your planning was solid, it should pass, maybe with a few yellow warnings which are typically safe to ignore.
To be 100% sure everything is healthy, run these quick spot-checks:
C:Windows
After these checks and any others relevant to your business, you can rest easy knowing that your “Promote a Domain Controller” change request was successful.
After you promote a domain controller, you may now want to replace an existing one. This is common in environments because LDAP and other connections may be tied directly to an IP address.
Before you do this, I suggest reviewing the “Checks and Tests Before Changing Anything” section above.
Use the following table to logically lay out the IP address changes. This is done so 2 domain controllers never have the same IP address (a big no no).
🔥WARNING! Between each of the steps below, run IPCONFIG /FLUSHDNS and IPCONFIG /REGISTERDNS followed by a NET STOP NETLOGON and NET START NETLOGON. Restart the server and confirm DNS on all domain controllers to confirm IP has changed.
Also have a similar table ready for if you need to roll back the IP settings. Again, it is recommended to do the following after each step. Run IPCONFIG /FLUSHDNS and IPCONFIG /REGISTERDNS followed by a NET STOP NETLOGON and NET START NETLOGON. Restart the server and confirm DNS on all domain controllers to confirm IP has changed.
After you promote a domain controller, check stability and confirm there are now system wide outages, first things first you deserve a drink.
Now with a drink in hand, I would suggest using an Active Directory Monitoring Tool to keep an eye on your environment.
👉 The link above is for our in-house AD monitoring tool Monro Cloud Monitoring. It has been designed to be simple, so you have SMS notifications and Email notifications pre-configured and included in a very affordable price.
We have also made every effort to configure the tool so that the agent running on the domain controller is tightly locked down and not running as system – like many of our competitors.
The tool is not built like some of the other mainstream options to check that the DNS Service is running or that the NTP Service is running, that offers little value.
Our Active Directory monitoring tool provides the usual service monitoring and also key metrics like Active Directory replication. This ensures you are notified if a network engineer makes a change that breaks replication at 2AM.
With support included in every plan and a security cleared systems engineer ready to assist, there has never been a better time to shine a light on your IT systems with Monro Cloud Monitoring.
Thank you for reading my article and I hope you found it useful. Articles of this complexity take hours to piece together and I do it for the benefit of my IT brothers and sisters trying to learn.
I would absolutely love to hear from you. If I have missed something, you loved reading this content or you have suggestions for other content, please let me know. A friendly “Thank you” gives me great satisfaction to keep writing and sharing knowledge.
Email: Support@MonroCloud.com
