Managing DHCP with PowerShell Part 3

Recap….

In Part 1 we exported existing scope(s) from the existing DHCP server.

In Part 2 we imported the scope to a new DHCP server.

In Part 3 I’ll discuss how to activate the scope(s), vendor custom classes and create a hot standby for failover and a couple of real world tips.

Depending on when you plan to activate the new DHCP server you have a few choices on what you may want to do.

  1. Deactivate the DHCP scopes on the old server and activate the new scopes on the new server.
  2. Import the scopes to the new DHCP server but leave deactivated

You may decide that you want to create the DHCP Hot Standby relationship first before activating the scopes, it’s really just about preference.

Real World Tips

Activating DHCP Scopes

  1. On the old DHCP server, open the console and deactivate the scope(s)
  2. On the new DHCP server open the console and activate the scope(s)

Set-DHCPServerV4Scope -ComputerName DHCP1.domain.local -ScopeID 10.0.0.1 -State InActive

Set-DHCPServerV4Scope -ComputerName DHCP1.domain.local -ScopeID 172.16.0.0 -State InActive

Set-DHCPServerV4Scope -ComputerName DHCP1.domain.local -ScopeID 192.168.0.0 -State InActive

Set-DHCPServerV4Scope -ComputerName DHCP2.domain.local -ScopeID 10.0.0.1 -State Active

Set-DHCPServerV4Scope -ComputerName DHCP2.domain.local -ScopeID 172.16.0.0 -State Active

Set-DHCPServerV4Scope -ComputerName DHCP2.domain.local -ScopeID 192.168.0.0 -State Active

Creating a DHCP Failover with a Hot Standby

It’s possible to create a Hot Standby with both the GUI and with PowerShell. There’s a couple of things to be aware of when you use PowerShell to create the relationship and configure the settings, these are discussed in the ‘Real World Tips’ section below

Relationship Settings

I’ll highlight only the options for the Hot Standby.

Relationship Name
This is the name of the relationship, by default it uses the DHCP server names.

Maximum Client Lead Time (MCLT)
This is the amount time for which a DHCP lease may be renewed by either DHCP server in the relationship without contacting each other.  It is also responsible for the amount of time that each DHCP server in the relationship will wait in a ‘partner down’ state before taking control of the entire IP address range within the scope.

Auto State Switchover Interval
This is the amount of time that passes during a communication interrupt between the servers in the relationship until the state of the relationship changes to ‘partner down’.

Addresses reserved for standby server
During the period before the DHCP relationship transitions to ‘partner down’ it will need a percentage of available IP addresses it assign to clients. Once the DHCP transitions to ‘partner down’ then the failover partner will assume control of the entire free IP address pool of the active server.

Enable Message Authentication
Enables authentication of failover traffic between DHCP servers

Shared Secret
Used to authenticate failover between DHCP servers

Real World Tips

  • Deactivating the scopes on the old DHCP server will not cause existing leases to fail straight away although I would check what your existing lease times are. if you have a standard lease time of about 8 hours then you’ll be able to make the change without any impact although I did my changes out of hours.
  • Even if you have IP Helpers to both the old and new DHCP servers the broadcasts will only be answered by the active DHCP server however it is advisable to remove the old IP helpers when possible to ensure no confusion is caused in your environment. It’s helpful to your network team so that they know only the IP helpers configured are actually requesting and accepting IP addresses on behalf of a client.
  • Always use a fully qualified name (FQDN) when specifying the primary and failover nodes. The DHCP method to create the relationship is content to use both FQDN or a Netbios name and the process will work with either however I did find that System Center Operations Manager (SCOM) will have some specific issues detecting the failover relationships. SCOM uses a technique called object discoveries to detect application components or if a sever has a particular role installed before it can effectively monitor it. When I created the failover relationship without the FQDN, SCOM was not able to populate the failover groups and relationships but it did still discover and monitor the DHCP server. This is annoying as once you’ve created the relationship you would have to remove and start again to resolve this issue.

Hot Standby script

So here’s the script I’ll use to create the DHCP relationship

<#
Author: <Author Name>
Created: <Date>
Purpose: This script creates a DHCP Failover Relationship. The script should be run from the Primary (Branch) DHCP server and created with the local Regional DHCP. Before this script is run the following variables will need to be updated:
$FailoverName – Ensure the relationship name is applicable
$SecondaryDHCP – Ensure this is the correct regional DHCP server
$ScopeIDs – Ensure this has the correct scope IDs for the branch office
$Secret – this will need a value added between “” before the script is executed
#>


# Create a DHCP Failover from the Branch office to the Regional DHCP Server
# Primary DHCP Server
$PrimaryDHCP = ‘dhcp2.domain.local’
# DHCP Failover Partner (Region)
$SecondaryDHCP = ‘dhcp3.domain.local’
# ScopeIDs to be made highly available
$ScopeIDs = @(“10.0.0.0″,”172.16.0.0″,”192.168.0.0”)
# Shared Secret for communications between Primary and secondary DHCP servers
$secret = “Add a Password Here”


