Replacing Active Directory domain controllers at Windows Server 2016 end of support

Replacing Active Directory domain controllers before Windows Server 2016 support ends

Each Windows Server 2016 domain controller needs its own decision before extended support ends in January 2027. Upgrade the controller to Windows Server 2025, replace it with a Samba AD domain controller, or keep Windows Active Directory for Windows and move Linux identity to FreeIPA. The right option depends on three things: how heavily the estate depends on Windows clients and Group Policy, how much of the estate runs Linux, and which functional level the forest needs. This is a per-controller decision, not one global switch. A forest can keep Windows domain controllers for Group Policy while Linux hosts move to FreeIPA, or it can replace only the controllers in one site. Start by inventorying each controller's role, site, FSMO holders, DNS duties and file-serving duties, because those roles decide which path each one can take.

Upgrading keeps the forest and its Windows tooling unchanged, and it carries licensing costs that should be checked before anything else. Windows Server 2025 is licensed per core, with a minimum of 16 cores per server and 8 per processor. Standard and Datacenter editions both need a Windows Server Client Access License for every user or device that accesses the server. Microsoft's pricing page lists suggested prices of 1,176 US dollars for Standard and 6,771 US dollars for Datacenter for 16 core licenses, and notes that prices vary by region, so ask a reseller for a quote built on your actual core counts and CAL count. Windows Server 2025 mainstream support runs to November 14, 2029, according to the Microsoft lifecycle page, so the upgrade buys a longer runway than the 2016 release does.

Samba AD and FreeIPA each need a specific check before a controller is retired. For Samba, confirm the forest functional level is supported (Samba supports the 2016 level since Samba 4.20), confirm the DNS backend is SAMBA_INTERNAL or BIND9_DLZ, and confirm that no domain controller doubles as a file server. For FreeIPA, the question is whether Linux identity can move while Windows stays on Active Directory. FreeIPA is not an Active Directory domain for Windows clients, and its IPA DNS domain must not overlap any domain in the AD forest. Test each path in a lab forest first, and check gaps in Group Policy and SYSVOL with the comparison and migration pages in this group before any production controller is demoted.

What the Windows Server 2016 end of support decision requires

Windows Server 2016 extended support ends in January 2027, and Windows Server 2025 is the current release, so each domain controller needs a documented replacement or upgrade path before that date. Whichever path you choose, the replacement has to carry the same directory job that Active Directory Domain Services does today.

Keep the forest and schema intact

Active Directory Domain Services stores users, computers and other objects, and it replicates that data to every domain controller in a domain, along with a schema, a global catalog and query and index mechanisms. Before any change, inventory the forest and domain functional levels, the schema extensions added by other products, and the global catalog placement. Ask any candidate platform to show how it reads and extends that schema, not only how it authenticates users.

Serve Windows clients and servers

Domain-joined Windows devices and Group Policy depend on the domain controllers answering Windows-integrated authentication with NTLM and Kerberos. List every application that uses LDAP, Windows-integrated authentication or header-based authentication, and every workstation and server that is domain-joined. Confirm that each one still authenticates after the first replacement controller is added, not only after the last one is removed.

Verify Group Policy and SYSVOL

Group Policy objects and their SYSVOL replication are requirements to verify in your own environment, not assumed behavior of any replacement. Export the current GPO list, check where SYSVOL content is replicated from, and test policy application on a pilot set of Windows clients. Record any policy that a Linux-based directory cannot apply, because those settings need another management method.

Keep DNS and replication working

Domain controllers depend on AD-integrated DNS and on replication between sites and peers, so a half-finished transition can break logons across the estate. Plan the DNS zones and their replication scope, the number of controllers per site, and the order in which roles move. Confirm that clients keep resolving service records while old and new controllers coexist, and document the rollback point for each step.

Test the recovery path

A replacement is not ready until a restore has been rehearsed against a copy of production data. Write down how each domain controller is backed up, who holds the restore keys, how long a restore takes in your own environment, and what happens if the last Windows controller is retired too early. Ask the platform team to demonstrate a restore in a lab before the Windows controllers are removed.

Which option fits which estate

This option keeps Active Directory Domain Services on Windows Server and treats the 2016 end of support as a scheduled in-place or side-by-side upgrade. It keeps Group Policy, SYSVOL replication, the Windows DNS integration and the Windows client experience exactly as they are today, so it carries the least application risk. The cost is the Windows Server license and lifecycle, which must be planned for each domain controller.

