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:

1)       Add–DhcpServerv4Policy

2) Get–DhcpServerv4Policy

3)       Set–DhcpServerv4Policy  

4) Add–DhcpServerv4PolicyIpRange

5)       Get–DhcpServerv4PolicyIpRange

6)      Remove–DhcpServerv4PolicyIpRange

7)       Remove–DhcpServerv4Policy

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)

  1. Relay Agent Information
  2.  Agent Circuit ID
  3. Agent Remote ID
  4. 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> OROR <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> ANDAND<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:

  1. Below is an example of a scope level policy in scope 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 -Condition OR -MacAddress EQ,F8DB7F* -VendorClass EQ,Android

  1. 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 will be:

Get-DhcpServerv4Policy –ScopeId –Name DevicesPolicy | fl

 Its output would be of the format:

Name : DevicesPolicy

Description :

Enabled : True

ScopeId :

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 -Name DevicesPolicy -Condition OR - MacAddress EQ,FCC734*

To change the operator between the conditions of DevicesPolicy to AND instead of OR:

Set-DhcpServerv4Policy –ScopeId –Name DevicesPolicy –Condition And

For disabling DevicesPolicy:

Set-DhcpServerv4Policy –ScopeId –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, to with DevicesPolicy:

Add-DhcpServerv4PolicyIPRange –Name DevicesPolicy –ScopeId –StartRange –EndRange

Now any client that matches the policy will get an address from the range to

Adding another IP Address range from to to it:

Add-DhcpServerv4PolicyIPRange –Name DevicesPolicy –ScopeId –StartRange –EndRange

Any client that matches the policy will get an address from either the range to or from the range to


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 -Name DevicesPolicy | fl 

The output would be: 

Name : DevicesPolicy

ScopeId :

StartRange :

EndRange :

Name : DevicesPolicy

ScopeId :

StartRange :

EndRange : 


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 from DevicesPolicy:

Remove-DhcpServerv4PolicyIPRange -Name DevicesPolicy -ScopeId -StartRange –EndRange


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 -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 -PolicyName DevicesPolicy -OptionId 3 -Value

An example of using Get-DhcpServerv4OptionValue to view the options configured for DevicesPolicy:

Get-DhcpServerv4OptionValue -ScopeId -PolicyName DevicesPolicy | fl

The output would be:

OptionId : 3

Name : Router

Type : IPv4Address

Value : {}

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:

1)       Add-DhcpServerv4Scope  

2)       Set–DhcpServerv4Scope

3)       Set–DhcpServerSetting

4)       Get-DhcpServerV4Scope

5)       Get-DhcpServerSetting

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 –EndRange –SubnetMask –Name Scope1 -ActivatePolicies $true

For deactivating PBA on the scope

Set-DhcpServerv4Scope -ScopeId -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 |fl would give the output:

ScopeId :

Name : Scope_XYZ

Description :

SuperscopeName :

SubnetMask :

StartRange :

EndRange :

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.