In this series, we’ll walk through a hands-on, zero-downtime Active Directory Domain Services (AD DS) migration from Windows Server 2016 to Windows Server 2025, including hybrid integration with Azure. The journey spans health checks, schema prep, introducing new 2025 domain controllers, tuning DNS and SRV records, transferring FSMO roles via PowerShell, decommissioning legacy DCs, reusing IPs, configuring time (NTP), deploying a DC in Azure, and finally raising functional levels. Each part is packed with best practices, PowerShell commands, and real-world tips gleaned from the field. Let’s dive in!

Cartoon of a cartoon of a beaver and a beaver holding a clipboard and a clipboard next to a tree with signs AI-generated content may be incorrect.

Admin Tip: Never perform an in-place upgrade of a domain controller via Windows Update or OS setup. Domain controllers are too critical. In-place upgrades can lead to extended downtime or unforeseen issues. Instead, we introduce new servers and migrate roles/services – the approach used in this series – to ensure a safe, zero-downtime transition. This method lets you fall back if needed and avoids impacting users during the migration.

Part 1: Verifying AD Health and Preparing for Migration

Before touching anything in your Active Directory, it’s crucial to verify that the existing environment is healthy. Think of it as giving your AD a thorough check-up before surgery. In this part, we’ll perform an AD health assessment and prepare our new Windows Server 2025 domain controller (DC) environment. Skipping health checks is like building a house on a shaky foundation – not a risk we’re willing to take.

Ensuring a Healthy Active Directory Environment

A migration will only be as smooth as the health of the current domain. We need to ensure replication is error-free, all domain controllers are communicating properly, and there are no lurking issues that could be amplified during the migration.

  • Run DCDiag on all DCs: DCDiag is the go-to tool for DC health. We run a comprehensive diagnostic on each DC (or enterprise-wide) to catch errors upfront. On each domain controller (or from one DC targeting all), run:
dcdiag /v /e > C:\AD_healthcheck.txt

This performs a verbose check of all DCs (/e tests entire enterprise). After it runs, review the output file for any failures or errors. Look especially for errors in the Advertising test, FRS/SYSVOL test, Connectivity, or Replication tests. All tests should pass before proceeding.

    • Verify SYSVOL and Netlogon shares: Every DC should have the SYSVOL and Netlogon shares present and accessible (this indicates that replication and file sharing are working). You can simply check by navigating to \\<DCName>\SYSVOL from another DC, or use net share on each DC to confirm the shares exist. If any DC is missing these, you have replication issues to fix before migrating.
    • Check AD replication status: Use Repadmin to ensure there are no replication failures:
repadmin /replsummary

repadmin /showrepl * /csv &gt; C:\repl_status.csv

The replsummary command summarizes replication health across all DCs, showing any failures and the largest replication latency. Ideally, you want 0 failures out of total attempts on all DCs. The showrepl (with * for all DCs) outputs detailed replication partner statuses. Look for any error states or large replication deltas. If there are issues, address them (for example, fix DNS resolution between DCs, ensure ports are open, or resolve lingering objects) before introducing new servers.

      • Check FSMO role holders: It’s useful to know which DC holds which Flexible Single Master Operations roles now. Run:
netdom query FSMO

This will list the current role owners (Schema Master, Domain Naming Master, PDC Emulator, RID Master, Infrastructure Master). Document these; by end of the migration, these roles will reside on our new 2025 DCs. For now, knowing the current holders ensures we perform certain steps (like schema prep) on the correct DC.

      • Review event logs: Open Event Viewer on each DC and look at the Directory Service, DNS Server, and File Replication Service (or DFSR) logs. Are there any critical errors or warnings (e.g. replication failures, USN rollback, time sync issues)? Resolve those. Common things to fix might include cleaning up old metadata of decommissioned DCs or fixing DNS lookup issues that cause replication hiccups.
      • Ensure functional level compatibility: Because we plan to add a Windows Server 2025 DC, verify the Domain Functional Level (DFL) and Forest Functional Level (FFL) of your AD. Windows Server 2025 requires that your domain and forest are at least Windows Server 2016 functional level. If your environment is currently at 2012 R2 (or lower), you’ll need to raise it to 2016 before introducing a 2025 DC. You can check this in Active Directory Domains and Trusts (right-click the domain > Properties) or via PowerShell:
Get-ADDomain | Select DomainMode, ForestMode

If it shows Windows2012R2Domain and you still have older DCs, plan to upgrade functional level to 2016 after those older DCs are gone. In our scenario (migrating from 2016), you should already be at 2016 mode, but it’s worth confirming.

Real-World Insight: In one production migration we handled, a hidden replication failure between two sites caused a seemingly routine schema update to fail halfway. We had to pause and fix that before proceeding. The lesson? Never skip health checks. As Cristal often says, “Trust, but verify.” By ensuring all DCs are in good shape now, we prevent nasty surprises during the critical migration steps.

By Cristal Kawula, CheckYourLogs.net