DHCP Policies using PowerShell
The DHCP server role in Windows Server® 2012 introduces DHCP Policies also referred as Policy Based Assignment (PBA), a feature that enables users to create policies at scope or server level for assigning IPv4 addresses and options to DHCP clients based on attributes like Vendor Class, User Class, MAC Address etc. The DHCP Policies blog discusses various scenarios where policies can come in handy.
Policies can be configured at server and scope levels using either DHCP server MMC or PowerShell. This post discusses configuring policies using DHCP PowerShell. Below is a list of DHCP PowerShell cmdlets provided for configuring and monitoring policies:
4) Add–DhcpServerv4PolicyIpRange
5) Get–DhcpServerv4PolicyIpRange
6) Remove–DhcpServerv4PolicyIpRange
8) Get- DhcpServerv4OptionValue
9) Set-DhcpServerv4OptionValue
Apart from these, there are non-policy specific cmdlets of Add-DhcpServerv4Scope , Set–DhcpServerv4Scope, Set-DhcpServerSetting , Get-DhcpServerV4Scope and Get-DhcpServerSetting, which can be used for activating/deactivating PBA on the DHCP server or individual DHCP scopes.
Policy Grammar
To understand the usage of these cmdlets, let us understand the structure of a policy and its representation in PowerShell. A policy is composed of conditions that a DHCP client must satisfy for the policy to be applicable. It also contains specific IP ranges (optional and available only for scope level policies) and specific DHCP options which are to be used while assigning leases and options to such clients.
A condition is normally represented as a criterion or an expression. A criterion consists of an attribute, an operator and the value of the attribute.
criterion = <attribute> <operator> <value>
An attribute is an identifier of the DHCP client. The following are the attributes supported in PBA:
1) Vendor Class
2) User Class
3) Mac Address
4) Client ID
5) Relay Agent Information (and its sub-options)
- Relay Agent Information
- Agent Circuit ID
- Agent Remote ID
- Subscriber ID
If the administrator wishes to assign leases from a specific IP address range to the DHCP clients belonging to a particular system vendor, he/she can do so by creating a policy specifying a criterion for the attribute of Vendor Class. Similarly, by using the MAC Address attribute, an administrator can configure policies that would be applicable to clients with a particular MAC Address prefix.
The administrator can also configure criterions where an attribute, say a MAC Address, is not equal to a certain value or begins with a certain value. This can be achieved by using Not Equals and Begins With operators respectively. The permissible operators are:
1) Equals ( <attribute> EQ <value> )
2) Not Equals ( <attribute> NE <value> ))
3) Begins With ( <attribute> EQ <value>* ))
4) Not Begins With ( <attribute> NE <value>* ))
Criterion for a policy that is intended to be applied to all clients belonging to a particular set of user classes (all of which share a common prefix - LAB) would look like MacAddress EQ LAB* .
The administrator might want to include more than one values in a criterion. This may be useful in cases such as where an administrator might be looking to create a policy which is intended to be applied to a set of clients whose MAC addresses are known. Here he/she can use expressions.
An expression can be seen as a join of multiple criterions of the same attribute via the logical operator OR/AND. An expression is of the form:
<attribute> <operator> <value 1>, <value 2>, <value 3>, …,<value n>
If the <operator> is either Equals or Begins With, the criterion in the expression will be equivalent to the following:
<attribute> <operator> <value 1> OR <attribute> <operator> <value 2> OR <attribute><operator><value 3> OR … OR <attribute><operator><value n>
If the <operator> is either Not Equals or Not Begins With, the criterion in the expression will be equivalent to the following:
<attribute> <operator> <value 1> AND <attribute> <operator> <value 2> AND <attribute><operator><value 3> AND …AND<attribute><operator><value n> A condition, which can be either a criterion or an expression, deals with only one attribute. A single policy can have one or more conditions. This comes in handy when the policy intends to identify clients based on more than one attributes. Multiple conditions can be joined in the policy using logical operators AND or OR.
An administrator creates a policy specifying conditions and then associates with it IP address ranges (only in scope level policies) and options. A client satisfying the conditions of the policy is assigned an IP address from the specified range and the specified DHCP options.
So, what happens when a DHCP client satisfies the conditions of more than one policies? Every policy has a processing order associated with it. It is essentially the priority of that policy and helps in deciding which policy needs to be applied if multiple policies match a client. A policy with a higher priority (numerically lower processing order) precedes over a policy with a lower priority (numerically higher processing order).
Policy cmdlets
Let us now take a detailed look at the PowerShell cmdlets for configuring policies:
Adds a new policy either at the server level or at the scope level.
Add-DhcpServerv4Policy [-Name] <String> [-Condition] <String> [-AsJob] [-CimSession <CimSession[]> ] [-CircuitId <String[]> ] [-ClientId <String[]> ] [-ComputerName <String> ] [-Description <String> ] [-Enabled <Boolean> ] [-MacAddress <String[]> ] [-PassThru] [-ProcessingOrder <UInt16> ] [-RelayAgent <String[]> ] [-RemoteId <String[]> ] [-ScopeId <IPAddress> ] [-SubscriberId <String[]> ] [-ThrottleLimit <Int32> ] [-UserClass <String[]> ] [-VendorClass <String[]> ] [-Confirm] [-WhatIf] [ <CommonParameters>]
It only creates a policy with the specified conditions. Post this, the administrator will need to execute the cmdlets Add–DhcpServerv4PolicyIpRange and Set-DhcpServerv4OptionValue to associate IP range (only for a scope level policy) and option values respectively with the policy.
The Policy name must be unique at the level (server/scope) where it’s being created and should have at least one condition specified. Let’s see some examples where an administrator wants to create policies for the following situations:
- Below is an example of a scope level policy in scope 10.0.0.0 for clients with MAC address prefix of HTC phones or vendor class of Android. The vendor class definition needs to be added to the DHCP server before being used in the policy. See cmdlet Add-DhcpServerv4Class.
Add-DhcpServerv4Policy -Name DevicesPolicy -ScopeId 10.0.0.0 -Condition OR -MacAddress EQ,F8DB7F* -VendorClass EQ,Android
- Here is an example of a server level policy for non-Hyper-V clients. The MAC addresses of Hyper-V VMs (
00-15-5D) and VMware VMs (000569) have been used in a negation condition in the policy.
Add-DhcpServerv4Policy -Name PhysicalComputersPolicy -Condition OR -MacAddress NE,00155D*,000569*
If no processing order is specified, the policy is created with a processing order which is numerically higher by one than the policy with the highest processing order already present on the server/scope. To create a policy with the highest priority (numerically lowest processing order), processing order should be specified as zero.
Gets one or more policies at the server level or the scope level.
Get-DhcpServerv4Policy [[-Name] <String[]> ] [[-ScopeId] <IPAddress> ] [-AsJob] [-CimSession <CimSession[]> ] [-ComputerName <String> ] [-ThrottleLimit <Int32> ] [ <CommonParameters>]
The cmdlet for viewing DevicesPolicywhich was configured for Scope ID 10.0.0.0 will be:
Get-DhcpServerv4Policy –ScopeId 10.0.0.0 –Name DevicesPolicy | fl
Its output would be of the format:
Name : DevicesPolicy
Description :
Enabled : True
ScopeId : 10.0.0.0
ProcessingOrder : 1
Condition : OR
VendorClass : {EQ, Android}
UserClass :
MacAddress : {EQ, f8-db-7f-*}
ClientId :
RelayAgent :
CircuitId :
RemoteId :
SubscriberId :
Sets the properties of an existing policy either at the server level or at the specified scope level.
Set-DhcpServerv4Policy [-Name] <String> [[-ScopeId] <IPAddress> ] [-AsJob] [-CimSession <CimSession[]> ] [-CircuitId <String[]> ] [-ClientId <String[]> ] [-ComputerName <String> ] [-Condition <String> ] [-Description <String> ] [-Enabled <Boolean> ] [-MacAddress <String[]> ] [-NewName <String> ] [-PassThru] [-ProcessingOrder <UInt16> ] [-RelayAgent <String[]> ] [-RemoteId <String[]> ] [-SubscriberId <String[]> ] [-ThrottleLimit <Int32> ] [-UserClass <String[]> ] [-VendorClass <String[]> ] [-Confirm] [-WhatIf] [ <CommonParameters>]
It can used to modify existing policies. For modifying the MAC address prefix based condition of DevicesPolicy to make it applicable to devices of some other manufacturer (which have a different prefix). The existing MAC address based condition will be replaced. The other condition based on the vendor class filed will be retained and logically combined (OR’d) with this new condition.
Set-DhcpServerv4Policy –ScopeId 10.0.0.0 -Name DevicesPolicy -Condition OR - MacAddress EQ,FCC734*
To change the operator between the conditions of DevicesPolicy to AND instead of OR:
Set-DhcpServerv4Policy –ScopeId 10.0.0.0 –Name DevicesPolicy –Condition And
For disabling DevicesPolicy:
Set-DhcpServerv4Policy –ScopeId 10.0.0.0 –Name DevicesPolicy -Enabled $false
Adds an IP range to an existing policy at the scope level.
Add-DhcpServerv4PolicyIPRange [-Name] <String> [-ScopeId] <IPAddress> [-StartRange] <IPAddress> [-EndRange] <IPAddress> [-AsJob] [-CimSession <CimSession[]> ] [-ComputerName <String> ] [-PassThru] [-ThrottleLimit <Int32> ] [-Confirm] [-WhatIf] [ <CommonParameters>]
To associate an IP address range (say, 10.0.0.1 to 10.0.0.100) with DevicesPolicy:
Add-DhcpServerv4PolicyIPRange –Name DevicesPolicy –ScopeId 10.0.0.0 –StartRange 10.0.0.1 –EndRange 10.0.0.100
Now any client that matches the policy will get an address from the range 10.0.0.1 to 10.0.0.100.
Adding another IP Address range from 10.0.0.101 to 10.0.0.200 to it:
Add-DhcpServerv4PolicyIPRange –Name DevicesPolicy –ScopeId 10.0.0.0 –StartRange 10.0.0.150 –EndRange 10.0.0.200
Any client that matches the policy will get an address from either the range 10.0.0.1 to 10.0.0.100 or from the range 10.0.0.150 to 10.0.0.200.
Gets one or more IP ranges from a policy in the specified scope.
Get-DhcpServerv4PolicyIPRange [-ScopeId] <IPAddress> [[-Name] <String[]> ] [-AsJob] [-CimSession <CimSession[]> ] [-ComputerName <String> ] [-ThrottleLimit <Int32> ] [ <CommonParameters>]
To view the IP address ranges associated with DevicesPolicy:
Get-DhcpServerv4PolicyIPRange -ScopeId 10.0.0.0 -Name DevicesPolicy | fl
The output would be:
Name : DevicesPolicy
ScopeId : 10.0.0.0
StartRange : 10.0.0.1
EndRange : 10.0.0.100
Name : DevicesPolicy
ScopeId : 10.0.0.0
StartRange : 10.0.0.150
EndRange : 10.0.0.200
Remove–DhcpServerv4PolicyIpRange
Deletes an IP range from an existing policy at the scope level.
Remove-DhcpServerv4PolicyIPRange [-Name] <String> [-ScopeId] <IPAddress> [[-StartRange] <IPAddress> ] [[-EndRange] <IPAddress> ] [-AsJob] [-CimSession <CimSession[]> ] [-ComputerName <String> ] [-PassThru] [-ThrottleLimit <Int32> ] [-Confirm] [-WhatIf] [ <CommonParameters>]
For deleting the IP range 10.0.0.150-10.0.0.200 from DevicesPolicy:
Remove-DhcpServerv4PolicyIPRange -Name DevicesPolicy -ScopeId 10.0.0.0 -StartRange 10.0.0.150 –EndRange 10.0.0.200
Deletes one or more specified IPv4 policies either at the server level or the specified scope level. It also removes the option values associated with the policy.
Remove-DhcpServerv4Policy [-Name] <String[]> [[-ScopeId] <IPAddress> ] [-AsJob] [-CimSession <CimSession[]> ] [-ComputerName <String> ] [-PassThru] [-ThrottleLimit <Int32> ] [-Confirm] [-WhatIf] [ <CommonParameters>]
To delete DevicesPolicy:
Remove-DhcpServerv4Policy -ScopeId 10.0.0.0 -Name DevicesPolicy
Configuring policy specific options
We are still to discuss configuring options for policies. It can be achieved using the cmdlets Get- DhcpServerv4OptionValue and Set-DhcpServerv4OptionValue . These cmdlets can be used for getting/setting the options configured for a policy.
Here is an example which uses Set-DhcpServerv4OptionValue to set the value of option id 3 (router) for DevicesPolicy.
Set-DhcpServerv4OptionValue -ScopeId 10.0.0.0 -PolicyName DevicesPolicy -OptionId 3 -Value 192.168.1.10
An example of using Get-DhcpServerv4OptionValue to view the options configured for DevicesPolicy:
Get-DhcpServerv4OptionValue -ScopeId 10.0.0.0 -PolicyName DevicesPolicy | fl
The output would be:
OptionId : 3
Name : Router
Type : IPv4Address
Value : {192.168.1.10}
VendorClass :
UserClass :
PolicyName : DevicesPolicy
Activating/Deactivating PBA
There are also a few other cmdlets which are useful in PBA. An administrator may want to turn off policy application for a server/scope without affecting the individual policies. He/She can do so by deactivating PBA at server/scope level. The following cmdlets can be used for the purpose:
Add-DhcpServerV4Scope/Set-DhcpServerv4Scope can be used for activating/deactivating PBA for a scope:
For creating a new scope with PBA activated:
Add-DhcpServerv4Scope -StartRange 11.0.0.1 –EndRange 11.0.0.254 –SubnetMask 255.0.0.0 –Name Scope1 -ActivatePolicies $true
For deactivating PBA on the scope 11.0.0.0:
Set-DhcpServerv4Scope -ScopeId 11.0.0.0 -ActivatePolicies $false
Similarly Set-DhcpServerSetting can be used to activate/deactivate PBA at the server level.
Set–DhcpServerSetting –ActivatePolicies $false
Get-DhcpServerv4Scope and Get-DhcpServerSetting cmdlets can be used to check the current value of ActivatePolicies (true if PBA is activated, false otherwise).
Get-DhcpServerV4Scope –ScopeId 10.0.0.0 |fl would give the output:
ScopeId : 10.0.0.0
Name : Scope_XYZ
Description :
SuperscopeName :
SubnetMask : 255.0.0.0
StartRange : 10.0.0.1
EndRange : 10.0.0.254
LeaseDuration : 8.00:00:00
NapProfile :
NapEnable : False
Delay(ms) : 0
State : Active
Type : Dhcp
MaxBootpClients : 4294967295
ActivatePolicies : True
Get-DhcpServerSetting |fl would give the output:
IsDomainJoined : True
IsAuthorized : True
DynamicBootp : True
RestoreStatus : False
ConflictDetectionAttempts : 0
NpsUnreachableAction : Full
NapEnabled : False
ActivatePolicies : True
We hope this blog post was useful. Do let us know if you have any questions, comments or feedback.
Other Links
- About DHCP policies
- Step-by-step to configure DHCP policies
- Scope-level Link Layer filtering using DHCP policies
- Setting up DHCP Policies for Virtual Machines
- Set different lease durations for different device types