I've encountered this issue twice while running a daily DHCP maintenance script. 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 repairs IPv4 records before the backup with Repair-DhcpServerv4IPRecord -Force, exports reservations, checks for inactive scopes, reactivates any it finds, and then forces failover replication.
Under normal conditions, several active scopes with regular printer and workstation activity briefly generate events indicating that they were deactivated, checked or reconciled, and then reactivated within about a second. The event sequence I've observed is 74, 20237, 20315, 20239, 20221, 20223, and 73.
Usually this has no visible impact. However, when an error or database-integrity problem occurs at the wrong time, a scope can remain inactive long enough for that state to replicate to the DHCP failover partner. That happened once recently and previously in January. I've added a safeguard that reactivates inactive scopes before replication, but that is reactive rather than a proper understanding or fix.
Backing up through the DHCP GUI does not produce the same event sequence in my testing. I'm looking for deeper information about what Backup-DhcpServer and Export-DhcpServer do internally, whether they invoke reconciliation-like operations, and whether the commands can leave asynchronous work running after they return. I'm not primarily looking for syntax or general script-organization advice; the question is about the underlying DHCP mechanisms and why the PowerShell path differs from the GUI.
1 Answer
The first useful diagnostic step would be to isolate every operation and run it independently: Repair-DhcpServerv4IPRecord, Backup-DhcpServer, and Export-DhcpServer. That should establish which cmdlet is producing the event sequence instead of assuming the backup and export paths behave identically.
It’s also worth checking whether the repair command has truly finished all of its server-side work before the backup begins. A cmdlet can return quickly while the DHCP service continues processing reconciliation or database changes internally. If that is happening, the subsequent backup or export could be overlapping with a state transition and exposing a race that the GUI workflow avoids.
The registry settings are another variable to eliminate during testing. Changing BackupDatabasePath and the related intervals while the service is running may not apply until restart, but it still makes the test environment harder to reason about. Capture the existing values, run the commands against a stable configuration, and compare the DHCP operational logs and failover state after each individual step.
The GUI and PowerShell commands may share some underlying DHCP functionality without following the exact same sequence. Therefore, the fact that the GUI does not show these events does not necessarily prove that the cmdlets are simply calling the same operation in a different interface.
The events also occur when I run Backup-DhcpServer or Export-DhcpServer by themselves, so I suspect both commands use similar internal routines for their respective data handling. The repair operation completes immediately on a clean database and only takes a few seconds when it has actual records to process; there is no known outstanding reconciliation task when the backup starts. I’m specifically trying to identify what the PowerShell implementation does differently from the GUI.