In this article, I will describe the process of upgrading a Microsoft Active Directory Domain Controller (DC). Specifically, I will focus on scenarios where it is necessary to upgrade the operating system on which the Domain Controller is running.
A Domain Controller is a role that can be installed on a computer running the Windows Server operating system. All Windows Server versions, starting with Windows Server 2000, can be configured as Domain Controllers. When you install the Domain Controller role on a Windows Server, it enables Active Directory services—managing the AD database, responding to authentication requests, participating in replication with other Domain Controllers, supplying Group Policy to domain-joined computers, and performing many other essential tasks.
There are many articles on Microsoft’s website that describe the technical steps for upgrading a Domain Controller, including procedures like running adprep and forestprep. However, these resources often lack guidance on how to minimize risk, control downtime, ensure compatibility, or perform rollbacks during the upgrade process.
From my experience performing numerous upgrades—and encountering upgrades managed by others—I’ve learned that inadequate planning in these areas can have serious consequences. If you overlook risk management, downtime control, or compatibility checks, your Active Directory infrastructure (and sometimes your entire IT environment) can stop functioning properly after an upgrade.
Reasons for Upgrade:
There are numerous reasons that may require you to upgrade a Domain Controller. The most obvious is when the operating system running the Domain Controller reaches its “end of life” and becomes insecure. For example, after Windows Server 2008 reached end of life, it no longer received security patches, updates, or service packs. In such cases, upgrading to a newer version of the operating system is necessary to maintain security and support.
Other reasons for upgrading include improved security features, access to new functionalities, enhanced performance, and better compatibility with modern applications and services.
Domain Controller Importance:
Microsoft Active Directory Domain Services is a remarkably stable technology—Microsoft has not made significant changes to its core functionality over the years. As a result, Active Directory running on Windows Server 2003 is quite similar to that on Windows Server 2019. This stability often leads companies to avoid frequent upgrades of their Domain Controller operating systems, following the old adage: “If it works, don’t touch it!” 😊
This mindset explains why many organizations still run Active Directory on Windows Server 2008 (which is already beyond its end of life) or Windows Server 2012 (which will reach end of life soon).
The number of Active Directory (AD) clients consuming services provided by domain controllers is increasing over time. The services offered by domain controllers are extremely critical, making any downtime a matter that requires extensive planning—including risk management, rollback strategies, and backup and restore procedures.
Examples of services typically provided by a domain controller include:
- Authentication for domain members running Windows operating systems.
- DNS services for Windows and other TCP/IP devices (this group can be very large and may include almost any networked device).
- LDAP services for custom applications.
- NTP services for various TCP/IP devices.
All of these services are highly critical, and the list of clients relying on them can be both large and dynamic, especially in global organizations.
Domain Controller Upgrade Challenges:
a. DC Services Unavailability During Upgrade
Upgrading a domain controller means that the network services it provides will be unavailable for the duration of the upgrade process. None of the dependent clients will be serviced, which can lead to high-priority incidents. This is especially critical in large environments where Active Directory spans multiple countries and continents.
b. Compatibility Issues
Running a domain controller on a newer operating system often changes the way it delivers services, potentially leading to compatibility issues. For example, consider an environment with several hundred LDAP clients, many of which are non-Windows systems such as various versions and configurations of JBoss. If all these clients work well with a domain controller running Windows Server 2012, it is possible that after upgrading the domain controller to Windows Server 2019, some may no longer be able to authenticate. Similar issues can arise even from routine security patches. While planning for such changes falls under change management, an operating system upgrade is a much larger system change than standard security patching and can impact a significantly greater number of services and client systems.
The purpose of this article is to describe various Domain Controller operating system upgrade strategies, with a particular emphasis on analyzing potential downtime and rollback plans.
There are three basic strategies for upgrading a Domain Controller:
| Name | Description | Pros | Cons |
|---|---|---|---|
| In-Place Upgrade | Upgrade the existing Domain Controller to a new OS on same hardware using the provided installation media. | Easy to execute | Unpredictable or uncontrolled consequences- Difficult to roll backYou lose the old OS but do not get a clean installation; the upgraded OS may retain misconfigurations and unnecessary software leftovers |
| Add New DC. Called “Staged Domain Controller Replacement” or just “DC Replacement” | Add a new Domain Controller to the domain, transfer all roles and services to it, and, after confirming no clients use the old DC, demote the old DC. | – No downtime for the old DC – Simple rollback plan that does not affect the old DC – Well-controlled process, as the old DC runs in parallel with the old IP and hostname; clients can be moved in batches and rolled back if needed – Good opportunity to inventory all DC clients | – Time-consuming and potentially expensive |
| Replace Old DC (aka swing upgrade aka side-by-sside upgrade) | Change the name and IP of the old DC, install a new server, assign the old DC’s name and IP to the new server, and promote it to Domain Controller. | Fast and cost-effective | Downtime for the old DC will occurAfter the new DC replaces the old DC, some systems may experience compatibility issuesRollback plan affects both the new and old DC, making it riskier |
In-Place Upgrade
Rarely used, I do not cover it in this article
DC Replacement
My favorite scenario. All steps are standard operations like installing additional DC in the same domain. Let’s cover with some details “deprioritization” of old DC and methods for checking which clients still use old DC after “deprioritization”.
For “deprioritization” we usally use 2 methods:
- AD Site reconfiguration based “deprioritization”
- DNS SRV record weight and priority adjusting
Lets discuss them with more details with examples:
DC Replacement: AD Site reconfiguration based “deprioritization”
Scenario
Subnet: 192.168.0.0/24
Site: Default-First-Site-Name
Domain Controllers: DC1 and DC2 (both in the same site and subnet)
Clients: Windows 10/11, all in 192.168.0.0/24
Goal
You want clients to prefer DC1 for authentication and other AD services, and “deprioritize” DC2 (so it gets minimal or no client connections, but remains online).
Step-by-Step Example
1. Create a New Site for DC2
Open Active Directory Sites and Services.
Right-click Sites and select New Site (e.g., name it “Deprioritized-DC-Site”).
Associate the new site with the same site link as your main site.
2. Move DC2 to the New Site
In Sites and Services, expand Default-First-Site-Name > Servers.
Drag DC2 from Default-First-Site-Name to Deprioritized-DC-Site.
3. Subnet Assignment
Ensure that the subnet 192.168.0.0/24 is still associated with Default-First-Site-Name.
Do not associate the subnet with the new site (“Deprioritized-DC-Site”).
4. Result
Clients in 192.168.0.0/24 will be associated with Default-First-Site-Name and will prefer DCs in that site (DC1).
DC2, now in a different site with no associated subnet, will not be preferred by clients in 192.168.0.0/24.
DC2 will only be used if DC1 is unavailable or for inter-site referrals.
DC Replacement: DNS SRV record weight and priority adjusting
Suppose you want clients to prefer DC1 and deprioritize DC2.
Default SRV Record (Typical)
_ldap._tcp.dc._msdcs.yourdomain.com
DC1: Priority = 0, Weight = 100
DC2: Priority = 0, Weight = 100
Adjusted SRV Record (Deprioritize DC2)
DC1: Priority = 0, Weight = 100 (default, highest preference)
DC2: Priority = 10, Weight = 10 (higher priority value, lower weight)
Result:
Clients will always try DC1 first. Only if DC1 is unavailable will they attempt to use DC2.
Alternative (if you want DC2 as a backup only)
DC1: Priority = 0, Weight = 100
DC2: Priority = 100, Weight = 0
Result:
DC2 will only be used if DC1 is completely unreachable.
DC Replacement: client inventory
After “deprioritazion” you need to check which clients still using old Domain Controller.
You cn use following methods:
- Collecting NETSTAT (good for TCP connections like LDAP, unfortuntely doesn’t collect UDP connections like DNS)
- DNS log parser
- You can ask network team to provide you connections statistics, or use a sniffer on dc to inventory connections
Swing upgrade
This table contains sample actions needed to perform Swing upgrade:
| Approx. Duration | Old DC Actions | New DC Actions |
|---|---|---|
| Actions before upgrade | Export SSL certificates with private key | |
| Install Network Monitor | ||
| Check Event Viewer for errors | ||
| 2–3h | If the server runs non-AD services (e.g., WINS or DFS), remove it from replication. | |
| 10m | If the Old DC holds FSMO roles, transfer them to another DC in this domain. | |
| 10m | Set the local administrator password if not known; remove NLA requirement from RDP settings. | |
| 1–2h | Demote the Old DC. | |
| 10m | Remove from AD domain and restart. | |
| 10m | Rename to <servername>-old and restart. | |
| Change IP to a temporary value. | ||
| 30m–1h | Ensure the old name is not in DNS; check AD metadata and perform cleanup if needed. | |
| 10–20m | Point DNS to an existing DC not affected by this change. | |
| Change name to the old DC name, restart, and verify the new name is registered in DNS. | ||
| 10–20m | Assign the old DC’s IP address, restart, and perform checks. | |
| 2–3h | Promote the new DC (restarts will be required). | |
| 20m | Install SSL certificates; check and configure NTP as previously set in CMO. | |
| 10m | If this is a FSMO server, move FSMO roles back. | |
| 2–3h | If the server runs non-AD services (e.g., WINS or DFS), add it back as a replication partner. | |
| 1–3h (up to one week for next DC pair upgrade) | Perform post-demotion checks. | Perform post-promotion checks: run diagnostics on the new DC, check replication and AD client connectivity. |
The information provided in this article is intended for general guidance and illustrative purposes only. While I have shared examples and recommendations based on personal experience and industry best practices, every Active Directory environment is unique. The steps and suggestions described may not be suitable for all scenarios, and there may be technical details or requirements specific to your organization that are not covered here.
Before performing any domain controller upgrade or related changes, please consult official Microsoft documentation and consider seeking advice from qualified IT professionals. The author is not responsible for any issues or damages resulting from the use of this information as a definitive guide.