Licensing: Windows Server 2025 is licensed per core with a minimum of 16 cores per server and 8 per processor, and Client Access Licenses apply to users or devices that access the server. Confirm the count with your Microsoft partner or reseller.
Lifecycle: Windows Server 2025 mainstream support runs to November 14, 2029, which sets a horizon for the next upgrade cycle.
Operational fit: Group Policy, domain join and Windows-native authentication work without a translation layer.
Cost driver: Core count per domain controller, not the number of DCs alone, drives the license total.
Trade-off: You keep paying for Windows Server and CALs, and the estate stays tied to the Microsoft release cycle.

Before committing, confirm the current Windows Server 2016 DCs are on a supported forest and domain functional level, and get a written quote that separates core licenses, CALs and any Software Assurance or Azure Arc terms.

Upgrade, Samba AD or FreeIPA compared

This table compares the three paths for each Windows Server 2016 domain controller: upgrading to Windows Server 2025, moving to Samba AD, or moving Linux identity to FreeIPA. Read each row against your own Windows client count, Linux estate and DNS design, since the right answer often differs per domain. Gaps are marked as items to confirm, not as settled facts.

Criterion	Windows Server 2025	Samba AD	FreeIPA
License model	Per core, 16-core minimum per server and 8 per processor, plus a Windows Server CAL for each user or device accessing the server	GPL-3.0, no license fee for the software; support comes from a vendor or your own staff	GPL-3.0-or-later, community project with no paid edition of its own
Windows client support	Native domain services for Windows clients, Group Policy and domain join	Acts as an AD-compatible DC for domain-joined Windows clients; Group Policy and SYSVOL gaps must be checked for your estate	Not an AD domain for Windows clients; Windows users reach Linux resources through a cross-forest trust
Linux integration	Linux machines need third-party tools or Kerberos realm configuration	Linux clients join through standard Kerberos and LDAP configuration; confirm each client tool against your build	Built for Linux: SSSD on clients, Kerberos, sudo and host-based access control rules
DNS options	Windows DNS server role integrated with AD	SAMBA_INTERNAL and BIND9_DLZ backends; NONE is not recommended and BIND9_FLATFILE is not supported	Optional ISC BIND DNS with the integrated IdM setup; confirm DNS design with your network team
Functional levels	Windows Server 2025 is the current release; confirm the forest and domain levels you must keep for existing DCs	2008 R2 since Samba 4.0, 2012 and 2012 R2 since 4.19, 2016 since 4.20; raise levels with samba-tool	Not applicable in the AD sense; the IdM domain is its own directory
Supported release status	Mainstream support ends November 14, 2029; extended support ends November 15, 2034 (Microsoft Lifecycle)	Samba 4.25.0 is the current stable release; each series gets six months full support, six months maintenance and six months security fixes only	FreeIPA 4.13.4 was released July 9, 2026 with CVE fixes; plan upgrades on your own schedule and confirm the distribution packaging you use
What your team must operate	Windows Server administration, patching, Group Policy and AD tooling; licensing tracking	samba-tool administration, DNS, SYSVOL replication, idmap and Windows client testing; Linux and Samba skills	Replica topology, certificate authority, DNS and NTP, backup and restore, and Kerberos trust configuration
Known gaps to confirm	Costs recur with core counts and CALs; confirm list and reseller pricing for your region	Confirm Group Policy coverage, file server placement and any AD features your applications use before demotion	Confirm Windows-side policy needs; FreeIPA does not replace Windows domain-joined management

What Windows Server 2025 licensing adds for each domain controller

Windows Server 2025 is licensed per core, and the licensing model is the first cost to price when a domain controller is upgraded rather than retired. Each server needs at least 16 core licenses, and each physical processor needs at least 8 cores licensed, so a small two-socket domain controller is licensed for 16 cores even if it runs far less load. Microsoft's pricing page lists suggested prices of 1,176 US dollars for Standard and 6,771 US dollars for Datacenter for 16 core licenses, and notes that prices vary by region. Treat those figures as Microsoft's suggested list prices, not the amount your reseller or enterprise agreement will charge. The core licenses are a one-time purchase per server, with a Software Assurance or subscription decision on top that you should confirm separately.

Both Standard and Datacenter also require a Windows Server Client Access License (CAL) for every user or device that accesses the server. CALs are often the larger and more easily overlooked line, because they scale with the user and device population rather than with the number of servers. If you choose pay-as-you-go licensing through Azure Arc instead of perpetual cores, Microsoft's pricing page lists 33.58 US dollars per core per month, which recurs for as long as the server is enrolled. Ask the reseller to show the monthly Arc cost for each domain controller next to the one-time core cost, so the two options can be compared over the period you plan to run the servers.

