I have seen an intermittent issue twice while running a PowerShell DHCP backup and lease export. The relevant commands are:
Backup-DhcpServer -Path $backupPath -ComputerName "$ENV:COMPUTERNAME"
Export-DhcpServer -ComputerName "$ENV:COMPUTERNAME" -File "$backupPath$ENV:COMPUTERNAME_leases.xml" -Leases
The script also runs Repair-DhcpServerv4IPRecord against every IPv4 scope before the backup, then checks for inactive scopes and replicates DHCP failover afterward. Most runs complete normally, but the event log sometimes shows active scopes being deactivated, checked, and reactivated within about a second. In a rare error or integrity-violation scenario, a scope remains inactive long enough for that state to replicate to its failover partner.
The event sequence I have observed is 74, 20237, 20315, 20239, 20221, 20223, and 73. The issue has occurred only twice, months apart. Running a backup through the DHCP GUI does not produce the same events, as far as I have observed.
For now, the script checks for inactive scopes and reactivates them before failover replication, but that is a reactive workaround. I would like to understand what the PowerShell backup, export, and repair cmdlets do internally, particularly whether they trigger database verification or other asynchronous DHCP operations that can temporarily change scope state. Is there Microsoft documentation or a known mechanism that explains this behavior?
1 Answer
The first troubleshooting step would be to isolate the operations rather than run the entire sequence together. Test Backup-DhcpServer by itself, then Export-DhcpServer, and then Repair-DhcpServerv4IPRecord separately while watching the DHCP operational log. That should show which command correlates with the scope-state events.
It is also worth confirming whether repair returns only after all of its work is complete, or whether the DHCP service continues database activity afterward. Starting the backup immediately after reconciliation could expose a timing issue, especially when a repair actually finds inconsistencies. Capturing timestamps, command output, and the exact event XML for each isolated run would help establish whether the cmdlets are directly changing scope state or merely causing the service to surface an existing database condition.
The registry settings and mixed local/explicit server parameters are separate script-design considerations, but they do not by themselves explain the event sequence. The important evidence is a controlled comparison of repair, backup, and export individually, followed by checking whether failover replication is started before the service has returned to a stable state.
Related Questions
Can't Load PhpMyadmin On After Server Update
Redirect www to non-www in Apache Conf
How To Check If Your SSL Cert Is SHA 1
Windows TrackPad Gestures