Deploy Windows Server 2025 DHCP scopes, reservations, and failover
Build an authorized two-server DHCPv4 service with reviewed IPAM, inactive-first scope creation, internal DNS options, shared secure updates, reservations, load-balanced failover, relay and maintenance tests, and isolated recovery.
Deliver predictable client addressing through either partner without exposing failover/DNS secrets, creating duplicate ownership, relying on one relay, or treating AD authorization as protection from rogue devices.
- Windows Server 2025
- DHCP Server 2025
- Active Directory Domain Services 2025
- Windows PowerShell 5.1
- Healthy identity and DNS Accepted AD DS and two AD-integrated DNS servers with secure dynamic updates, replication, time, monitoring, and recovery.
- Two DHCP hosts Patched Windows Server 2025 domain members with fixed addresses, independent failure domains, controlled interfaces, console access, and TCP 647 between partners.
- IPAM and relay design Approved scope/subnet, pool, exclusions, statics, reservations, options, lease/capacity model, two relay targets, ACLs, and Option 82 behavior.
- Secret and identity handling Dedicated least-privilege DHCP DNS update identity, unique failover shared secret, trusted nontranscribed sessions, escrow, rotation, and audit process.
- Failure and recovery Fencing method, named partner-down authority, MCLT/state runbook, protected export/backup storage, isolated restore network, and monitoring.
OneLiners never runs these steps or stores secrets. Review placeholders, versions, current state, and change-control requirements before using a command.
Full guide
What you will build
- Two authorized Windows Server 2025 DHCP servers with one inactive, reviewed IPv4 scope containing exclusions, standard options, reservations, secure DNS-update behavior, and measured capacity.
- A load-balanced DHCP failover relationship using TCP 647, synchronized time, an interactively supplied shared secret, manual configuration replication, redundant relay paths, and safe activation.
- Monitoring, audit, protected exports/backups, isolated recovery rehearsal, and a fenced partner-down procedure that prevents split brain.
- Clients on the target subnet obtain valid leases, gateway and DNS settings through either partner, and reserved clients receive their assigned address.
- Both servers show NORMAL failover state and identical scope configuration, while A/PTR updates use the same dedicated identity and remain correct after a partner switch.
- Operators can distinguish service availability, configuration replication, lease-state replication, MCLT, COMMUNICATION INTERRUPTED, PARTNER DOWN, and restoration without unsafe guesswork.
Architecture
How the parts fit together
DHCP01 and DHCP02 are domain members on independent failure domains. Both are authorized in AD and reachable from each client VLAN through redundant DHCP relays. One reviewed scope is created inactive on DHCP01, paired to DHCP02 through a load-balance relationship, synchronized, and then activated. Both use the accepted internal DNS pair and identical dedicated DNS update credentials. Monitoring reads audit/event channels and scope/failover counters; protected exports and backups are restored only on an isolated network.
- A client broadcasts DHCPDISCOVER and the redundant relay forwards it to both partners.
- The failover relationship deterministically selects a responding server and records the lease in both databases.
- The client receives address, mask, gateway, internal DNS, and domain options and validates network/domain reachability.
- The designed updater creates or refreshes secure A/PTR records; failover partners share the same updater identity.
- Configuration changes originate on the reviewed authoritative partner and are manually replicated; monitoring observes state, utilization, time, DNS, and audit evidence.
Assumptions
- The AD forest and two Microsoft DNS servers are healthy, and DHCP01/DHCP02 are clean patched Windows Server 2025 domain members with fixed addresses and independent failure domains.
- This guide implements DHCPv4 failover. Microsoft DHCP failover does not support DHCPv6 scopes; IPv6 high availability requires a separate documented design.
- IPAM/network owners approved the subnet, dynamic range, exclusions, static assignments, gateway, DNS addresses, lease duration, reservations, relay paths, and capacity thresholds.
- Both failover partners synchronize time through the AD hierarchy and can communicate on TCP 647. Clients or relays can reach both servers.
- The shared failover secret and DNS update credential are created, transmitted, escrowed, rotated, and audited through approved secret processes, never embedded in source control or example output.
Key concepts
- Scope
- A subnet-specific pool and policy that defines allocatable addresses, exclusions, reservations, lease duration, and options.
- Authorization
- An AD object identifying an approved Windows DHCP server. It helps stop unauthorized domain DHCP services but does not block rogue network devices.
- Reservation
- A stable mapping from a client identifier to one address within the scope, still delivered and tracked by DHCP.
- Failover relationship
- A two-server partnership that replicates IPv4 scope and active lease information and coordinates which server may allocate addresses.
- MCLT
- Maximum Client Lead Time limits how far one partner may extend a lease beyond what its peer knows, protecting address ownership during communication failure.
- COMMUNICATION INTERRUPTED
- A cautious state where partners cannot communicate but both may still be operating; address use remains constrained to prevent duplicate leasing.
- PARTNER DOWN
- A state asserting the peer cannot serve. Declaring it without fencing the peer can create split brain and duplicate addresses.
- Configuration replication
- An explicit overwrite of partner scope settings after changes. Lease-state synchronization is not a guarantee that administrators' configuration edits replicated automatically.
Before you copy
Values used in this guide
{{dhcpPrimary}}FQDN of the initial DHCP configuration server.
Example: dhcp01.corp.example.com{{dhcpPrimaryIp}}Fixed IPv4 address of DHCP01.
Example: 10.20.0.20{{dhcpPartner}}FQDN of the independent failover partner.
Example: dhcp02.corp.example.com{{dhcpPartnerIp}}Fixed IPv4 address of DHCP02.
Example: 10.20.0.21{{scopeName}}Human-readable target scope name from IPAM.
Example: HQ-Users-VLAN20{{scopeId}}IPv4 network identifier of the scope.
Example: 10.20.20.0{{scopeStart}}First dynamically assignable IPv4 address.
Example: 10.20.20.50{{scopeEnd}}Last dynamically assignable IPv4 address.
Example: 10.20.20.220{{exclusionStart}}First address in the reviewed static exclusion inside the scope.
Example: 10.20.20.50{{exclusionEnd}}Last address in the reviewed static exclusion inside the scope.
Example: 10.20.20.59{{subnetMask}}Scope IPv4 subnet mask.
Example: 255.255.255.0{{routerIp}}Approved default gateway option for the subnet.
Example: 10.20.20.1{{dnsOneIp}}First accepted internal AD DNS server address.
Example: 10.20.0.10{{dnsTwoIp}}Second accepted internal AD DNS server address.
Example: 10.20.0.11{{adDomainFqdn}}DNS suffix supplied to domain clients.
Example: corp.example.com{{reservationIp}}Approved reserved address within the scope.
Example: 10.20.20.60{{reservationClientId}}Client identifier from managed asset inventory; treat hardware identifiers as sensitive device data.
Example: 00-11-22-33-44-55{{failoverName}}Stable name for the two-server relationship.
Example: HQ-DHCP-FO{{dhcpExportPath}}Protected local staging path for an export copied to backup storage.
Example: D:\ProtectedExport\dhcp-20260728.xmlSecurity and production boundaries
- Use a dedicated least-privilege account for DHCP DNS updates and configure the identical credential on both partners. Never use Domain Admin or disclose the password.
- The DHCP failover cmdlet accepts a string shared secret. Collect it as SecureString, convert only in process immediately before invocation, never echo it, and remove variables in a finally block.
- Authorization in AD does not block rogue non-Windows servers. Use DHCP snooping, trusted switch ports, NAC, wireless controls, and monitoring.
- Lease and reservation data maps users/devices to addresses and can be personal/security data. Protect exports, audit logs, incident evidence, and retention.
- Never declare PARTNER DOWN unless the peer is fenced or independently proven unable to serve. Running both sides as partner-down can issue duplicate leases.
Stop before continuing if
- Stop if address ownership, exclusions, static assignments, lease duration, gateway, DNS, relay, or capacity is not approved in IPAM.
- Stop failover creation if time differs, TCP 647 is unavailable, either server is unauthorized/unhealthy, or the scope already exists independently on both.
- Stop activation until configuration/lease synchronization, DNS credential parity, relay reachability, reservations, and isolated client tests pass.
- Stop any PARTNER DOWN transition without fencing or definitive independent proof that the peer cannot serve.
- Stop recovery if an imported/restored database could become active on a network with the current pair or overlapping scope.
decision
Approve IPAM, relay, DNS ownership, and failure behavior
Record the subnet, pool, exclusions, statics, reservations, gateway, internal DNS pair, domain suffix, lease duration, growth threshold, relay targets, Option 82 policy, DNS updater, load-balance mode, MCLT, maintenance behavior, recovery owner, and explicit partner-down authority before installing service.
Why this step matters
DHCP makes network identity decisions at scale. An incorrect scope, gateway, DNS address, or failover action can disconnect an entire subnet or create duplicate address ownership.
What to understand
Use IPAM and switch/router sources of truth, not ping sweeps, to identify static and reserved addresses.
Size the pool from measured concurrent devices, growth, lease duration, quarantine/guest behavior, and maintenance reserve.
Define who may fence a partner and declare PARTNER DOWN before an outage; ambiguity during an incident causes split brain.
System changes
- The command prints reviewed nonsecret design values only. The step changes architecture/change records, not the DHCP servers.
Syntax explained
scopeId/start/end- Define the network and allocatable dynamic pool after exclusions.
routerIp- Default gateway option delivered to clients; a wrong value causes immediate outage.
dnsOneIp/dnsTwoIp- Only the accepted internal AD DNS resolvers supplied to clients.
Values stay on this page and are never sent or saved.
'{{scopeId}}','{{scopeStart}}','{{scopeEnd}}','{{exclusionStart}}','{{exclusionEnd}}','{{routerIp}}','{{dnsOneIp}}','{{dnsTwoIp}}' | ForEach-Object { $_ }Scope: 10.20.20.0/24 Dynamic pool: 10.20.20.50 - 10.20.20.220 Gateway: 10.20.20.1 DNS: 10.20.0.10, 10.20.0.11 Static/exclusion review: approved Peak required leases: 118 Pool capacity after exclusions: 171 Failover mode: LoadBalance 50/50 MCLT: 01:00:00 Partner-down authority: Network Incident Commander
Checkpoint: Verify this layer before continuing
Continue whenIPAM shows no overlaps, pool capacity meets threshold, both relays/servers are reachable, DNS ownership and failover timers are approved, and incident authority is named.
Stop whenStop for unknown statics, overlapping scope, public DNS, single relay path, inadequate pool, or undefined partner-down authority.
If this step fails
The dynamic range includes addresses already used by printers or infrastructure.
Likely causeInventory and network configuration were not reconciled with IPAM.
Compare ARP/switch evidence, IPAM allocations, DNS records, and device owners for the disputed addresses.Verify exclusion ranges and reservation plans without scanning broadly.
ResolutionMove the dynamic boundary or migrate statics under an approved plan; never rely on conflict detection as permanent address management.
Security notes
- IPAM and reservation identifiers are sensitive asset data; restrict exports.
Alternatives
- Create a new isolated pilot VLAN when the existing subnet cannot be safely inventoried.
Stop conditions
- Stop for unknown statics, overlapping scope, public DNS, single relay path, inadequate pool, or undefined partner-down authority.
command
Install the DHCP role on both fixed-address servers
Install the in-box DHCP Server role and management tools on DHCP01 and DHCP02, create the local DHCP security groups where required, restart the service after group creation, and verify role, service, interface binding, time, and fixed networking before authorization.
Why this step matters
Both partners need matching supported role binaries, service identity/groups, fixed bindings, and synchronized time before AD authorization or relationship creation.
What to understand
The role installation does not require a reboot in the normal documented path, but honor any actual servicing restart request.
Bind only the intended server interface. A management or untrusted interface can expose offers or accept relay traffic unexpectedly.
Time synchronization is a DHCP failover prerequisite; record the source and offset on both nodes.
System changes
- Adds the DHCP role, RSAT tools, local DHCP security groups, and service. Restarting DHCPServer briefly stops service, but no scopes exist yet.
Syntax explained
Install-WindowsFeature DHCP- Installs the Windows Server DHCP service role.
-IncludeManagementTools- Installs the DHCP PowerShell module and administrative console.
Add-DhcpServerSecurityGroup- Creates local groups used to delegate read/admin access to DHCP.
Get-DhcpServerv4Binding- Shows which interfaces are enabled to serve DHCPv4.
Values stay on this page and are never sent or saved.
Invoke-Command -ComputerName '{{dhcpPrimary}}','{{dhcpPartner}}' -ScriptBlock { Install-WindowsFeature DHCP -IncludeManagementTools; Add-DhcpServerSecurityGroup; Restart-Service DHCPServer; Get-WindowsFeature DHCP | Select-Object Name,InstallState; Get-Service DHCPServer; Get-DhcpServerv4Binding; w32tm /query /status }Feature DHCP installation: Success DHCP Administrators security group: configured DHCP Users security group: configured Name InstallState DHCP Installed DHCPServer Running Automatic Interface 10.20.0.20 BindingState=True Time source: dc01.corp.example.com Leap indicator: 0 (no warning)
Checkpoint: Verify this layer before continuing
Continue whenBoth servers report Installed/Running, only intended fixed interfaces are bound, time is healthy, and no unapproved scope exists.
Stop whenStop if addresses are dynamic, time warns, bindings expose another network, role servicing fails, or a preexisting scope is discovered.
If this step fails
DHCP service stops immediately after starting.
Likely causeThe server is domain-joined but unauthorized, its database/path is inaccessible, or another fatal event exists.
Inspect System and Microsoft-Windows-DHCP-Server operational/admin events.Check Get-DhcpServerInDC and service database permissions/path.
ResolutionContinue to authorization only if the service failure is the expected authorization state; repair any database, binding, or role failure first.
Security notes
- Delegate through DHCP Administrators only where needed and protect server administration from general network operators.
Alternatives
- Use Server Manager to install the same role when the organization's procedure requires GUI evidence.
Stop conditions
- Stop if addresses are dynamic, time warns, bindings expose another network, role servicing fails, or a preexisting scope is discovered.
command
Authorize exact server identities in Active Directory
Authorize DHCP01 and DHCP02 by FQDN and fixed address, allow AD replication, and verify the directory list and service events from both nodes. Authorization is necessary for managed Windows DHCP, but network security must still block rogue offer sources.
Why this step matters
Domain DHCP servers check AD authorization before serving. Exact FQDN/address registration establishes the managed service inventory and prevents accidental domain Windows servers from leasing.
What to understand
Use current fixed addresses and allow Configuration partition replication before diagnosing the other node.
Avoid duplicate stale entries during renames or readdressing; follow a coordinated remove/add procedure.
AD authorization does not stop a rogue appliance, personal router, or hostile host. Enforce trusted server ports and DHCP snooping at the network layer.
System changes
- Creates two DHCP authorization objects in Active Directory. Authorized services can now serve any active bound scopes configured on them.
Syntax explained
Add-DhcpServerInDC- Registers an approved DHCP server in Active Directory.
-DnsName- Uses the server's stable fully qualified identity.
-IPAddress- Associates the exact fixed service address with the authorization object.
Values stay on this page and are never sent or saved.
Add-DhcpServerInDC -DnsName '{{dhcpPrimary}}' -IPAddress '{{dhcpPrimaryIp}}'; Add-DhcpServerInDC -DnsName '{{dhcpPartner}}' -IPAddress '{{dhcpPartnerIp}}'; Get-DhcpServerInDC | Sort-Object DnsName; Get-Service DHCPServerDnsName IPAddress dhcp01.corp.example.com 10.20.0.20 dhcp02.corp.example.com 10.20.0.21 AD replication check: converged DHCP01 service: Running, authorized DHCP02 service: Running, authorized Rogue-offer network control test: approved sources only
Checkpoint: Verify this layer before continuing
Continue whenGet-DhcpServerInDC lists each server once with the correct identity, replication is healthy, and both services report authorized.
Stop whenStop if a duplicate/stale authorization exists, identity/address differs, AD replication fails, or network controls allow other offer sources.
If this step fails
Authorization appears on DC01 but DHCP02 still logs unauthorized.
Likely causeAD replication or local authorization discovery has not converged, or the object identity differs.
Query Get-DhcpServerInDC against another trusted view and inspect AD replication.Compare DHCP02 FQDN/address and authorization failure details.
ResolutionCorrect replication or the exact object and wait for supported discovery; do not add repeated near-duplicate entries.
Security notes
- Only delegated identity/network administrators should authorize or remove DHCP servers.
Alternatives
- A workgroup DHCP server can operate outside AD, but it loses this authorization control and requires a separately justified security design.
Stop conditions
- Stop if a duplicate/stale authorization exists, identity/address differs, AD replication fails, or network controls allow other offer sources.
command
Create the IPv4 scope inactive with exclusions and essential options
Create the reviewed scope on DHCP01 in InActive state, add exclusion ranges for managed static addresses, and set router, internal DNS, and domain-name options. Keeping it inactive prevents leases until failover, relays, DNS, and client behavior pass review.
Why this step matters
Building inactive separates data modeling from client impact. Options 003, 006, and 015 are essential routing and identity dependencies and require explicit verification.
What to understand
Lease duration balances churn, outage tolerance, and address reuse. Eight days is an example, not a universal optimum.
Exclusions reserve portions of the pool that must never be dynamically offered; reservations remain inside the managed scope and are still DHCP assignments.
Supply only internal AD DNS addresses. A public alternate can cause intermittent authentication failure.
System changes
- Creates an inactive scope, exclusion, and scope-level options on DHCP01. Because it is inactive, no new client lease should be offered yet.
Syntax explained
-State InActive- Prevents the new scope from serving until acceptance and failover are complete.
-LeaseDuration 8.00:00:00- Sets an eight-day lease; tune from actual capacity and device mobility.
-Router- Sets DHCP option 003, the client default gateway.
-DnsServer/-DnsDomain- Sets options 006 and 015 to the two internal resolvers and AD suffix.
Values stay on this page and are never sent or saved.
Add-DhcpServerv4Scope -ComputerName '{{dhcpPrimary}}' -Name '{{scopeName}}' -StartRange '{{scopeStart}}' -EndRange '{{scopeEnd}}' -SubnetMask '{{subnetMask}}' -LeaseDuration 8.00:00:00 -State InActive; Add-DhcpServerv4ExclusionRange -ComputerName '{{dhcpPrimary}}' -ScopeId '{{scopeId}}' -StartRange '{{exclusionStart}}' -EndRange '{{exclusionEnd}}'; Set-DhcpServerv4OptionValue -ComputerName '{{dhcpPrimary}}' -ScopeId '{{scopeId}}' -Router '{{routerIp}}' -DnsServer '{{dnsOneIp}}','{{dnsTwoIp}}' -DnsDomain '{{adDomainFqdn}}'; Get-DhcpServerv4Scope -ComputerName '{{dhcpPrimary}}' -ScopeId '{{scopeId}}'; Get-DhcpServerv4OptionValue -ComputerName '{{dhcpPrimary}}' -ScopeId '{{scopeId}}'ScopeId SubnetMask Name State StartRange EndRange LeaseDuration 10.20.20.0 255.255.255.0 HQ-Users-VLAN20 InActive 10.20.20.50 10.20.20.220 8.00:00:00 Exclusion: 10.20.20.50 - 10.20.20.59 003 Router: 10.20.20.1 006 DNS Servers: 10.20.0.10, 10.20.0.11 015 DNS Domain Name: corp.example.com Free dynamic addresses after exclusion: 161
Checkpoint: Verify this layer before continuing
Continue whenThe scope is InActive, range/mask/exclusions match IPAM, essential options contain only approved values, and capacity remains above threshold.
Stop whenStop if scope arithmetic, exclusions, gateway, DNS, domain suffix, lease duration, or capacity differs from approval.
If this step fails
Add-DhcpServerv4Scope reports an overlap.
Likely causeAnother scope, superscope, multicast scope, or stale configuration already covers part of the network.
List all v4 scopes and compare IPAM boundaries.Inspect server exports/change history before removing anything.
ResolutionResolve ownership and migrate/delete only through approved change; do not alter the subnet mask merely to satisfy the cmdlet.
Security notes
- A wrong gateway or resolver can redirect all new clients. Require peer review before activation.
Alternatives
- Import a generated scope from approved IPAM automation if it produces the same reviewable inactive state.
Stop conditions
- Stop if scope arithmetic, exclusions, gateway, DNS, domain suffix, lease duration, or capacity differs from approval.
config
Configure identical secure DNS update behavior on both partners
Create a dedicated nonprivileged domain identity for DHCP DNS updates through the organization's identity process. Set it interactively on both servers, configure the same update policy, and prove it can manage canary A/PTR records without Domain Admin or nonsecure DNS.
Why this step matters
When DHCP updates secure DNS on behalf of clients, the updater owns the records. Both failover partners need the same identity so either can update or delete records after a failover.
What to understand
Use a dedicated account with only the necessary DNS update capability inherited through secure record creation; do not add it to Domain Admins or broad DNS administrator groups.
Password lifecycle must update both partners atomically and be tested with a canary lease.
Always mode makes DHCP own updates consistently, including older clients; confirm this matches endpoint and DNS ownership policy.
System changes
- Stores the DHCP DNS update credential securely in each server's DHCP configuration and changes scope A/PTR update/delete behavior. The credential object is removed from the session afterward.
Syntax explained
Set-DhcpServerDnsCredential- Stores the credential used by DHCP for authenticated dynamic DNS updates.
-DynamicUpdates Always- Requests that DHCP perform DNS updates for all leases in the scope.
-DeleteDnsRRonLeaseExpiry $true- Allows DHCP-owned A/PTR records to follow lease expiry.
-UpdateDnsRRForOlderClients $true- Covers clients that do not request updates themselves.
Values stay on this page and are never sent or saved.
$dnsCredential = Get-Credential -Message 'Enter the dedicated DHCP DNS update identity'; Set-DhcpServerDnsCredential -ComputerName '{{dhcpPrimary}}' -Credential $dnsCredential; Set-DhcpServerDnsCredential -ComputerName '{{dhcpPartner}}' -Credential $dnsCredential; Set-DhcpServerv4DnsSetting -ComputerName '{{dhcpPrimary}}' -ScopeId '{{scopeId}}' -DynamicUpdates Always -DeleteDnsRRonLeaseExpiry $true -UpdateDnsRRForOlderClients $true; Remove-Variable dnsCredential -ErrorAction SilentlyContinueDHCP01 DNS credential: configured (identity redacted) DHCP02 DNS credential: configured (same approved identity) Scope DNS settings: DynamicUpdates: Always DeleteDnsRRonLeaseExpiry: True UpdateDnsRRForOlderClients: True Credential privilege review: dedicated account, not Domain Admin Secret written to output/history: False
Checkpoint: Verify this layer before continuing
Continue whenBoth partners use the same dedicated identity, policy is documented, canary A/PTR ownership/lifecycle works through either partner, and no secret appears in output.
Stop whenStop if the identity is privileged, differs between partners, password handling is unapproved, DNS zones are nonsecure, or canary ownership fails.
If this step fails
The second partner cannot update a record created by the first.
Likely causeThe configured credentials differ or existing record ACL ownership belongs exclusively to another identity.
Inspect configured credential identity metadata without retrieving the password.Review DNS record owner and DHCP DNS audit events for one canary.
ResolutionSet the same approved credential on both and recreate/refresh the canary through the supported lease lifecycle; repair legacy ownership deliberately.
Security notes
- Never include the password in a script, transcript, command argument, or sample output.
- Protect the account against interactive logon and monitor its use.
Alternatives
- Let modern domain clients own their A records and configure DHCP only for PTR/legacy updates if that ownership model is explicitly chosen and tested.
Stop conditions
- Stop if the identity is privileged, differs between partners, password handling is unapproved, DNS zones are nonsecure, or canary ownership fails.
command
Create and validate a managed reservation
Create a reservation for a managed test device using its authoritative client identifier, then inspect its scope membership, exclusion relationship, name, description, and current conflicts. Do not publish real hardware identifiers in general documentation.
Why this step matters
A reservation proves the stable-address workflow and provides a canary for failover and DNS ownership. It must still fit the scope and be free of static use.
What to understand
Use the client identifier observed from the managed asset/lease behavior, not a manually guessed MAC format.
Keep reservation addresses outside exclusion ranges if the server requires them within the allocatable pool design, and ensure no static device already uses them.
Names/descriptions should link to asset ownership without exposing sensitive user data.
System changes
- Creates a persistent reservation object on DHCP01. It does not reach DHCP02 until initial failover creation or later explicit configuration replication.
Syntax explained
Add-DhcpServerv4Reservation- Maps a client identifier to one scope address.
-ScopeId/-IPAddress- Selects the containing scope and reserved address.
-ClientId- Uses the DHCP client identifier, commonly a MAC-derived value for Ethernet clients.
Values stay on this page and are never sent or saved.
Add-DhcpServerv4Reservation -ComputerName '{{dhcpPrimary}}' -ScopeId '{{scopeId}}' -IPAddress '{{reservationIp}}' -ClientId '{{reservationClientId}}' -Name 'dns-canary' -Description 'Managed DHCP/DNS acceptance device'; Get-DhcpServerv4Reservation -ComputerName '{{dhcpPrimary}}' -ScopeId '{{scopeId}}' | Select-Object IPAddress,Name,Type,DescriptionIPAddress Name Type Description 10.20.20.60 dns-canary Both Managed DHCP/DNS acceptance device Client identifier: stored (redacted from evidence) Address conflict check: clear Asset inventory link: ASSET-2841
Checkpoint: Verify this layer before continuing
Continue whenThe reservation exists once, is inside the scope and conflict-free, maps to the correct managed asset, and is ready for partner replication.
Stop whenStop if the identifier is uncertain, the address is excluded/in use, the asset owner is missing, or reservation data would violate privacy policy.
If this step fails
The client receives a different address after activation.
Likely causeThe identifier differs, an existing lease/policy takes precedence, or the reservation did not replicate.
Compare client-reported identifier, reservation on both partners, policy, and current lease.Check whether the client uses randomized hardware identity on this network.
ResolutionCorrect the authoritative identifier/reservation, replicate from the chosen server, and renew the isolated client after resolving conflicting lease state.
Security notes
- Hardware identifiers and lease mappings are sensitive device/user data; redact them from broad reports.
Alternatives
- Use certificate/NAC-based identity and dynamic addressing when device privacy or mobility makes MAC reservations unreliable.
Stop conditions
- Stop if the identifier is uncertain, the address is excluded/in use, the asset owner is missing, or reservation data would violate privacy policy.
command
Create load-balance failover without exposing the shared secret
Verify TCP 647, name resolution, time, and service health, then collect a unique high-entropy shared secret as SecureString. Convert it to plaintext only in process because the Microsoft cmdlet API requires a string, create the relationship from DHCP01, and remove both variables in a finally block.
Why this step matters
Failover makes the two services coordinate leases and availability. Secret handling deserves special care because Add-DhcpServerv4Failover requires a String even though secure interactive collection is available.
What to understand
TCP 647 and synchronized time are explicit Microsoft requirements. Test them before creating the relationship.
Load balance hashes client identifiers so both servers normally serve. MCLT protects lease ownership if communication fails.
Auto state transition can move behavior after the timer, but it does not remove the need to understand/fence a potentially active peer during severe incidents.
System changes
- Creates a two-server failover relationship, replicates the selected scope and current configuration to DHCP02, stores the relationship secret, and begins lease-state synchronization.
Syntax explained
-LoadBalancePercent 50- Allocates normal response responsibility evenly between partners.
-MaxClientLeadTime 01:00:00- Bounds lease extension beyond partner knowledge during failover behavior.
-AutoStateTransition/-StateSwitchInterval- Configures automatic state timing after communication loss according to the reviewed runbook.
-SharedSecret $secretPlain- Passes the secret required by the API only from ephemeral process memory; it is never a literal or output value.
Values stay on this page and are never sent or saved.
$secretSecure = Read-Host 'Enter the DHCP failover shared secret' -AsSecureString; $secretPlain = [Net.NetworkCredential]::new('', $secretSecure).Password; try { Add-DhcpServerv4Failover -ComputerName '{{dhcpPrimary}}' -Name '{{failoverName}}' -PartnerServer '{{dhcpPartner}}' -ScopeId '{{scopeId}}' -LoadBalancePercent 50 -MaxClientLeadTime 01:00:00 -AutoStateTransition $true -StateSwitchInterval 01:00:00 -SharedSecret $secretPlain } finally { Remove-Variable secretPlain,secretSecure -ErrorAction SilentlyContinue }; Get-DhcpServerv4Failover -ComputerName '{{dhcpPrimary}}' -Name '{{failoverName}}' | Select-Object Name,PartnerServer,Mode,LoadBalancePercent,MaxClientLeadTime,StatePreflight DNS: passed Preflight TCP 647: passed Partner time offset: 0.018s Name : HQ-DHCP-FO PartnerServer : dhcp02.corp.example.com Mode : LoadBalance LoadBalancePercent : 50 MaxClientLeadTime : 01:00:00 State : Normal Shared secret displayed or logged: False
Checkpoint: Verify this layer before continuing
Continue whenBoth partners show one relationship in Normal state, identical scope configuration, synchronized leases/time, and no secret in transcript, history, process arguments, or evidence.
Stop whenStop if TCP 647/time fails, the scope exists independently on DHCP02, state is not Normal, or the secret might have been captured.
If this step fails
Relationship creation reports that the scope already exists on the partner.
Likely causeSomeone precreated/imported an overlapping scope instead of allowing failover to replicate it.
Keep both scopes inactive and export configuration from each.Identify the reviewed authoritative source and compare reservations/options/policies.
ResolutionRemove the unintended partner scope only through approved change after preserving evidence, then create failover from the authoritative primary.
Security notes
- Run the secret prompt in a trusted nontranscribed privileged session and rotate it if session capture is suspected.
- Restrict TCP 647 to the two partner identities/addresses.
Alternatives
- Use hot-standby mode with a reviewed reserve percentage for asymmetric site/DR requirements.
Stop conditions
- Stop if TCP 647/time fails, the scope exists independently on DHCP02, state is not Normal, or the secret might have been captured.
verification
Replicate configuration deliberately and compare both partners
Treat DHCP01 as the reviewed configuration source, invoke failover replication, and compare scope, options, exclusions, reservations, policies, DNS settings, leases, and relationship state on both servers. Record that replication overwrites partner configuration.
Why this step matters
Microsoft documents that later scope configuration changes require manual replication. Choosing the source explicitly avoids overwriting correct settings with stale partner data.
What to understand
Capture a semantic comparison before and after replication; success output alone does not prove every policy and reservation is correct.
Configuration replication direction matters. Lease synchronization and configuration replication are related but distinct behaviors.
After future changes, modify one owned source, peer-review it, replicate, and verify both partners.
System changes
- Pushes failover-enabled scope configuration from DHCP01 to DHCP02 and overwrites the partner's corresponding settings.
Syntax explained
Invoke-DhcpServerv4FailoverReplication- Replicates failover scope configuration from the named source to its partner.
-Name- Targets the reviewed failover relationship.
-Force- Runs without interactive confirmation after direction/content were reviewed; it does not resolve conflicts automatically.
Values stay on this page and are never sent or saved.
Invoke-DhcpServerv4FailoverReplication -ComputerName '{{dhcpPrimary}}' -Name '{{failoverName}}' -Force; Get-DhcpServerv4Scope -ComputerName '{{dhcpPrimary}}' -ScopeId '{{scopeId}}'; Get-DhcpServerv4Scope -ComputerName '{{dhcpPartner}}' -ScopeId '{{scopeId}}'; Get-DhcpServerv4Reservation -ComputerName '{{dhcpPartner}}' -ScopeId '{{scopeId}}'; Get-DhcpServerv4Failover -ComputerName '{{dhcpPartner}}' -Name '{{failoverName}}'Replication initiated from: dhcp01.corp.example.com Relationship: HQ-DHCP-FO Scope properties identical: True Options identical: True Exclusions identical: True Reservations identical: True DNS settings identity/policy parity: True Failover state DHCP01: Normal Failover state DHCP02: Normal Pending binding updates: 0
Checkpoint: Verify this layer before continuing
Continue whenAll compared configuration and relationship state match, no pending updates remain, and the authoritative replication direction is documented.
Stop whenStop if any partner contains unique intended settings, state is not Normal, or the source of truth cannot be established.
If this step fails
Replication succeeds but a new reservation is missing on DHCP02.
Likely causeThe reservation belongs to another scope/relationship, comparison used stale data, or audit/replication failed partially.
Refresh the reservation and relationship objects on both servers.Inspect DHCP operational/audit events and exact scope ID.
ResolutionCorrect the reservation on the authoritative source, repeat targeted replication, and verify on the partner before client testing.
Security notes
- Exports/comparisons contain leases and client identifiers if included; minimize and restrict evidence.
Alternatives
- Use reviewed IPAM automation that applies and verifies both partners while preserving the same single-source rule.
Stop conditions
- Stop if any partner contains unique intended settings, state is not Normal, or the source of truth cannot be established.
config
Activate only after redundant relay paths pass a canary test
First configure each subnet relay to both partner addresses and prove ACL and Option 82 behavior from a disposable client while the new scope remains inactive. Activate the scope only after those relay captures, failover Normal state, and partner parity are recorded. Immediately use the isolated client console to obtain, renew, release, and reacquire a lease while observing which partner responds; the PowerShell block intentionally cannot prove the network relay by itself.
Why this step matters
Activation is the moment configuration becomes a client-facing network service. Redundant relay and one isolated canary limit blast radius and prove the complete offer-to-DNS path.
What to understand
Relays must forward to both partner addresses; server redundancy is ineffective behind a single helper target.
Observe discover/request/ack and failover state without collecting unrelated client data.
Verify gateway, both DNS servers, suffix, reservation, route, domain discovery, A/PTR ownership, and renewal—not merely that an address exists.
System changes
- Changes the scope to Active, replicates that configuration, and allows either partner to issue leases to relayed/direct clients. Incorrect values can affect every new/renewing client.
Syntax explained
Set-DhcpServerv4Scope -State Active- Enables the reviewed scope to serve leases.
Invoke-DhcpServerv4FailoverReplication- Ensures activation and current settings reach the partner.
Get-DhcpServerv4ScopeStatistics- Shows in-use/free/percentage metrics for capacity acceptance.
Values stay on this page and are never sent or saved.
Set-DhcpServerv4Scope -ComputerName '{{dhcpPrimary}}' -ScopeId '{{scopeId}}' -State Active; Invoke-DhcpServerv4FailoverReplication -ComputerName '{{dhcpPrimary}}' -Name '{{failoverName}}' -Force; Get-DhcpServerv4Scope -ComputerName '{{dhcpPrimary}}' -ScopeId '{{scopeId}}'; Get-DhcpServerv4ScopeStatistics -ComputerName '{{dhcpPrimary}}' -ScopeId '{{scopeId}}'Relay targets: 10.20.0.20, 10.20.0.21 Relay path to DHCP01: passed Relay path to DHCP02: passed Option 82 policy: accepted Scope state DHCP01/DHCP02: Active/Active Failover relationship: Normal Canary client address: 10.20.20.60 (reserved) Gateway: 10.20.20.1 DNS: 10.20.0.10, 10.20.0.11 Domain suffix: corp.example.com A/PTR registration: passed Free addresses: 160
Checkpoint: Verify this layer before continuing
Continue whenThe canary receives only the reserved/valid address and approved options through either relay/server, DNS lifecycle passes, statistics are correct, and the relationship stays Normal.
Stop whenImmediately inactivate the new scope if wrong gateway/DNS/subnet, duplicate offers, unexpected server, address conflict, or DNS ownership failure appears.
If this step fails
The canary receives no offer after activation.
Likely causeRelay target/ACL, scope subnet, binding, authorization, failover state, or filter/policy blocks the request.
Inspect relay counters and a bounded packet trace for the canary exchange.Review server audit logs, binding, authorization, scope, policy/filter, and relationship state.
ResolutionRepair the exact path while keeping the scope inactive if broad clients could be affected, then repeat the isolated exchange.
Security notes
- Monitor for offers from unexpected servers during activation and contain them at the network edge.
- Do not use a real user's device as the first acceptance client.
Alternatives
- Activate only in an isolated pilot VLAN before migrating the production relay when the existing subnet has high risk.
Stop conditions
- Immediately inactivate the new scope if wrong gateway/DNS/subnet, duplicate offers, unexpected server, address conflict, or DNS ownership failure appears.
verification
Exercise one-partner maintenance and fenced failover behavior
In a maintenance window, stop or isolate only one DHCP service through an approved reversible action, confirm the peer serves renewals/new leases under the documented MCLT behavior, restore the partner, and observe Normal recovery. Separately tabletop PARTNER DOWN; do not invoke it unless the peer is fenced.
Why this step matters
A controlled single-partner test proves useful availability while preserving the protocol safeguards. It also teaches operators not to confuse communication loss with proof that the peer is down.
What to understand
Use an approved service/network maintenance action with console access and a short bound; do not crash or corrupt a server to test failover.
COMMUNICATION INTERRUPTED may be expected while the peer is unavailable. Address ownership and MCLT intentionally limit what the survivor can do.
A real PARTNER DOWN declaration requires independent fencing, incident authority, lease risk assessment, and a controlled recovery sequence.
System changes
- The shown commands read state/counters/events. The associated exercise temporarily removes one DHCP partner and produces failover state transitions and test lease updates.
Syntax explained
Get-DhcpServerv4Failover- Shows relationship mode, state, partner, timers, and synchronization evidence.
Get-Counter- Samples DHCP service/failover counters during bounded maintenance.
Get-WinEvent- Reads administrative state-transition and error evidence.
Values stay on this page and are never sent or saved.
Get-DhcpServerv4Failover -ComputerName '{{dhcpPrimary}}' -Name '{{failoverName}}'; Get-DhcpServerv4Failover -ComputerName '{{dhcpPartner}}' -Name '{{failoverName}}'; Get-Counter '\DHCP Server\*' -SampleInterval 2 -MaxSamples 3; Get-WinEvent -LogName 'Microsoft-Windows-DHCP Server Events/Admin' -MaxEvents 20Baseline state: Normal / Normal Maintenance: DHCP01 service controlled unavailable DHCP02 state observed: CommunicationInterrupted -> Normal after return Existing canary renewal through DHCP02: passed New canary lease within available ownership: passed Duplicate address events: 0 Pending binding updates after recovery: 0 Time offset: 0.022s Manual PARTNER DOWN invoked: False Runbook fencing evidence requirement: verified
Checkpoint: Verify this layer before continuing
Continue whenThe surviving partner serves within protocol constraints, no duplicates occur, the returned partner resynchronizes to Normal, and operators can explain the fenced partner-down gate.
Stop whenStop if duplicate leases, wrong DNS ownership, time offset, persistent non-Normal state, dropped binding updates, or unsafe partner-down pressure appears.
If this step fails
The returned partner remains in RECOVER or RECOVER-DONE.
Likely causeLease-state synchronization is incomplete, communication/time remains unstable, or state transition requires the documented administrative completion.
Inspect pending binding updates and failover events on both servers.Verify time, TCP 647, relationship secret/configuration, and lease database health.
ResolutionKeep client service on the healthy partner within protocol limits and follow the Microsoft failover recovery state procedure; do not delete/recreate the relationship impulsively.
Security notes
- Restrict failover state-changing rights and audit every manual transition.
Alternatives
- Use a tabletop plus lab exercise for PARTNER DOWN when production fencing cannot be tested safely.
Stop conditions
- Stop if duplicate leases, wrong DNS ownership, time offset, persistent non-Normal state, dropped binding updates, or unsafe partner-down pressure appears.
verification
Protect exports, monitor service quality, and rehearse isolated recovery
Export configuration plus leases from the authoritative server, create the in-box backup, copy artifacts to protected storage, and validate restore only on an isolated network with no route to production client VLANs. Monitor scope, failover, authorization, DNS, time, audit, and rogue offers continuously.
Why this step matters
Availability depends on detecting degradation and recovering configuration/lease state without starting a stale overlapping service. An export is useful only when protected, complete, versioned, and rehearsed in isolation.
What to understand
Use -Leases when the recovery objective requires lease data. Protect the XML and backup because they map devices to addresses and expose network design.
Import-DhcpServer and Restore-DhcpServer are recovery operations; run them only on an isolated interface/network in the rehearsal.
Monitor state-transition events and failover performance counters as well as scope utilization, BAD_ADDRESS, DNS failures, authorization, time, audit delivery, and rogue offers.
System changes
- Writes a DHCP XML export and in-box backup containing configuration and potentially client lease identifiers. The isolated rehearsal creates state only in a fenced recovery environment.
Syntax explained
Export-DhcpServer -Leases- Exports server/scope configuration and current lease data to XML.
-Force- Overwrites the reviewed staging path without prompting; protected versioning must retain prior artifacts elsewhere.
Backup-DhcpServer- Creates the DHCP service's native backup set at the selected protected path.
Get-DhcpServerv4ScopeStatistics- Provides current utilization for capacity alert validation.
Values stay on this page and are never sent or saved.
Export-DhcpServer -ComputerName '{{dhcpPrimary}}' -File '{{dhcpExportPath}}' -Leases -Force; Backup-DhcpServer -ComputerName '{{dhcpPrimary}}' -Path 'D:\ProtectedExport\DhcpBackup'; Get-Item '{{dhcpExportPath}}' | Select-Object Name,Length,LastWriteTime; Get-DhcpServerv4ScopeStatistics -ComputerName '{{dhcpPrimary}}'; Get-DhcpServerv4Failover -ComputerName '{{dhcpPrimary}}'Export file: dhcp-20260728.xml Export size: 184320 bytes Export includes leases: True In-box DHCP backup: completed Protected-copy checksum recorded: SHA256 (value stored in recovery system) Isolated import test: configuration 1 scope, 1 reservation, 2 options, 4 synthetic leases Production connectivity during restore test: blocked Failover state: Normal Scope utilization: 6.8% Alert tests: utilization, authorization, failover, DNS update, time, audit all passed
Checkpoint: Verify this layer before continuing
Continue whenProtected export/backup is current and integrity-checked, isolated restore reproduces expected synthetic state, production paths remain fenced, and every operational alert is tested.
Stop whenStop if artifacts are unencrypted/uncontrolled, leases are missing, restore network can reach production, imported scopes could become authorized/active, or monitoring is incomplete.
If this step fails
Isolated import reports that backup path is required or server settings conflict.
Likely causeImport-DhcpServer needs a local backup path for rollback and the target already contains incompatible DHCP state.
Inspect the target in isolation, document its role/build, and review Import-DhcpServer prerequisites.Confirm the export version, scope selection, lease inclusion, and clean target.
ResolutionRebuild the isolated target cleanly, provide a protected local backup path, import while disconnected, and verify before repeating; never experiment on an active partner.
Security notes
- Encrypt exports/backups, restrict recovery operators, and redact client identifiers from general reports.
- Never email or attach the raw lease database to a public incident ticket.
Alternatives
- Use an enterprise DHCP-aware backup/IPAM system when it provides equivalent lease/configuration integrity, isolation, audit, and restore proof.
Stop conditions
- Stop if artifacts are unencrypted/uncontrolled, leases are missing, restore network can reach production, imported scopes could become authorized/active, or monitoring is incomplete.
Finish line
Verification checklist
Get-DhcpServerInDC | Sort-Object DnsName; Get-Service DHCPServerBoth exact FQDN/address identities are authorized once and both services are healthy on intended bindings.Get-DhcpServerv4Scope -ComputerName '{{dhcpPrimary}}' -ScopeId '{{scopeId}}'; Get-DhcpServerv4OptionValue -ComputerName '{{dhcpPrimary}}' -ScopeId '{{scopeId}}'Range, mask, state, duration, exclusions, router, two internal DNS servers, and domain suffix match IPAM and the partner.Get-DhcpServerv4Failover -ComputerName '{{dhcpPrimary}}' -Name '{{failoverName}}'; Get-DhcpServerv4Failover -ComputerName '{{dhcpPartner}}' -Name '{{failoverName}}'Both partners report Normal, identical mode/MCLT/timers, synchronized time, and zero pending binding updates.Get-DhcpServerv4Reservation -ComputerName '{{dhcpPartner}}' -ScopeId '{{scopeId}}'; Resolve-DnsName dns-canary.{{adDomainFqdn}}The reservation exists on both partners, the canary receives it through either server, and matching A/PTR records have the approved DHCP update owner.Get-DhcpServerv4ScopeStatistics -ComputerName '{{dhcpPrimary}}' -ScopeId '{{scopeId}}'; Get-Item '{{dhcpExportPath}}'Utilization is below threshold, one-partner maintenance passes without duplicates, and protected export/backup has a successful isolated restore record.Recovery guidance
Common problems and safe checks
The DHCP service logs that the server is not authorized.
Likely causeIts AD authorization object is absent, stale, duplicated, not yet replicated, or does not match the server's current FQDN and fixed address.
Run Get-DhcpServerInDC from a trusted management host and compare the exact FQDN/address with Get-DhcpServerv4Binding and current interface configuration.Inspect DHCP Server operational and system events and AD replication before adding another authorization object.
ResolutionCorrect or remove the conflicting authorization entry through the approved AD process, allow replication, authorize the exact server identity once, and restart/verify service only after the directory view is consistent.
Clients on one VLAN do not receive offers, while local clients do.
Likely causeThe DHCP relay/IP helper is missing or points to only one partner, routing/ACLs block UDP flows, Option 82 policy rejects requests, or the scope does not match the relay subnet.
Inspect relay configuration and counters, server audit logs, packet capture on an authorized test path, and the gateway address reported with the request.Confirm the relay lists both failover partners and the scope network matches the client subnet.
ResolutionCorrect the redundant relay and approved ACL/policy, then repeat a single isolated client discover. Do not place a second unmanaged DHCP server on the VLAN.
A scope remains inactive or does not serve addresses.
Likely causeThe scope was intentionally created InActive, the binding is disabled, the server is unauthorized, the failover relationship is unhealthy, or no free addresses remain.
Inspect Get-DhcpServerv4Scope, Get-DhcpServerv4Binding, Get-DhcpServerInDC, Get-DhcpServerv4ScopeStatistics, and failover state.Review exclusions, leases, policies, filters, and audit events before activation.
ResolutionRepair authorization, binding, capacity, or failover first, then activate the reviewed scope deliberately. Never toggle random scope/server state during production diagnosis.
Add-DhcpServerv4Failover fails or the relationship enters COMMUNICATION INTERRUPTED.
Likely causePartner name resolution, TCP 647, time synchronization, service state, duplicate relationship, shared secret, or scope ownership is wrong.
Resolve both partner names, test the approved TCP 647 path, compare time, inspect Get-DhcpServerv4Failover on both nodes, and review failover events.Confirm the scope exists only on the intended primary before initial relationship creation.
ResolutionRepair name, time, network, service, or relationship state and retry from the authoritative configuration server. Do not recreate overlapping scopes independently on the partner.
The two failover partners show different scope options or reservations.
Likely causeA post-creation change was made on one partner and failover configuration replication was not initiated, or changes were made from both directions.
Export/read scope, option, policy, and reservation configuration from both servers and identify the intended source of truth.Review change/audit logs before invoking replication because replication overwrites partner settings.
ResolutionChoose the reviewed authoritative server, correct its settings, and invoke failover replication from that server. Verify both sides and prohibit independent conflicting edits.
DHCP leases succeed but DNS A or PTR updates fail after partner failover.
Likely causePartners use different DNS update credentials, the credential expired, record ownership belongs to the other identity, or secure zone/update policy is incorrect.
Compare whether both servers are configured with the same dedicated credential without retrieving or exposing its password, then inspect DHCP DNS/audit events and DNS record ownership.Renew one canary lease through each server and query A/PTR records from both DNS replicas.
ResolutionSet the same approved dedicated least-privilege DNS credential on both partners, repair ownership through the supported update lifecycle, and retest; never grant Domain Admin or enable nonsecure updates.
A reservation does not receive its expected address.
Likely causeThe ClientId/MAC format is wrong, another active lease owns the address, a policy selects another range, the client identifier changed, or the reservation exists only on one partner.
Inspect the reservation, current lease, policy result, client-reported identifier, and both partner configurations without publishing the hardware identifier.Verify the address is inside the scope but outside exclusions and not statically used.
ResolutionCorrect the authoritative reservation and replicate it, resolve the conflicting lease through the documented maintenance process, then renew the test client.
The scope approaches exhaustion or shows many BAD_ADDRESS leases.
Likely causeThe pool is undersized, lease duration is too long, unknown clients consume addresses, conflict detection found statically used addresses, or relay duplication creates noise.
Review scope statistics, lease age/state, denied/filtered clients, audit events, conflict data, and IPAM/source-of-truth assignments.Validate a sample of BAD_ADDRESS entries against switch/ARP ownership without blindly deleting leases.
ResolutionRemove address conflicts at their source, tune lease duration from measured churn, expand/readdress through network design, or control admission. Do not shorten leases drastically during an incident without capacity analysis.
Both partners issue or appear able to issue the same address.
Likely causeAn operator forced PARTNER DOWN on both sides, restored an old database into an active network, created overlapping standalone scopes, or bypassed failover fencing.
Isolate one side, preserve audit/failover logs and lease databases, inspect relationship state and duplicate address evidence, and confirm which server is authoritative.Do not run bulk lease deletion or activate restored scopes until the split-brain boundary is understood.
ResolutionTreat as a network incident: fence one server, restore one authoritative relationship/database state using supported procedures, remediate duplicate leases, and reconnect only after lease and failover convergence.
A server stays in COMMUNICATION INTERRUPTED during a real partner outage.
Likely causeAutomatic state transition is disabled/not elapsed, the server cannot prove partner state, or operators have not fenced the failed partner.
Confirm partner power/network/service state through an independent channel, inspect MCLT and state-switch timers, and review leases still owned by each partner.Verify no alternate path could allow the partner to continue serving before any manual PARTNER DOWN decision.
ResolutionUse the approved failover runbook and declare partner down only after fencing or positively proving it cannot serve. Respect MCLT address ownership before using the full pool.
DHCP service or failover time-offset events appear.
Likely causeThe servers follow different time sources, the AD hierarchy is unhealthy, or a virtualization clock provider conflicts with domain time.
Run w32tm /query /status and /monitor for both partners and domain controllers and inspect failover TimeOutOfSync events.Compare effective time policy and hypervisor integration without manually setting clocks.
ResolutionRestore the approved AD time hierarchy, correct competing providers, and verify stable offset before resuming failover changes.
DHCP export or backup exists but cannot be restored safely.
Likely causeThe artifact lacks leases, is corrupt, is stored on the failed server, uses an incompatible context, or restore testing would collide with the active pair.
Inspect Export-DhcpServer/Backup-DhcpServer logs, file integrity, protected storage, version, scope selection, and presence of leases without importing it into production.Provision an isolated recovery network and confirm the documented server identity and authorization boundaries.
ResolutionCreate a fresh protected export/backup and rehearse Import-DhcpServer or Restore-DhcpServer only in isolation. Never start a restored overlapping DHCP service on a production-connected interface.
An unauthorized DHCP server still offers leases even though Windows servers are authorized in AD.
Likely causeAD authorization controls Windows domain DHCP behavior but does not block rogue appliances, personal routers, or malicious hosts at the network edge.
Capture offer server identifiers from an authorized test client and correlate them with switch port, DHCP snooping, wireless, and NAC telemetry.Compare the source with the approved server inventory without responding to or managing the rogue device from the client.
ResolutionContain the rogue port/device through network security, enable and monitor DHCP snooping/port security/NAC where supported, and renew affected clients after legitimate service is authoritative.
Reference
Frequently asked questions
Does failover replicate every configuration change automatically?
No. Microsoft documents that scope-setting changes must be manually replicated. Initiate replication from the server whose reviewed configuration should overwrite the partner.
Can a failover relationship contain three servers?
No. A relationship is always between two servers, though one server can have multiple relationships with different partners for different scopes.
Why must both partners use the same DNS credential?
Secure DNS record ownership can prevent the other identity from updating a name after failover. Microsoft explicitly requires the same DNS credentials when partners update on behalf of clients.
Is manual PARTNER DOWN the normal response to a network blip?
No. COMMUNICATION INTERRUPTED protects against the possibility that both servers still run. PARTNER DOWN is a controlled incident action after fencing/proving the peer is unable to serve.
Recovery
Rollback
Before activation, remove the inactive failover relationship/scope only after exporting evidence. After clients receive leases, rollback is a coordinated migration: inactivate the faulty new scope if an alternate service is authoritative, preserve both lease databases, and avoid overlapping active service. Never restore/import an old database into the connected production network or declare both peers partner-down.
- Stop new rollout and preserve scope, option, reservation, policy, DNS, authorization, failover, lease, relay, audit, and time evidence from both partners.
- If activation distributed wrong options and the previous DHCP service remains authoritative, inactivate the new scope on the authoritative partner, replicate the state, and verify no new offers before restoring the prior relay path.
- Do not simply delete active leases or activate the same scope on another server; coordinate client lease timers and address ownership.
- For one failed partner, fence it and keep the healthy failover relationship within supported MCLT/state behavior while rebuilding or restoring the failed node.
- Restore/import backup only in an isolated network, reconcile it with current lease state, and follow the approved Microsoft failover recovery/migration procedure before any production connection.
- Reauthorize/reactivate service only after Normal state, configuration parity, relay, reservation, DNS, single-partner maintenance, monitoring, and rogue-offer tests all pass.
Evidence