Moving domain controllers to Samba AD does not remove every Windows licensing line. Other Windows servers, such as file, application or print servers, still need core licenses and CALs, and existing CALs may still be needed for users who reach those servers. Before you remove licenses, inventory which servers and services depend on the Windows domain and which ones only use it for authentication. In the quote, ask the reseller for an itemized list with core counts per server, CAL type (user or device), quantity, term, whether Software Assurance is included, the regional price basis, and any Azure Arc billing terms, and confirm the exact figures against your own agreement.

How to decide each domain controller before January 2027

This sequence turns a vague end-of-support deadline into a per-controller decision record. Each domain controller ends up with a named target (upgrade, Samba AD or FreeIPA), a tested recovery path and a scheduled cutover.

Inventory every domain controller and its roles
The directory or infrastructure team lists every domain controller in each forest and domain, including its Windows Server version, domain and forest functional levels, and the FSMO roles it holds. Record the sites and the DNS zones each controller hosts, and map the applications, scripts, file shares and Linux hosts that authenticate against it. The step is done when every controller has one row in a shared inventory that the application owners have reviewed and signed off.
Map Windows client and Group Policy dependence
Identify which workloads depend on Group Policy, SYSVOL replication, Windows-integrated authentication (NTLM and Kerberos), domain-joined clients and servers, and AD-only features such as certificate services or DNS scavenging. Note which of these a Samba AD domain controller supports and which need a different answer or a Windows controller kept in place. The output is a dependency register that lists each feature, its owner and whether it blocks a Samba DC for that domain.
Assign upgrade, Samba AD or FreeIPA per controller
For each controller, decide whether it moves to Windows Server 2025 with the licensing that implies, becomes a Samba AD domain controller in the existing domain, or is replaced for Linux identity by FreeIPA with a cross-forest trust. Record the reason in the register, and flag any controller whose role cannot move yet. Ask Windows Server 2025 licensing questions to a Microsoft partner or reseller, and confirm current Windows Server 2022 support dates in the Microsoft Lifecycle pages for mixed estates.
Build a lab copy and test each path
Clone the directory into an isolated lab network that mirrors the production DNS layout, functional levels and key applications. Join a Samba DC or a FreeIPA server to the lab, test client logons, Kerberos tickets, Group Policy or sudo rules, and the applications from the dependency register. Record each failure and its fix. The step closes when every planned path has a documented test run that the application owners accept.
Confirm backup and restore for every path
Take a current system state backup of each Windows controller and check that it restores in the lab. For FreeIPA, plan ipa-backup runs and confirm that a restore from an outdated backup is never loaded into an active replica topology. Verify that the first FreeIPA server still handles certificate renewal and CRL publication in your design. For Samba, confirm the backup of the sysvol and domain database. Record the recovery time you measured, and the owner who can execute it.
Schedule and run each cutover in order
Set a change window for each controller, starting with the least critical one, and move FSMO roles and DNS authority only after the new controller is verified healthy. Keep at least one Windows controller available until the Samba or FreeIPA replicas have held authentication for every application in the register. The cutover is complete when the inventory shows no unassigned roles, all clients resolve through the new DNS servers and the change record is closed with the test evidence attached.

Risks in the Samba and FreeIPA paths and the timeline to plan

The biggest risk in either path is assuming a Samba AD DC or a FreeIPA topology behaves like the Windows domain controllers it replaces. On the Samba side, DNS is the first gap to close. A Samba AD DC supports the SAMBA_INTERNAL and BIND9_DLZ DNS backends, the Samba wiki warns against the NONE backend, and BIND9_FLATFILE is not supported. Confirm which backend each domain controller will run before any promotion, check that existing Windows DNS zones and records are reproduced, and test name resolution from every client subnet. Also plan for Group Policy and SYSVOL. Compare the policy set you rely on today against what Samba supports, and test each policy on a pilot OU before moving production machines. Run file serving on a separate Samba domain member, not on the DC, as the Samba wiki recommends for multi-DC domains, which means budgeting for those extra servers.

