Windows Server 2016 DHCP, DNS and NPS: Move Them Without Breaking the Network

DHCP, DNS and Network Policy Server (NPS) are the small services nobody thinks about until a laptop cannot get an address, a name will not resolve or Wi-Fi sign-in stops. On many networks all three sit on the same Windows Server 2016 machine, often a domain controller. This guide treats them together because they are usually moved together, but gives each its own verdict, commands and rollback. Sources checked 6 November 2026 against Microsoft Learn and Microsoft Lifecycle; they are listed at the end.

Verdict

Verdict: DHCP Either. DNS Either. NPS Migrate.

Microsoft's role matrix supports in-place upgrade and migration for DHCP and DNS, and Microsoft documents an export and import for NPS, with no explicit in-place verdict, so treat NPS as a side-by-side move.

Microsoft's DHCP migration guide goes further than the matrix: it says migration is recommended instead of an upgrade, even when the hardware is x64. And all three guides assume the source server does one job. The DHCP guide states it does not cover source servers running multiple roles, so if your server also does file sharing or domain control, separate the roles first.

Who this is for and what changes on the end-of-support date

This is for anyone running the DHCP Server, DNS Server or Network Policy Server role on Windows Server 2016, including a branch-office domain controller that does all three.

Microsoft Lifecycle lists Windows Server 2016 under the Fixed Lifecycle Policy. The Lifecycle table shows the extended support end as 1/13/2027 6:59:59 AM, while Microsoft's extended security updates page names 12 January 2027. Plan to finish before 12 January 2027.

Nothing stops answering on the day. What stops is security updates unless you buy Extended Security Updates, on servers that every device on the network talks to and that, for NPS, hold the shared secrets for your wireless and VPN equipment. On ESU, Microsoft's Azure Arc documentation says Windows Server 2016 reaches end of support on January 12, 2027, and that Extended Security Updates provide Critical and Important security updates for up to three years, through 2030, without new features, customer-requested nonsecurity hotfixes or design change requests. Arc-enabled ESU can be configured in the Azure portal from August 3, 2026, and its billing begins January 13, 2027. Standard and Datacenter editions are supported; physical-core licences need at least 16 cores per machine, and virtual-core licences need at least 8 per VM and use Standard. You must attest to Software Assurance or an equivalent server subscription, or license through SPLA. The pages I read show no price, so get a quote. Microsoft describes ESU generally as a last resort paid option and a temporary bridge, so treat it as a way to finish a migration, not as the plan.

Decision table

For the Azure row: I did not find a Microsoft page that replaces these roles with a hosted service, so a role on an Azure VM follows the same procedure as any other new server.

Steps, with the rollback point

DHCP

1. Inventory. Run Get-DhcpServerv4Scope | Format-Table ScopeId, Name, State, Get-DhcpServerv4Failover, Get-DhcpServerv4Reservation -ScopeId <id> and Get-DhcpServerInDC. Note relay agents and IP helpers on routers and switches.
2. Back up. Take a DHCP-specific backup with Backup-DhcpServer -Path C:\DhcpBackup; Microsoft says the backup should be DHCP-specific, not a full Windows backup. Rollback point: this backup, plus the source server left intact.
3. Failover pair? Microsoft's failover migration steps are: delete the failover relationship on the first server with Remove-DhcpServerv4Failover -Name <name> (which removes the scopes from the partner), export server-level settings with Export-DhcpServer -ComputerName <old> -File C:\export\dhcp.xml, import with Import-DhcpServer -ComputerName <new> -File ... -BackupPath C:\backup\ -ServerConfigOnly -Force on both new servers, then configure failover with the old and new server so leases replicate, delete that relationship and configure failover between the two new servers. To undo an import use Restore-DhcpServer with the backup path.
4. Single server? Install Windows Server Migration Tools on both servers, stop the DHCP service on the destination, run Export-SmigServerSetting -featureID DHCP -User All -Group -IPConfig -path <store> on the source, deauthorize the source with netsh DHCP delete server <FQDN> <IP>, import with Import-SmigServerSetting, start the service and authorize the destination with netsh DHCP add server <FQDN> <IP>. Do not import the source IP address while the source is still on the network, or you create an address conflict.
5. Verify. netsh DHCP show server must list the new server; run ipconfig /renew on a client; check scopes, reservations and options in the DHCP console. Update DHCP relay agents, then stop the old DHCP service.

DNS

