PowerShell Migration from On-Premises DHCP to Windows Server Failover

For many Australian IT teams running distributed networks between Sydney, Melbourne, and regional branches, the DHCP service quietly handles thousands of address leases every day. As Windows Server 2012 R2 approaches end of support and hardware refreshes loom, migrating to a modern DHCP failover configuration becomes a practical necessity rather than a luxury. PowerShell gives administrators the scripting muscle to automate what would otherwise be hours of repetitive GUI work, reducing human error during the cutover.

The failover feature, originally introduced in Windows Server 2012, allows two DHCP servers to share lease information and provide continuous address assignment if one node fails. Combined with PowerShell remoting and the DhcpServer module, the migration can be largely scripted, tested, and rolled back if needed. This approach suits Australian organisations operating across multiple time zones, where weekend maintenance windows must be tightly choreographed.

Australian sysadmins also need to weigh local realities: data sovereignty under the Privacy Act, the Essential Eight mitigation strategies from the Australian Cyber Security Centre, and the bandwidth constraints of remote sites connected via the NBN or dedicated services. Scripting the migration makes it predictable, auditable, and repeatable across multiple offices without sending a senior engineer on a plane.

This walkthrough assumes familiarity with Active Directory, basic networking, and PowerShell fundamentals. It covers the end-to-end process using native cmdlets, from exporting the existing scope configuration to validating the failover relationship on the new pair of servers.

Assessing the Current DHCP Environment

Before touching any scripts, take inventory of what the source DHCP server is currently serving. Capture the scope names, address ranges, exclusions, reservations, options, and policies that exist today. The Get-DhcpServerv4Scope and Get-DhcpServerv4OptionValue cmdlets provide a clean export of this information.

For larger Australian enterprises, this inventory often uncovers forgotten reservations set up years ago for point-of-sale terminals in a Brisbane store or for building management systems in a Perth data centre. Documenting these before migration prevents outages that surface only when a device fails to obtain its expected address.

Australian-specific considerations include AEST and AEDT timezone handling on lease expiry calculations and ensuring the new servers sit in sites with sufficient NBN or enterprise link capacity to handle replication traffic. Regional offices in places like Cairns or Hobart may have limited uplink bandwidth, so the failover load should be sized accordingly.

Preparing the Windows Server Failover Cluster

DHCP failover does not require a Windows Failover Cluster, but it does require both servers to be domain-joined, authorised in Active Directory, and reachable on UDP ports 67 and 68. Install the DHCP Server role on both target hosts and authorise them using Add-DhcpServerInDC before any configuration is imported.

Prerequisites for a clean deployment:

• Windows Server 2016 or later on both failover partners
• Domain membership with consistent time synchronisation
• Administrative credentials with DHCP and AD permissions
• Network connectivity on UDP 67/68 and the configured replication port

For Australian organisations subject to the Essential Eight, both servers should have consistent security baselines, including application control, patched operating systems, and centralised logging forwarded to a SIEM. The Australian Government Information Security Manual provides additional guidance on hardening Windows infrastructure services.

Network connectivity between the two DHCP servers must allow replication traffic on a defined port. By default, DHCP failover uses port 647, but this can be changed during configuration. Ensure any stateful inspection firewalls between sites, particularly over inter-capital links or MPLS, permit this traffic bidirectionally.

Exporting DHCP Configuration via PowerShell

The migration begins by exporting the existing scope configuration to a portable format. The Export-DhcpServer cmdlet creates an XML file containing scopes, superscopes, reservations, options, and policies. Store this file on a secure path accessible from both source and destination servers.

PowerShell makes it easy to automate this step as part of a scheduled job, generating fresh exports each night during the lead-up to the migration. For multi-site deployments common in Australian retail or government, the script can loop through a list of source servers and produce dated exports for each location.

Validate the XML file by opening it in a text editor or parsing it with PowerShell to confirm the expected scope count. A quick Compare-Object between the live scope list and the exported nodes catches any inconsistencies before they propagate to the new environment.

Importing Scopes onto the Failover Partner

With the export file ready, transfer it to the primary failover partner and run Import-DhcpServer. This cmdlet reads the XML and recreates the scopes, reservations, and options on the destination server. The import does not activate failover; it merely provisions the configuration identically.

For organisations with sites spread across AEST, ACST, and AWST time zones, schedule the import during a low-traffic window such as early Sunday morning AEST to minimise disruption. The import itself is usually quick, but reservation-heavy scopes can take longer to process.

Run Get-DhcpServerv4Scope on the target server to confirm the imported scopes match the source. Pay particular attention to exclusion ranges and vendor classes, which are easy to overlook in a visual review but critical for correct network behaviour.

Configuring DHCP Failover Relationships

Once both servers carry identical scopes, establish the failover relationship using Add-DhcpServerv4Failover. The cmdlet accepts parameters for the partner server, shared secret, mode (load balance or hot standby), and load balance percentage.

Hot standby suits scenarios where one site acts as a passive disaster recovery location, such as a secondary datacentre in Adelaide backing a primary in Sydney. Load balance is preferable when both servers sit in the same datacentre or campus with low-latency links.

Australian organisations with offices connected over the NBN or consumer-grade business links should generally favour hot standby, since WAN latency can degrade load-balanced performance. Document the shared secret in a secure vault aligned with the organisation's credential management policy.

Validating Lease and Reservation Migration

DHCP failover replicates leases once the relationship is active, but historical lease history does not migrate automatically. Reservations, however, are part of the scope configuration and travel with the import. Validate reservations by comparing the source and destination lists.

A simple validation script:

• Compare reservation MAC addresses between source and destination
• Verify option values match for each scope
• Confirm DNS dynamic update credentials are correctly configured
• Test lease assignment from a representative client

This is also a good moment to verify that the new servers respond correctly to requests from a test VLAN. Australian networks with extensive 802.1X deployments may need additional checks to ensure the DHCP packets are reaching the server through authenticated ports.

Post-Migration Monitoring and Cutover

After validation, monitor the failover replication status with Get-DhcpServerv4Failover and review event logs on both servers. The Microsoft-Windows-DHCP Server event log surfaces replication warnings and scope state changes.

For Australian teams working across multiple states, a brief change advisory board meeting the morning after the cutover helps confirm that sites in Perth, Brisbane, and Melbourne are all reporting healthy lease activity. Until the source DHCP server is decommissioned, leave it running but unbind the scope from network interfaces to prevent accidental response.

Once the new failover pair has carried production traffic through a full business week, schedule the final decommission of the legacy server. During those long weekend maintenance windows, a quiet glance at Australian gaming culture sites is a familiar way for engineers to unwind between replication checks. Document every step, retain the export XML for rollback purposes, and update the network operations runbook to reflect the new authoritative DHCP pair.