On the FreeIPA side, the risk is replication topology. FreeIPA deployment recommendations call for at least two to three replicas in each datacenter, no more than four replication agreements per replica, dedicated servers without other applications, and at least one replica per datacenter running PKI or DNS if you use them. Design that topology on paper before building it, because a poor layout is expensive to correct later. The backup documentation adds a specific trap: restoring an outdated backup into an active replica topology can break replication, and the first server handles certificate renewal and CRL publication by default. Write a restore runbook that identifies the current server, records which backup is the most recent, and rehearses ipa-restore in a non-production copy.

On timing, the supplied lifecycle dates set the outer boundary. Windows Server 2016 extended support ends in January 2027, and Windows Server 2025 mainstream support runs to November 14, 2029, so any decision you defer past 2026 leaves little margin. Duration depends on estate size, the number of domain controllers, the number of applications bound to LDAP or Kerberos, and how much Group Policy and Linux identity must move, so ask each implementation partner for a written scope with phases and exit criteria before committing. Sequence the work as inventory, pilot, coexistence, role transfer and retirement of the last Windows DC, and keep the final demotion for after you have verified authentication, DNS and replication from every site. Confirm current Samba and FreeIPA release support with the project pages before choosing a version.

Questions buyers ask before replacing Active Directory domain controllers

How much does a Windows Server 2025 upgrade for domain controllers cost?

The cost is set by licensing, not by the upgrade itself: Windows Server 2025 is licensed per core, with a minimum of 16 cores per server and 8 per processor, and Standard and Datacenter editions both need a Windows Server Client Access License for every user or device that accesses the server. Microsoft's pricing page lists a suggested price of 1,176 US dollars for Standard and 6,771 US dollars for Datacenter for 16 core licenses, and notes that prices vary by region. The main drivers are the total core count across domain controllers, the edition you choose, the number of CALs your estate needs, and your reseller or agreement terms. Pay-as-you-go licensing through Azure Arc is priced at 33.58 US dollars per core per month. Ask your Microsoft partner or reseller for a quote built from your actual core counts and user and device counts, and confirm regional pricing with them.

Can Samba AD replace every Active Directory domain controller?

Samba AD can replace many domain controllers, but not every estate qualifies, so check your environment before you commit. Samba supports the 2016 functional level since Samba 4.20, and it can run with the SAMBA_INTERNAL or BIND9_DLZ DNS backends. Features that matter for Windows estates include Group Policy and SYSVOL replication, Windows client behavior and file serving, and the Samba wiki advises against using a domain controller as a file server when multiple DCs exist. Review your Group Policy use, DNS design and any applications that depend on specific Windows behaviors. The Samba wiki on setting up an AD DC is the natural starting point for the technical review.

How long does an Active Directory domain controller migration take?

The duration depends on the number of domain controllers, the functional level you must keep, how many applications authenticate against the domain, and how many change windows your organization allows. Replacement is staged: you join new DCs, check replication and functional levels, transfer FSMO roles, handle SYSVOL and identity mapping, and only then retire the old Windows DCs. Each stage needs testing and rollback planning. Because no supplied timeline applies to your estate, ask any implementation partner for a written schedule tied to a defined scope, and ask what testing and sign-off each phase requires. Samba's release planning also matters: each release series gets six months of full support, six months of maintenance and six months of security fixes only, with Samba 4.25 starting in September 2026.

Can our own team run an Active Directory replacement without outside help?

Some teams can, but the work needs skills in Active Directory, Kerberos, DNS, Linux administration and directory replication, and most teams lack all of them at the depth a domain controller requires. Your team should be comfortable with samba-tool for administration, with DNS and Kerberos troubleshooting, and with the rollback steps before demoting the last Windows DC. Ask yourself whether you have staff who have already run a domain controller migration and who can own the change windows. An outside partner can plan, implement, harden, document and support the work under a fixed-scope agreement, with ongoing support available as a retainer. Put the skills gap in writing before you decide which parts to keep in-house.

What access, change windows and owners does a domain controller migration need?

A migration needs administrative access to the domain, the DNS zones, the existing domain controllers and the servers and applications that authenticate against them, plus named owners for each application. You also need approved change windows for each domain controller, a rollback plan, and a clear decision on who signs off each phase. Ask for an inventory of every system using LDAP, Kerberos, NTLM or Group Policy before you start, and for a list of who owns each dependency. Confirm with your auditors and internal change board how evidence will be captured for each change, since DeployOpen prepares systems, controls and evidence but does not issue audit reports or certifications.

Can FreeIPA serve Windows clients as an Active Directory replacement?