Write-Host -ForegroundColor Yellow “Creating DHCP Failover Relationship between ‘$PrimaryDHCP’ and ‘$SecondaryDHCP'”
Add-DhcpServerv4Failover -ComputerName $PrimaryDHCP -Name dhcp2.domain.local-dhcp3.domain.local $SecondaryDHCP -ScopeId $ScopeIDs -ReservePercent 5 -MaxClientLeadTime 1:00:00 -AutoStateTransition $true -StateSwitchInterval 1:00:00 -ServerRole Active -SharedSecret “$secret”
Write-Host -ForegroundColor Yellow “Finished Creating DHCP Failover. Please open DHCP Console on ‘$PrimaryDHCP’ to confirm the configuration”

Real World Tip

  • When you compare the GUI method to the PowerShell method for creating the Hot Standby for DHCP any errors returned throughout the process are much easier to capture in the GUI. When I ran this with PowerShell initially I was getting errors returned that suggested my syntax and use of the DHCP cmdlets was incorrect.
  • If you unsure if it’s actually the PowerShell cmdlets then run through the process in the GUI. Once I did this I got presented with an actual error code that allowed me to progress.

Error 20044 was displayed from the GUI indicating a missing vendor class from the server that will be the failover partner. More details here

More details on what a vendor class is here

  • If you create the failover relationship when the scopes are deactivated you will need to ensure that when you bring the scopes online on the primary DHCP server you replicate the scopes, this will ensure that the scopes on the failover partner are operational and are up to date.
  • The quick way to resolve this is to import the DHCP scopes from the old server you exported in Part 1. Once you complete this it will import all the vendor classes. Finish the process by deleting the scopes it has imported. This can be done with PowerShell and inline with my example scopes

Remove-DhcpServerv4Scope -ComputerName “dhcp3.domain.local” -ScopeId 10.0.0.0, 172.16.0.0, 192.168.0.0

More details here

Now re-run the Hot Standby Script, the relationship should now be created.

Testing

To test a failover of DHCP you can simply power off the server which is the primary partner or disable the NIC. You can use a little PowerShell to collect the relevant logs to make it easier to confirm the process is working as expected.

Get-WinEvent -FilterHashtable @{ ProviderName = ‘Microsoft-Windows-DHCP-Server’} | where {($_.Id -like “202*”) -and ($_.message -match “Relationship*”) }  | ft -AutoSize -Wrap | Out-File C:\Temp\Relationship.txt

The relationship name mentioned above can be filtered using a wild card if you know only part of the name or to save typing. Replace ‘Relationship’ with an actual DHCP relationship name

ProviderName: Microsoft-Windows-DHCP-Server

TimeCreated Id LevelDisplayName Message
———– — —————- ——-
01/02/2020 11:19:41 20251 Information The failover state of server: Primary.domain.com for failover relationship: dhcp2.domain.local-dhcp3.domain.local changed from: RECOVER_DONE to NORMAL.
01/02/2020 11:19:41 20251 Information The failover state of server: Failover.domain.com.dla.com for failover relationship: dhcp2.domain.local-dhcp3.domain.local changed from: PARTNER_DOWN to NORMAL.
01/02/2020 11:19:41 20251 Information The failover state of server: Primary.domain.com for failover relationship: dhcp2.domain.local-dhcp3.domain.local changed from: RECOVER_WAIT to RECOVER_DONE.
01/02/2020 11:09:39 20288 Warning This DHCP server Failover.domain.com.dla.com has transitioned to a PARTNER DOWN state for the failover relationship dhcp2.domain.local-dhcp3.domain.local and the MCLT period of 3600 seconds has expired. The server has taken over
the free IP address pool of the partner server Primary.domain.com for all scopes which are part of the failover relationship.
01/02/2020 10:19:40 20251 Information The failover state of server: Primary.domain.com for failover relationship: dhcp2.domain.local-dhcp3.domain.local changed from: RECOVER to RECOVER_WAIT.
01/02/2020 10:19:40 20251 Information The failover state of server: Primary.domain.com for failover relationship: dhcp2.domain.local-dhcp3.domain.local changed from: COMMUNICATION_INT to RECOVER.
01/02/2020 10:19:40 20259 Information The failover state of server: Primary.domain.com for failover relationship: dhcp2.domain.local-dhcp3.domain.local changed to : COMMUNICATION_INT.
01/02/2020 10:19:40 20254 Information Server has established contact with failover partner server 10.0.0.10 for relationship dhcp2.domain.local-dhcp3.domain.local .
01/02/2020 10:09:38 20251 Information The failover state of server: Failover.domain.com.dla.com for failover relationship: dhcp2.domain.local-dhcp3.domain.local changed from: COMMUNICATION_INT to PARTNER_DOWN.
01/02/2020 09:39:38 20252 Error The failover state of server: Failover.domain.com.dla.com for failover relationship: dhcp2.domain.local-dhcp3.domain.local changed from: NORMAL to COMMUNICATION_INT.
01/02/2020 09:39:38 20255 Error Server has lost contact with failover partner server 10.0.0.10 for relationship dhcp2.domain.local-dhcp3.domain.local .

To break this down a little further:

  1. At 09:39 – contact is lost between DHCP2 and DHCP3
  2. At 10:09 – the Switchover state (30 mins) expires and the DHCP3 takes full control of the scopes
  3. At 10:19 the DHCP2 is powered on and communication is re-established
  4. At 11:09 the MCLT (60 mins) expires
  5. 11:19 DHCP2 takes ownership for the scopes

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s