1. Inventory. Get-DnsServerZone | Format-Table ZoneName, ZoneType, IsDsIntegrated, ReplicationScope tells you which zones are AD-integrated and which are file-backed. Record forwarders (Get-DnsServerForwarder), conditional forwarders, root hints and scavenging settings.
2. AD-integrated zones. Microsoft notes that AD-integrated zones remove the need for secondary zones and zone transfers, so on a domain controller you add the DNS role to the new controller and the zones replicate with the directory. Then point clients and DHCP option 6 at the new address.
3. File-backed zones. Microsoft's zone-move article converts AD-integrated zones to standard primary, stops DNS on both servers, copies the %SystemRoot%\System32\DNS folder, exports the two Zones registry keys, imports them on the destination, moves the IP address, and runs ipconfig /registerdns. It is an older article written around Windows 2000, so rehearse it. It states that interfaces, forwarders, advanced settings, root hints, logging and security are not migrated; recreate them by hand.
4. Verify. Check the SOA and NS records name the right servers, resolve internal and external names from several clients, and confirm domain controllers re-registered their SRV records. Rollback point: the old DNS server, still holding every zone, until clients have used the new one for a full cycle.

NPS

1. Check versions. Microsoft says not to import if the source NPS database version is higher than the destination's; compare with netsh nps show config.
2. Export. Export-NpsConfiguration -Path C:\npsconfig.xml, or netsh nps export filename="C:\npsconfig.xml" exportPSK=YES. Microsoft states the XML is not encrypted and contains the shared secrets for RADIUS clients and remote RADIUS server group members, so move it only inside an encrypted, password-protected archive and delete every copy afterwards. SQL Server logging settings are not exported.
3. Import. On the destination run Import-NpsConfiguration -Path C:\npsconfig.xml. Microsoft notes an import overwrites the existing configuration rather than adding to it.
4. Repoint and test. Update RADIUS client definitions on access points, switches, firewalls and VPN gateways, then test wired, wireless and VPN authentication with one real user for each policy. Reconfigure SQL logging if you used it. Rollback point: the old NPS server and its exported file, kept until every device authenticates against the new one.

Mistakes that cause outages

• Importing the source IP onto the new DHCP server while the source is live. That creates an address conflict.
• Forgetting authorization. An unauthorized DHCP server in a domain will not hand out leases.
• Leaving relay agents pointed at the old server. Remote subnets keep asking a server you have turned off.
• Failover partner mismatch. Server-level options, classes and policies must exist on both new servers before you build the relationship.
• Losing forwarders and root hints. Microsoft's DNS zone-move steps do not carry them; internal names work and external names silently fail.
• Moving DNS before domain controllers register. Check SRV records afterwards.
• Leaving the NPS export lying around. It holds unencrypted shared secrets.
• Importing NPS over a live configuration by mistake. The import overwrites.
• Moving a multi-role server in one go. Microsoft's DHCP guide excludes it; split the roles first.

Checklist

• DHCP scopes, failover, reservations, relay agents and authorization recorded
• DHCP-specific backup taken; failover or single-server migration chosen
• DNS zones classified as AD-integrated or file-backed; forwarders and root hints recorded
• NPS database version checked; export secured and later deleted
• Clients, relays, RADIUS clients and DHCP option 6 repointed
• Each service tested from real devices
• Old servers kept intact for a business cycle
• Finish before 12 January 2027

Related tools and reading

The Windows Server 2016 end-of-support planner gives a starting verdict for each of these roles, and our subnet calculator and reverse DNS name generator help when you rebuild scopes and PTR zones. If the server is also a domain controller, read the domain controller guide first. The full series is in the role-by-role guide.

Sources

Checked 6 November 2026.

• Windows Server 2016 on Microsoft Lifecycle
• Extended Security Updates for SQL Server and Windows Server
• Prepare to deliver Extended Security Updates for Windows Server through Azure Arc (2016 dates, coverage, Software Assurance)
• License provisioning guidelines for Extended Security Updates for Windows Server (editions, core minimums)
• Billing service for Extended Security Updates for Windows Server through Azure Arc (billing start)
• Product Lifecycle FAQ: Extended Security Updates
• Upgrade and migrate roles and features (DHCP and DNS rows; NPS migration guide listing)
• Migrate DHCP Server to Windows Server
• Migrate existing DHCP failover deployment
• How to move Windows DNS zones to another Windows server
• DNS and AD DS
• Export an NPS configuration for import on another server

General planning information, not a design for your environment. Test on a spare subnet or a lab first.