No, FreeIPA is not an Active Directory domain for Windows clients. It is an identity and access management solution for Linux and UNIX networks that combines 389 Directory Server, MIT Kerberos, the Dogtag certificate system and SSSD on clients. Windows devices cannot domain-join a FreeIPA realm in the way they join an AD domain. The practical choice is different: use FreeIPA to take over Linux identity, Kerberos, sudo and host policies, and keep Windows domain controllers or Samba AD for Windows clients. FreeIPA can also establish a cross-forest trust with an Active Directory domain on Windows Server 2008 R2 or later, so AD users can reach Linux resources during a transition. Confirm the design with your architects before you assume any Windows client behavior.

Evidence to collect for the domain controller decision

Each domain controller decision rests on records that show what the estate looks like today and what a change would touch. The cards below cover the inventory, functional levels, replication health, restore evidence, licensing and the documented decision, so the team and any assessor can trace each choice back to a source. DeployOpen can prepare this evidence, but independent auditors issue any assurance reports.

Inventory of domain controllers and FSMO roles

List every domain controller, its site, its operating system version and its role in the forest. Record which DC holds each of the five FSMO roles (schema master, domain naming master, PDC emulator, RID master and infrastructure master), and which DCs host DNS, the global catalog or certificate services. This list tells you which Windows Server 2016 machines are in scope and which roles must move before any of them is retired. Confirm the list against the directory itself, not against an old spreadsheet.

Domain and forest functional level records

Record the current domain and forest functional levels and the operating system of every DC that could be promoted or demoted. A Samba AD DC can raise functional levels, but the Samba wiki documents which levels it supports and from which release, so the target level must be checked against the Samba version you plan to run. Keep the before and after values with the change ticket. A level that cannot be lowered in your environment is a constraint the decision must account for.

Replication health and SYSVOL status

Save the output of replication checks across all DCs, including the time of the last successful sync and any lingering objects or errors. Also record the SYSVOL replication method in use, since Group Policy depends on it and Samba's support for it differs from Windows DCs. Run these checks before and after each DC change, and keep the results with dates. Unresolved replication errors found during the inventory should be fixed or documented before any demotion starts.

Backup and restore test results

Keep a current system state backup for each DC and a dated record of at least one restore test in an isolated lab. A backup that has never been restored is not evidence of recoverability. For FreeIPA estates, the backup documentation warns that restoring an outdated backup into an active replica topology can break replication, so record which backup type was tested and where it was restored. Note who ran each test and what was verified.

Windows Server and CAL licensing records

Gather purchase records, software assurance or subscription status, and the license count for each Windows Server host, including the core count per server. Windows Server 2025 is licensed per core with a minimum of 16 cores per server and 8 per processor, and both editions need a Client Access License for each user or device that accesses the server. Separate the DC licenses that a Samba or FreeIPA move would retire from the CALs that still apply to other workloads. Confirm current pricing and terms with your Microsoft reseller or licensing agreement.

Documented decision for each domain controller

Record a decision for every DC: upgrade to Windows Server 2025, retire into a Samba AD coexistence path, or move Linux identity to FreeIPA. Each entry should name the owner, the evidence references, the date of the decision, the rollback plan and the approval. Keep the record with the inventory so the decision can be reviewed later. Note that DeployOpen prepares this evidence and the controls around it, while independent auditors issue any assurance reports.

How DeployOpen plans and runs a domain controller replacement

DeployOpen plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside your own infrastructure. For Windows Server 2016 domain controllers, we start from a written inventory of every DC, its role and its dependencies, then build the replacement path you choose, whether that is Samba AD, FreeIPA for Linux identity or a Windows Server upgrade you run yourselves.

How we scope

Inventory every domain controller, its FSMO roles, DNS zones, SYSVOL contents and Group Policy objects
List applications that bind to LDAP, Kerberos or NTLM and record which ones break under each option
Agree the scope, deliverables and timeline in writing before any work starts, as engagements are fixed-scope

How we build

Build test domain controllers in an isolated environment and check functional levels and DNS backends before production
Test Windows client domain joins, Group Policy behavior and authentication for each application on the list
Document each change, rollback step and cutover checkpoint so your team can repeat them without us

How we hand over

Deliver runbooks for replication health checks, backups, restores and the checks to run before demoting any Windows DC
Provide the export, validation and audit evidence your compliance team and independent auditors may request
Train administrators on the tools you will operate, such as samba-tool or FreeIPA administration commands

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after handover
Review patch releases and security advisories for the chosen platform and agree how updates are applied
Confirm with us in writing which support tier, response terms and upgrade cadence apply to your environment