About this article: AI-assisted writing, reviewed against the cited sources. This is source research, not a lab validation of the procedures. Check the stated versions and your own recovery requirements before making changes.
A recovered Network Policy Server is useful when the right connection is accepted, the wrong connection is rejected, and the required accounting record reaches its destination. An imported XML file is an intermediate result. It does not establish any of those outcomes by itself.
NPS often sits behind equipment people encounter first: wireless access points, switches and VPN gateways. A failure can therefore look like a wireless outage, a broken VPN or an application login problem. The recovery plan must identify which component makes the access decision before someone starts changing passwords or weakening policies to restore connectivity.
This article covers configuration-based recovery of the Windows NPS role. It does not provide a forest recovery procedure, a certificate-authority restore, or instructions to repair a third-party authentication extension. The workflow and acceptance matrix below are editorial recommendations grounded in Microsoft's documentation. They have not been run in a lab.
Identify the service you are recovering
Microsoft's NPS overview distinguishes a RADIUS server that evaluates access from a RADIUS proxy that forwards requests. A deployment may use both roles. Write down where the decision occurs and where accounting goes; recovering the proxy does not prove that its upstream authentication service is available.
A useful inventory follows one connection from the device to its outcome. Record the access device, the NPS address it contacts, the connection request policy, the network policy or remote server group involved, and the accounting destination. Include the system owner who can explain an unexpected rejection. This inventory is your map for diagnosis after recovery, not a substitute for the export.
Treat any installed MFA or other extension as a separate recovery workstream with its own version-specific documentation and acceptance test. Do not infer that restoring the base NPS settings reinstalls an extension, renews its credentials or recreates an external service relationship. Record that dependency explicitly rather than claiming the whole authentication service passed because ordinary RADIUS traffic reached Windows.
Preserve configuration changes as they happen
Microsoft's best-practice guidance recommends saving the NPS configuration after installation and configuration, and again after changes. That matters when the latest machine backup predates a newly added gateway or revised access policy.
For each recovery copy, retain a nonsecret manifest with the source server identity, Windows version and build, capture time, approved change reference and intended recovery target. Record whether the export was taken before or after a relevant secret rotation. Keep the manifest separate from sensitive file contents so an incident coordinator can find the right generation without opening a credential-bearing XML document.
The Export-NpsConfiguration reference documents a critical limitation: shared secrets for RADIUS clients and remote server-group members are present without encryption. It also excludes SQL Server logging settings. Protect the export in transit and at rest, restrict retrieval to the recovery roles, and use controlled handling for temporary copies. Do not attach it to a ticket, paste it into chat or include its contents in a public verification report.
This makes an export materially different from a screenshot of a policy list. It can help rebuild the service, but possession of it also exposes authentication infrastructure secrets. The backup process needs a tested way to retrieve the protected file when the source server is unavailable, without depending on a password remembered by one administrator.
Import is replacement, not a merge
Microsoft's configuration-transfer procedure says importing replaces the destination configuration. It is not an additive import. The same procedure prohibits moving from a higher NPS database version to a lower one and identifies netsh nps show config as the way to view that version.
Choose a prepared recovery target under an approved change plan. Preserve any destination configuration that must survive, confirm the version relationship, and keep the target out of normal authentication traffic while it is being prepared. A second production NPS is not an empty test host merely because it is usually quiet: replacing its settings can affect clients already relying on it.
The Import-NpsConfiguration cmdlet reads the saved file into NPS. Its successful completion establishes that the import operation completed, not that a gateway uses this server or that a client trusts its certificate. Use a post-import inventory to compare expected clients, policies and server groups before moving to connection tests.
A recovery plan should also name the reversal point. If the test target fails, stop sending test requests to it and investigate while the previous service path remains controlled. Do not overwrite the only recoverable configuration while trying different generations, and do not send production devices to the new server simply to discover what is missing.
Recover both sides of each RADIUS relationship
In Microsoft's RADIUS client configuration guidance, the RADIUS client is the network access device, such as a VPN server or access point. It is not the laptop or person asking for access. NPS and that device must agree on the configured relationship and shared secret.
A restored export can contain an older secret than the device currently uses. Inventory the effective configuration at both ends through authorised administration; never solve a mismatch by guessing which secret is newest. Choose the intended generation and use a coordinated rotation if the secret may have been exposed. Record the change reference and outcome, not the secret itself.
Address changes need the same two-sided treatment. A new NPS address is useless if the gateway still sends requests to the failed address. Conversely, a gateway using a different source address may no longer match the client entry you restored. Proxies and network address translation can complicate the apparent source, so establish the actual path from observations instead of assuming the diagram is current.
Microsoft's post-change verification guide calls out RADIUS-client and proxy configuration, SQL connectivity, IPsec rules and adapter bindings after an NPS address change. Use those as separate checks. Copying a hostname or importing a policy cannot silently repair each external reference.
Check ports and reachability without broadening access
The NPS UDP-port documentation lists default listeners on 1812 and 1645 for authentication, and 1813 and 1646 for accounting, across installed IPv4 and IPv6 interfaces. The deployment may use different settings. Check what the recovered server and devices are configured to use; do not open every documented port as a generic repair.
Separate three observations: the device sent a request, the intended NPS received it, and the device received the response. A missing packet and an explicit access rejection are different faults. An ICMP reply does not establish that the required UDP exchange works, while a blocked ping does not establish that it cannot.
Use a controlled test path that cannot accidentally become the authentication destination for all production clients. Where an isolated environment needs directory or certificate services, document those dependencies and limit any approved connectivity. Do not bridge the recovered server into production simply because a test dependency is inconvenient to reproduce.
A policy reference is not an installed server identity
For EAP-TLS, PEAP-TLS and PEAP-MS-CHAPv2 deployments, Microsoft's certificate-management guidance requires an appropriate server certificate and client trust in its issuer. It describes selecting the certificate in each relevant network policy and checking the bound certificate. Treat that selection as a verification task after recovery.
The operational question is whether the recovered machine can use the required identity, not whether an export contains a thumbprint. Record the selected certificate, validity period, trust requirements and a supported way to provide the necessary private-key capability. That may mean approved recovery of existing key material or enrolment of a replacement certificate. A public certificate file alone does not supply a private key.
Client-side trust and expected server identity are also part of acceptance. Do not disable certificate validation to make a test pass. If a newly enrolled certificate changes what clients must trust or identify, coordinate that change through the normal client-policy process and test representative managed clients. Keep the certificate change distinct from the NPS configuration import so the incident record shows which action changed the result.
Some reconnects can use cached TLS state, as Microsoft's certificate page explains. Include a fresh authentication in the acceptance plan rather than treating an already-connected client's continued access as proof that the new server identity works. This article does not recommend changing TLS cache settings to manufacture that test.
Directory permissions and policy order still matter
Microsoft's NPS registration guidance explains that registration adds the server to the relevant domain's RAS and IAS Servers group so it can read user dial-in properties. For a replacement member server, verify the required registration and directory access in the domains that hold the accounts being authorised.
An XML import does not demonstrate that the replacement computer account has the same effective directory permissions as the old one. Record the actual computer identity and permitted domains. A local sign-in to the recovered Windows server is not a test of the directory-dependent network access decision.
The NPS server-planning guide describes ordered network-policy matching and rejection when no policy matches. Compare the recovered order and conditions with the approved configuration. A policy existing in the console is insufficient if a different rule handles the request first.
Test at least one intended admission and one intended rejection. Use designated test identities and avoid attempts that could lock out real users. A recovery that admits everyone has restored connectivity by losing the access control; it has not restored the intended service. Record the expected matched policy as well as the outcome so a broad rule cannot hide behind one successful connection.
Accounting can affect service availability
The NPS accounting guide distinguishes local logging and SQL-based accounting, and provides a setting controlling what happens when logging fails. Recreate the required SQL logging configuration separately, then check connectivity, permissions and whether records actually arrive. Preserve historical accounting records according to their own retention requirements; the configuration export is not evidence that those records were backed up.
Inspect the configured logging-failure action rather than assuming authentication will always continue. A recovered server with correct access policies but an unavailable accounting destination can behave differently from what the recovery team expects. Exercise that failure condition only in a controlled test, and do not change the organisation's required accounting behaviour merely to obtain a green connection result.
For local logging, include the target path, capacity and authorised access in the recovery inventory. For SQL, include the destination and required connection configuration without publishing credentials. A record appearing somewhere is not enough if the accepted operational destination remains empty.
Define the evidence that closes recovery
Microsoft's 802.1X troubleshooting guidance identifies NPS Security events 6272 for accepted attempts and 6273 for rejected attempts, with reason information useful for investigation. Use those events alongside the access device and endpoint observations. An NPS acceptance alone does not prove the endpoint received the intended network access.
A practical acceptance matrix can remain short:
| Test | Required observation | Scope limit to record |
|---|---|---|
| Designated allowed identity | Fresh authentication accepted by the intended policy and usable access at the endpoint | Access method, device class and route tested |
| Designated denied identity | Rejection consistent with the intended rule | Other denial cases not exercised |
| Certificate-based connection | Expected server identity validated without disabling client checks | Trust configuration and client policy used |
| Accounting | Correlated record reaches the required destination | Historical records are a separate recovery item |
| Alternate authentication path | Approved secondary or proxy path behaves as designed | Do not infer failover from one-server testing |
Keep timestamps, the recovered configuration identity, policy names, observed events, certificate identifiers and outstanding findings. Exclude shared secrets, exported XML contents and unnecessary personal data. State whether the evidence comes from an isolated rehearsal or an authorised service cutover.
Finally, retain a protected export of the accepted configuration and update the recovery inventory when an approved change alters it. The useful result is a repeatable recovery path: the file is available, dependencies are identified, access decisions remain correct and accounting survives the move. This source-researched guide does not claim that any particular NPS installation has passed those tests.
Sources
Microsoft Learn documentation retrieved 13 November 2026:
- Network Policy Server overview.
- NPS best practices.
- Export-NpsConfiguration and Import-NpsConfiguration.
- Export an NPS configuration for import on another server.
- Configure RADIUS clients and verify configuration after NPS changes.
- Configure NPS UDP port information.
- Manage certificates used with NPS.
- Register an NPS in an Active Directory domain and plan NPS as a RADIUS server.
- Configure NPS accounting.
- Troubleshoot 802.1X authentication.
This article was originally published on .