Setting Up a DHCP Server for your

Organization
One of the most basic processes on a network is that of assigning IP addresses to network clients.
Although there are many different types of DHCP servers that can do the job, you can configure
Windows Server 2003 to act as a DHCP server. In this article, I will show you how.
Years ago, I used to be a network administrator for an organization that had some rather odd
security policies in place. One of the existing policies when I got there was that all computers
had to be assigned a static IP address. DHCP servers were forbidden for security reasons. The
result was a maintenance nightmare. Obviously, some servers have a legitimate need for static IP
addresses, but usually it is perfectly acceptable for workstations to use dynamic IP addresses.
Generally speaking, using static IP addresses on workstations is only truly feasible on small
networks. Unfortunately, the network that I spoke of a moment ago was anything but small. It
had 25,000 workstations.
This network was a logistical nightmare for several reasons. For starters, any time that a PCs
hard disk crashed, someone had to figure out which IP address had been assigned to that PC
before Windows could be reloaded. You can imagine what it was like to try to figure out which
of the 25,000 IP addresses was supposed to be assigned to the machine that was being rebuilt.
There was no central list of addresses. Each building had their own address block to manage, and
consequently, there was no standard for managing addresses. Quite frequently, someone would
assign a PC an address that had already been used, resulting in an IP address conflict that forced
someone elses PC off of the network.
Hopefully, this story shows you why it is a good idea to assign dynamic IP addresses to the
workstations on your network. Fortunately, the process of configuring a Windows 2003 Server to
act as a DHCP server is simple. Furthermore, in most cases, the DHCP services place such a
small burden on the server that the DHCP services can often be run on one of your existing
servers rather than you having to invest in a dedicated machine. In this article, I will show you
how to install the DHCP services on a Windows 2003 Server. I will also take the opportunity to
discuss some common DHCP configuration issues.

Avoiding DHCP Conflicts

As you will see later on, the Active Directory is designed to prevent rogue DHCP servers from
being placed onto your network. The idea is that you dont want to have an unauthorized DHCP
server assigning an invalid block of IP addresses to the computers on your network. However,
this protective mechanism is only effective if the rogue DHCP server is running a Windows
operating system and is attempting to interact with the Active Directory.

Microsoft didnt invent DHCP and DHCP servers are certainly not unique to Windows networks.
In fact, its very possible that you might have a DHCP server on your network right now and not
even know it.
When most people think of a DHCP server, they tend to think of a Windows, UNIX, Linux, or
perhaps a NetWare or Macintosh server that is configured to assign IP addresses to clients. While
these are certainly types of DHCP servers, you would probably notice it if someone brought one
of these types of servers online on your network (at least I hope you would notice it). The most
common type of rogue DHCP server is a router with a built in DHCP service. For example,
wireless access points are available at any electronics store for a ridiculously low price. The vast
majority of wireless access points have a built in DHCP server that is enabled by default.
Typically, these devices are set up to assign an address in the 192.168.x.x range to any client
(wireless or wired) that requests it. The DHCP services arent just limited to wireless access
points though. Youve probably seen low budget routers that are designed to connect a small
network to a broadband Internet connection. These devices almost always have a built in firewall
and a built in DHCP server.
A DHCP server can also be software based. For example, most of the Windows operating
systems that have been released in the last decade offer a service called Internet Connection
Sharing (ICS). The idea behind ICS is that one computers internet connection can be shared
with other computers on the network. The ICS service implements its own mini DHCP service.
Just for the record, ICS and the DHCP services that are a part of the Windows Server have
trouble co-existing on a network.
The biggest trick to making the DHCP services work well on your network is to make sure that
the IP address range that the server is handing out does not overlap with the addresses being
handed out by another DHCP server on your network. If there are other DHCP servers present,
you must make sure that they are configured to assign appropriate addresses to your
workstations. Its perfectly OK to use multiple DHCP servers on your network. In fact, doing so
provides you with a degree of fault tolerance. You must however make sure that each DHCP
server is assigned a block of IP addresses that does not overlap with an address block managed
by another DHCP server. These blocks of addresses are known as scopes.
If you arent aware of any DHCP servers on your network, then I recommend performing a quick
test prior to deploying a Windows based DHCP server just to verify the absence of DHCP servers
on your network. The easiest way to confirm that no DHCP servers are presently active is to
configure a workstations TCP/IP settings so that the workstation acquires an IP address
automatically. After doing so, simply reboot the computer and see if it is assigned an IP address.
You can determine whether or not an IP address has been assigned by opening a Command
Prompt window and entering the IPCONFIG /ALL command.
Advertisement

Installing a DHCP Server

Now that I have talked about how you can avoid DHCP conflicts, lets talk about how to install
and configure a Windows Server 2003 based DHCP server. Before I get started, I should mention
that the server itself must be configured to use a static IP address.
Begin the process by selecting the Add / Remove Programs option in the Control Panel. When
the Add / Remove Programs dialog box opens, click the Add / Remove Windows Components
button. After a brief delay, Windows will open the Windows Components Wizard. Scroll through
the list of available components until you find the Networking Services option. Select
Networking Services and then click the Details button. You will now see a list of the various
Windows network services. Select the check box next to Dynamic Host Configuration Protocol
and click OK, followed by Next. Windows will now begin to copy the necessary files. During
this operation, you may be prompted to insert your Windows Server installation CD. When the
file copy operation completes, click Finish to close the wizard.

Configuring a DHCP Server

The process of configuring the DHCP services is almost as simple as the installation was. Before
you begin the configuration process though, you will need to come up with at least one scope.
Remember that a scope is a range of IP addresses that the DHCP server can lease to clients.
Begin by opening the DHCP console. You can access the DHCP console by selecting the DHCP
command from the servers Administrative Tools menu. When the console opens, the first thing
that you will want to do is to create a new scope. To do so, right click on your server and select
the New Scope command from the resulting shortcut menu. This will cause Windows to launch
the New Scope wizard. Click Next to bypass the wizards Welcome screen and you will be
prompted to enter a name and a description for the scope. After doing so, click Next and you will
see a screen prompting you to enter the beginning and ending addresses of the scope range. After
doing so, you must also enter the subnet mask to be used by the addresses (or the number of bits
to use for a subnet) before clicking next.
The next screen gives you a chance to enter any necessary exclusions. Exclusions are addresses
within the scope that are already in use. Entering an exclusion address prevents the DHCP server
from leasing that address. Enter any exclusions that you might have and click Next. You will
now be prompted to enter a lease duration. The lease duration is the length of time that a
workstation can use an IP address before having to either give the address up or renew it. The
default lease period is eight days, which works fine in most cases.
Click Next and you will see a screen asking if you want to configure extra DHCP options. Select
the Yes option and click Next. You are now given the opportunity to enter the address for a
default gateway. Click Next and you are presented with a screen that allows you to enter the IP
address of one or more DNS servers. Click next one more time and you will be allowed to enter
the addresses of any WINS servers that may exist on your network (newer networks do not

usually use WINS servers). Click Next once more and you will be asked whether or not you wish
to activate the scope. Select the yes option and click Next followed by Finish.
Although the newly created scope has been activated it wont be used just yet because the DHCP
server has not been authorized to issue addresses for your network. To solve this situation, right
click on the servers listing within the DHCP console and select the Authorize command from
the shortcut menu. Assuming that you are logged in as a domain administrator, the server will be
authorized to start servicing requests.

Conclusion
In this article, I explained that setting up a DHCP server provides you with an easy way of
assigning IP addresses to workstations on your network. I then went on to show you how to
install and configure a DHCP Server and how to avoid overlapping scopes.
Windows Server 2012 DHCP

Introduction
Dynamic host configuration protocol (DHCP) is one of the most commonly implemented
network services in todays network environments. In this article I will review the deployment
and configuration of the DHCP server role in Windows Server 2012. We will revise the DHCP
leasing process, DHCP options, DHCPv4 and DHCPv6 scopes, and auto configuration.
Advertisement

The Case for DHCP

DHCP is primarily used to automatically distribute critical IP configuration settings to network
clients, eliminating the tedious and burdensome task of manually configuring hosts on TCP/IPbased networks. It also provides configuration information and interacts with other networking
services such as domain name system (DNS), windows deployment services (Windows DS) and
network access protection (NAP).
Without DHCP service, you have to individually configure each network client with the correct
internet protocol settings, including the IP address, the networks subnet mask, the default
gateway, and the DNS server address. These settings are necessary for the network clients to
communicate within and outside their network locations. You have to repeat this manual
configuration process any time you bring a new device to the network or you move one to a
different subnet.
Many organizations manage hundreds or thousands of network client devices, including smart
phones, tablets, desktop computers, and laptops. The DHCP service helps to ensure that all
network clients have correct configuration settings, eliminating fat fingers and other human
errors that may occur when we have to enter the information manually. Network configuration
changes can be updated on the DHCP server without having to change the information directly
on each client computer.

DHCP Server Authorization

In an active directory infrastructure, to prevent an incorrectly configured DHCP server or a rogue
DHCP server from distributing IP addresses, DHCP servers are not allowed to start servicing
clients before they are authorized to operate in the network. DHCP authorization is the process of
registering the DHCP Server in the active directory database to service DHCP clients. An
enterprise administrator account is necessary to authorize Windows Server 2012 DHCP servers;
once it is authorized, the DHCP server can support multiple domains in the same active directory
forest.
A standalone (no domain member) Windows Server 2012 DHCP server can detect an authorized
DHCP server in a domain. When that happens, the standalone DHCP server does not lease IP
addresses and shuts down automatically.

Deploying the DHCP Server Role

These are the steps necessary to add the DHCP server role to a Windows Server 2012 computer:
1. In Server Manager, click Add roles and features.

Figure 1
2. In the Add Roles and Features Wizard, click Next.

Figure 2
3. On the Select installation type page, click Next.

Figure 3
4. On Select destination server page, click Next.

Figure 4
5. On the Select server roles page, select the DHCP Server check box.

Figure 5
6. In the Add Roles and Features Wizard, click Add Features, and then
click Next.

Figure 6
7. On the Select features page, click Next.

Figure 7
8. On the DHCP Server page, click Next.

Figure 8
9. On the Confirm installation selections page, click Install.

Figure 9
10.On the Installation progress page, wait until the Installation succeeds.

Figure 10
Once the installation completes, you can proceed to authorize the DHCP server or start
configuring the DHCP scopes.

DHCPv4 Scopes
By configuring DHCP scopes, you make IP addresses available to the DHCP clients. A DHCP
scope is a pool or range of IP addresses that are available for lease from the DHCP server.
Usually a DHCP scope is limited to the IP addresses in a prearranged IP subnet. DHCP scopes
must be activated before their IP addresses become available in the network.
On Windows Server 2012, you configure a DHCP scope along with the following settings:
Name and description. This is used to identify the scope. The name is mandatory, the
description is optional.
IP address range. This is the starting pool of IP addresses that are available for lease. This pool
usually lists the entire range of addresses for a defined IP subnet.
Subnet mask. This property provides space to configure the bit length and the decimal notation
for the subnet mask.

Both fields are automatically filled when you enter the IP address range. You may need to change
those values when using non default class A, B, or C networks. The subnet mask is used to
separate the network ID from the host ID component in the IP address; this allows TCP/IP hosts
to determine their location in the network.
Exclusions. Here you list single addresses or range of addresses that belong to the IP address
pool, but that will not be offered for lease usually because they have been manually assigned to
servers in the network. For example, if the DHCP server is deployed to the same subnet, it will
need at least one IP address from the pool. That IP address should be excluded from the scope.
Subnet Delay. This is the amount of time in milliseconds that the DHCP server waits before
sending a DHCPOFFER. The default value is 0; when having two DHCP servers servicing the
same IP subnet, you may change the default settings on your lower-priority DHCP server by
increasing the subnet delay value.
Lease duration. This is the amount of time for which clients are allowed to use the IP addresses
without renewal. It is recommended to use shorter durations for scopes with limited IP addresses
or a significant number of mobile clients, and longer durations for more static networks.
DHCP Reservations:
A DHCP reservation is a given IP address from within a scope that is set aside for lease to a
specific DHCP client. DHCP reservation ensures that the IP addresses that you reserve from a
configured scope are not leased to any other device in the network. A DHCP reservation also
ensures that devices with reservations are certain to have their IP address even if a scope runs out
of available IP addresses. The devices network interface media access control (MAC) address or
physical address is necessary to configure a reservation. If the client is already leasing an IP
address from a Windows Server 2012 DHCP server, its MAC address will be available from the
DHCP management console.
DHCP Options:
DHCP options are configuration settings that are applied to the DHCP clients when they lease or
renew their IP addresses from a DHCP server. An option code identifies the DHCP options; many
DHCP options are available, among the most common ones are:

* Option 003 Router (the default gateway for the subnet)

* Option 006 Domain Name System (DNS) servers

* Option 015 DNS suffix

On a Windows Server 2012, you can configure DHCP options at the server, scope, reserved
client, and class levels. When troubleshooting the DHCP service, it is critically important that

you understand the order in which DHCP applies these options to client computers. DHCP
options are applied in the following order:
1. Server level. A server-level option is assigned to all DHCP clients of the
DHCP server. Server options can be superseded by scope, class, and clientassigned options.
2. Scope level. These settings are applied to clients that obtain a lease within
that specific scope. Scope options consistently apply to all computers
acquiring a lease from a given scope unless they are superseded by class or
reserved client options.
3. Class level. Client class can be user-defined or vendor-defined. A class-level
option is assigned to all clients that identify to the DHCP server as members
of a class. Class options can be superseded by reserved client level options.
4. Reserved client level. This is a reservation-level option that is assigned to
one DHCP client. If DHCP option settings are configured at each level and
they conflict, then the option that is applied last overrides the previously
applied setting. Because the reserved client options are the last one to apply,
they will override all the previous levels in case of conflicting settings.

DHCP Lease Generation Process

Understanding the steps involved in the lease and renewal of IP addresses helps you troubleshoot
problems when clients cannot obtain their configuration from a DHCP server. There are four
steps in the DHCP lease process:
1. DHCPDISCOVER. The DHCP client broadcasts a DHCPDISCOVER packet in
the subnet. All computers in the subnet receive this packet; however, only
the DHCP server responds. If there is no DHCP server in the subnet, then a
computer or router configured as DHCP Relay agent forwards the message to
a DHCP server located in another subnet
2. DHCPOFFER. All DHCP servers that receive the client DHCPDiscover packet
reply with a DHCPOffer packet. This packet contains IP configuration settings
including an available IP address and subnet mask.
3. DHCPREQUEST. The client might receive DHCPOFFER packets from more
than one DHCP server; if that is the case, the DHCP client typically selects the
DHCP server that responded first to its DHCPDISCOVER packet. The client
then broadcasts a DHCPREQUEST identifying the DHCP server from which is
willing to lease the IP settings. This broadcast reaches all other the DHCP
servers so they know which servers DHCPOFFER the client has accepted.
4. DHCPACK. The selected DHCP server stores the IP address client information
in the DHCP database and sends back a DHCPACK message and any optional
configuration parameters. It is possible for the DHCP server to send a
DHCPNAK message; this may happen if the IP address is invalid or it is being

used by another computer. In this case the client begins the lease process
again.

DHCP clients try to renew their leases after every reboot or startup. This is a great feature,
especially for mobile devices since users may move their laptops or tables to different locations
or subnets and those devices can automatically obtain the right IP configuration to operate in the
new environment. The lease period is reset after each renewal. You can force a renewal by
executing the following command: ipconfig /renew. If a device stays on, it will attempt to renew
its lease when 50% of its lease time has elapsed. This is a transparent background process in
which the DHCP client broadcasts a DHCPREQUEST message. If the DHCP server that leased
the IP addresses is available, it will send a DHCPACK message back to the client. If some
options have changed since the original lease, the DHCP server includes the new values with the
DHCPACk message.
If the DHCP client cannot talk with the DHCP server, then the client waits until 87.5 percent of
the lease time passes and then tries to renew again. If 100 percent of the lease time has expired
and the renewal is unsuccessful, the client goes into autoconfiguration mode.

DHCPv4 Autoconfiguration
If a DHCP server is not available and the previous lease has expired, the client computer
executes an automatic private IP addressing (APIPA) process to assign itself a valid IPv4 address
from the 169.254.0.0 subnet with a mask of 255.255.0.0. Before it starts using the new IPv4
address, the client performs an address resolution protocol (ARP) test to ensure that the selected
IP address is not being used by any other client in that network. After it configures itself with its
new APIPA address, the client keeps sending broadcasts every five minutes to the network,
trying to contact a DHCP server. Whenever a DHCP server responds, the client negotiates a new
lease, and configures the NIC with the new IPv4 address obtained from the DHCP server.

DHCPv6 Scopes
On Windows Server 2012, DHCPv6 scopes are created and configured separately from IPv4
scopes. Lets review the step-by-step configuration of a DHCPv6 scope.
1. On the DHCP Server console, right click IPv6 and select New Scope.

Figure 11
2. On the Welcome to the New Scope Wizard, click Next

Figure 12
3. On the Scope Name, enter Name and Description information.

Figure 13
4. On the Scope Prefix, enter the corresponding prefix for your IPv6 network. If
you have multiple DHCPv6 servers, the preference value can be modified
to indicate your priority among the servers. The lower this value, the higher
the priority.

Figure 14
5. On the Add Exclusions, enter any IPv6 address that belongs to that scope
but has been manually assigned to other devices in the network. This
includes the IPv6 address that is manually configured on the DHCPv6 server
itself. Additional exclusion can be added after the initial DHCPv6 scope has
been configured.

Figure 15
6. On the Scope Lease, configure two settings:
7. Preferred Life Time is the length of time that a valid IPv6 address is
preferred. When this time expires, the address becomes deprecated but it is
still valid.
8. Valid Life Time is the length of time that an IPv6 is in the valid state. The
address becomes invalid after the valid life time expires. The valid life rime
must be equal or greater than the preferred life time.

Figure 16
9. On the Completing the New Scope Wizard, click Finish to activate the
scope.

Figure 17
As on IPv4 scopes, you can configure exclusions, reservations, and DHCP options on IPv6
scopes. However, DHCPv6 clients do not use their MAC addresses when contacting a DHCP
server. Instead a device unique identifier (DUID) is used by clients to get an IP address from a
DHCPv6 server.

DHCPv6 Autoconfiguration
IPv6 supports both stateful address configuration and stateless address configuration. Stateful
address configuration happens when a DHCPv6 server assigns the IPv6 address to the DHCPv6
client in conjunction with additional DHCP configuration options.
Stateless address configuration is an autoconfiguration process by which IPv6 clients assign
themselves IPv6 address without ever talking to a DHCPv6 server. It is possible to use a
combination of both. For example, you may configure your DHCPv6 client in stateless mode so
that they dont need a DHCPv6 server to obtain an IP address, but you may assign the DNS
server address to the same clients using a DHCPv6 server.

Even though routers play an important role in the aotuconfiguration process of DHCPv6 clients,
even without a router present, hosts in the same subnet can automatically configure themselves
with IPv6 addresses based on the link-local prefix of FE80::/64; this allows the clients to
communicate in the local subnet without manual configuration. Before using an auto-selected
link-local unicast IPv6 address, a duplicate address detection process is performed to ensure that
the select IP address is not being used by another host in the subnet. If the duplicate address
detection is successful, the link-local address is initialized for the interface.
In this article we concentrated on the deployment of the DHCP server role on Windows Server
2012 and how the DHCP server scopes and autoconfiguration play an important role for IPv4
and IPv6 clients in the network. In our next article we will focus on the DHCP service
availability and some of the new features on Windows Server 2012.

The DHCP Database

Guarding and maintaining the DHCP database is important for system administrators not only to
provide consistent performance, but also to minimize unscheduled downtime due to unexpected
server or network snags.
The DHCP database is a dynamic database that stores the DHCP configuration information and
the lease data for clients that have leased an IP address from the DHCP server; this includes
DHCP options, scope configuration, address leases, exclusion, and reservations. By default, the
following DHCP database files are stored in the %systemroot%\System32\Dhcp folder.
* Dhcp.mdb This is the DHCP server database file.
* Dhcp.tmp A temporary file that the DHCP database uses as a swap file during database
index maintenance operations.
* J50.log and J50#####.log These are logs of all database transactions. These logs may be
used by the DHCP server for data recovery.
* J50.chk A checkpoint file that is updated every time data is written to the DHCP.mdb
database file. This checkpoint file can be used during recovery to indicate where the recovery or
replaying of data should begin.
Advertisement

Backup and Restore

By default, the DHCP database and associated registry entries are backed up automatically at 60minute intervals. There is no GUI to change the backup interval; however if you want to change
the default settings, you can do so in the following registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DHCPServer\Parameters

You can also back up a DHCP database manually at any time. There is no need to stop the DHCP
service to perform a backup of the database. The default path for the DHCP backup is
systemroot\System32\Dhcp\Backup. It is possible to modify this path in the server properties to
point to another hard drive. Backing up the DHCP database over the network is not possible.
You can use the restore function in the DHCP server console to restore the database. When
performing a restore, after you select the location, the DHCP service stops and the database is
restored. You must be a member of the administrators group or the DHCP administrators group
to perform a DHCP database restore.
Reconciling scopes helps to resolve inconsistencies on the DHCP database. The DHCP Server
service stores detailed IP address lease information in the DHCP database and summary IP
address lease information in the Windows Server registry. When you reconcile the DHCP scopes,
the detail and summary entries are compared to verify inconsistencies. During this process, the
DHCP service may restore those inconsistent IP addresses to the original clients, or it may set
aside those IP addresses in the form of temporary reservations with duration equal to the lease
time assigned to the scope.

Using DHCP Relay Agents to provide DHCP service across multiple

subnets.
DHCPv4 uses IP broadcasts and DHCPv6 uses multicasts; in both cases, DHCP servers are
limited to communication within their IP subnet. If your organization has a large number of
subnets, you have to either deploy a DHCP server on each subnet or provide DHCP service
across multiple subnets by configuring DHCP relay.
Using DHCP relay means that you configure a DHCP relay agent on each subnet where a DHCP
server is not present. A DHCP relay agent is a computer or router that listens for DHCPv4
broadcasts from DHCPv4 or DHCPv6 multicast from DHCPv6 clients and then relays them to
DHCP servers in different subnets. DHCPv4 and DHCPv6 need separate DHCP relay
configurations. In either case however, you cannot deploy the DHCP relay agent component on a
Windows Server that is running the DHCP service; the network address translation (NAT)
routing protocol component with automatic addressing enabled, or Internet connection sharing
(ICS).

DHCP Service Availability

Even though you may be able to service thousands of clients from a single DHCP server, it is a
best practice to implement at least two DHCP servers to improve reliability and fault tolerance
with the additional benefit in some cases of configuring load balancing to distribute the workload
across multiple DHCP servers.
One possible approach is to configure the DHCP service using the Windows Server 2012 cluster
feature or a third-party clustering solution. If one DHCP server fails, the DHCP service can fail

over to another DHCP server in the cluster. In this implementation, the DHCP servers have
access to a storage area network (SAN) where the DHCP database and related files are stored.
To improve availability and load balancing, there are two other Windows Server 2012 DHCP
native solutions that are less complicated than deploying Windows Server clusters; they are split
scopes and DHCP Failover.

DHCP Split Scopes

Split scope allows you to improve the load balancing and fault tolerance of the DHCP service by
configuring two DHCP servers that serve the same subnet without IP address overlapping. This
feature is only available for IPv4 and cannot be configured on IPv6 scopes.
Using a wizard-based configuration, you use two stand-alone DHCP servers to make a certain
percentage of a scopes IP addresses available on one DHCP server while the remaining IP
addresses are assigned to the second DHCP server. For this to work, each DHCP server is
configured with the same scope range but with different exclusions within that range. The
exclusions are necessary because the DHCP servers do not share their lease database
information. Each server must be configured to assign only a subset of the available IP address
from a given scope.
Lets say that you have a scope of 192.168.1.0 /24 and you want to configure a split scope using
two DHCP servers: DHCP1 and DHCP2. You want to assign 70% of the IP addresses in the
subnet to DHCP1 and the other 30% to DHCP2.
The DHCP scope may be configured as follows:
DHCP1 Scope configuration:
Range: 192.168.1.1 to 192.168.1.254
Exclusion: 192.168.1.178 to 192.168.1.254
DHCP2 Scope configuration:
Range: 192.168.1.1 to 192.168.1.254
Exclusion: 192.168.1.1 to 192.168.1.177
As part of the split-scope implementation, you need to specify the second DHCP server involved
in the process. Running the Split-scope Configuration wizard on DHCP1 allows you to allocate
the IP address pool in the right proportion; the wizard automatically creates the scope and the
corresponding exclusions on DHCP2. You still need to activate the scope on DHCP2 before its
IP addresses become available to DHCP clients in the network. The figure below show the
DHCP split-scope configuration wizard being run from DHCP1.

Figure 1
It is possible to configure a time delay on the DHCP2 server (see figure below). The delay in
DHCP Offer allows DHCP2 to wait before responding to DHCP DISCOVER requests from
DHCP clients, permitting the DHCP1 server to respond to and accept the DHCPOFFER first. In
the event that DHCP1 becomes unavailable, DHCP2 can continue distributing addresses until
DHCP1 is available to service clients again.

Figure 2
In our example, DHCP1 manages 70% of the IP addresses in the 192.168.1.0 /24 subnet. This
may be a problem if DHCP1 fails and stays out of service for a prolonged period of time,
because DHCP2 is responsible only for 30% of the IP addresses within the scope and it could run
out of assignable IP addresses quickly.
Wouldnt it be great if DHCP2 could also manage the other 70% of the address space? How
about if both DHCP1 and DHCP2 could manage 100% of the IP address range within the scope
in coordination with each other? This is now possible by configuring DHCP failover on
Windows Server 2012.

DHCP Failover
DHCP failover allows two Windows Server 2012 DHCP servers to share a common pool of IP
addresses in which both servers can have access to 100% of the IP address range in a given scope
and either one of them may assign IP addresses to network clients. As the lease information is
replicated between the servers, there is no risk of duplicate IP address distribution. Because both
DHCP servers are enabled to provide IP addresses and option configuration to the same subnet or
scope, the availability and redundancy of the DHCP service is greatly improved.

There are some caveats worth mentioning before you get too excited about DHCP failover and
try to implement it in your network. Windows Server 2012 permits only two DHCP servers for
failover; this feature applies to IPv4 scopes and subnets and there is no way to configure it on
IPv6 scopes. A single DHCP server can have multiple failover relationships with other DHCP
servers, but each configuration must be assigned a unique name for the partnerships to work.
DHCP failover is time-sensitive so time synchronization is critically important; a time difference
between the partners greater than one minute will result in a critical error and the failover process
will stop.
DHCP failover can be configured in two different modes: load sharing or hot standby.
In Load Sharing mode (default) both DHCP servers provide IP settings to clients concurrently.
By configuring the load distribution ratio you determine your priorities on how the servers
respond to IP configuration requests.
In Hot Standby mode you specify a primary DHCP server that actively dispenses IP settings for
the scope or subnet and a secondary DHCP server that will only distribute IP settings if the
primary server becomes unavailable. You must configure a percentage of the IP address range to
be assigned to the standby server. These addresses are delivered during the maximum client lead
time (MCLT) interval if the primary server is down. The secondary server takes control of the
entire IP range after the MCLT interval expires.
It is important to remind you that whether you are configuring load sharing or hot standby mode,
the configured scope is still shared between the two servers. In either case, if one server fails, the
other DHCP server will be able to manage the whole pool of IP addresses because the lease
information has been replicated all along.
Here are the steps to configure DHCP failover:
1. In the DHCP console, right-click the IPv4 node, and then click Configure
Failover.

Figure 3
2. In the Configure Failover Wizard, click Next. Any scope that you are
configuring for failover must not exist on the partner DHCP server.

Figure 4
3. On the Specify a partner server to use for failover page, in the Partner
Server box, enter the other DHCP server host name or IP Address.

Figure 5
4. On the Create a new failover relationship page, in the Relationship
Name box, enter a unique name and review and/or configure these settings
before clicking Next.

Maximum Client Lead Time (MCLT): This parameter determines the

amount of time a DHCP server should wait when a partner is unavailable,
before assuming control of the address range. It also specifies the amount of
time for which a DHCP lease may be renewed by either failover peer without
previously contacting the other.

Mode: Load balance or standby. Load balance gives the option to assign the
load balance percentage for each server. Hot standby allows you to set the
role of the partner as active or standby and to allocate a percentage of
addresses to the standby server.

State switchover interval: This option specifies the time interval before a
DHCP server is automatically transitioned to a partner down state when
network communication is interrupted and the DHCP partner is no longer
available. By default you must manually switch the status of a DHCP Server
to a partner down state using the DHCP Management console or
PowerShell.

Enable Message Authentication: Use to enable or disable authentication

of failover replication traffic between servers.

Shared Secret: Enter a password to authenticate the failover connection

between servers.

Figure 6
5. Click Finish, and then click Close.

Figure 7
6. After the wizard runs on DHCP1, we can verify that the failover scope has
been created and activated on the DHCP2 server. (See figure below.)

Figure 8
Here we have used the DHCP management console to configure DHCP failover; it is possible to
complete the same configuration using Windows PowerShell.
In this article we focused on the Windows Server 2012 DHCP service performance and
accessibility issues. We reviewed the DHCP database maintenance, using DHCP relay agents,
and the configuration alternatives to improve availability, load balancing and fault tolerance.
This article was originally published by Intense School, a security training company that
specializes in Cisco CCNA training.
Windows Server 2012 IP Address Management

Windows Server 2012 introduces a brand new feature that allows network administrators to
aggregate multiple DNS and DHCP servers and manage them from a centralized location.
Welcome to Internet Protocol Address Management (IPAM).
This article examines how IPAM works in Windows Server 2012 along with its benefits and
limitations; we will walk through the step-by-step IPAM installation and configuration in a
network environment where domain controllers, DNS and DHCP servers are already up and
running.
Advertisement

The Need for IPAM

The more IP-enabled devices in a network, the greater the need for a system to document,
manage, and monitor the IP address space that allows those devices to access network resources.
Tracking IP addresses and DNS names throughout an enterprise network becomes a real

challenge when several DNS and DHCP servers are involved across multiple locations. Thirdparty solutions to this issue have been around for quite a while but Windows Server 2012 is the
first Microsoft server operating system that provides built-in IPAM functionality. However,
IPAM is not enabled by default; it must be installed as a server feature using Server Manager,
Windows PowerShell or the Deployment Image Servicing and Management (DISM) commandline tool.
The IPAM feature on Windows Server 2012 is a centralized tool from which a system
administrator can discover, audit, monitor, and manage IPv4 and IPv6 addresses while
maintaining a wide-ranging view of where IP addresses are used in the network. This is possible
because IPAM supports the management and surveillance of DHCP and DNS servers while
collecting information from domain controllers and network policy servers. That information
feeds the Windows internal database and is critical for IPAM to function.
IPAM benefits
* IPv4 and IPv6 address space planning and provisioning.
* Managing DHCP and DNS records.
* IP address usage statistics and monitoring.
* DNS service zone monitoring.
* Tracking of IP addresses lease, release, and renewal.
* Tracking of logon and logoff events.
* Role-based access control.
* Allow remote management using the Remote Server Administration Tools (RSAT).
* IPAM stores three years of related network information, i.e. user logon and logoff, MAC
addresses, IP address leases, etc. for up to 100,000 users.
* By enabling tracking and forecasting of the IP address space, the IPAM centralized console
helps to optimize the IP address utilization and manage capacity planning for DNS and DHCP.
IPAM modular approach
IPAM installation automatically includes a server and a client component. The server side
executes the data collection from DHCP, DNS, domain controllers and network policy servers. It
also administers the Windows internal database and provides role based access control (RBAC).
All the heavy lifting is done on the server side. The client software supplies the interface to

interact with the IPAM server; it relies on Windows PowerShell and Windows Remote
Management to perform DHCP configuration and DNS monitoring. It is possible to install the
IPAM client separately.
The IPAM server runs four major modules to provide most of its functionality:
* IPAM discovery. This module uses active directory domain services (AD DS) to discover and
enumerate Windows Server 2008 with SP2 or later servers running DNS, DHCP or AD DS. You
can manually add or delete servers and define a custom scope within a domain or forest.
* IP address space management. The IPAM address space management (ASM) is used to view,
monitor, and manage dynamic, static, public, and private IP addresses. It allows tracking IP
addresses and displaying utilization trends, thus making it possible to have more accurate
forecast, planning, accountability, and control of the IP address space. By using IPAM, its easier
to detect overlapping IP address ranges across multiple DHCP servers, identify free IP addresses
within a range, and perform routine tasks like creating DHCP reservations and DNS records.
* Multi-server management and monitoring. IPAM tracks the service status of the DNS and
DHCP servers on the network. By aggregating multiple DHCP servers the multi-server
management (MSM) module enables an administrator to perform editing and configuration of
important properties on multiple DHCP servers and scopes. It also facilitates surveillance and
tracking of DHCP service status and utilization of DHCP scopes. IPAM allows monitoring the
condition of a DNS zone on multiple DNS servers by exposing the collected status of a zone
across all authoritative DNS servers.
* Operational auditing and IP address tracking. Configuration problems can be avoided or
minimized by
using theIPAM auditing tools. Administrators can gather, oversee and display details of
configuration changes on DHCP servers that fall within an IPAM scope. IPAM can extract IP
address lease tracking information from the DHCP servers lease logs as well as logon and logoff
related events from domain controllers and network policy servers.
IPAM Limitations
* The IPAM feature cannot be enabled on a domain controller.
* Windows Server 2012 IPAM supports only Windows internal database. Support for SQL
databases has been added to Windows Server 2012 R2.
* IP address utilization trends are available only for IPv4 (No option for IPv6).
* IP address reclamation support is available only for IPv4 (No option for IPv6).
* IPAM does not support auditing of IPv6 address.

* IPAM cannot be configured to check for IP address consistency on network routers and
switches.
* IPAM does not allow the configuration of a database purge policy. Data must be purged
manually.
* IPAM does not support non-Microsoft network devices, operating systems, or services.
* An IPAM server can only operate within one active directory forest.
* IPAM servers do not share database information or interchange configuration information with
one another.
IPAM implementation guidelines and requirements
* The IPAM feature must be enabled on a Windows Server 2012 computer that is a member of a
domain.
* IPv6 must be enabled in order to manage IPv6 addresses.
* A domain account with proper privileges is needed to administer an IPAM Server.
* The enterprise and domain administrator accounts have unrestricted access to IPAM
administration.
* When IPAM is enabled, several domain local IPAM security groups are created on the IPAM
server.
* The IPAM security groups are configured with the required permissions to access or manage
different IPAM functionalities. These groups may be used to delegate tasks and responsibilities
to other users.
* Microsoft recommends IPAM to be a single purpose server. It discourages the installation of
other roles such as DNS or DHCP on the IPAM server.
To demonstrate the installation and configuration, I have three main Windows 2012 Servers: DCDNS1 is a domain controller with the DNS server role installed. DHCP1 is the DHCP server in
the network, and a server conveniently named IPAM-Server that will be running the IPAM
Server and client components. DHCP1 and the IPAM-Server are members of
the lanztek.com domain. We will review four main phases of the IPAM installation and
configuration process.

Phase 1 Installing the IPAM feature

On IPAM-Server, in the Server Manager Dashboard, click Add roles and

features.

Figure 1

In the Add Roles and Features Wizard, click Next.

Figure 2

On the Select installation type page, click Next.

Figure 3

On the Select destination server page, click Next.

Figure 4

On the Select server roles page, click Next.

Figure 5

On the Select features page, select the IP Address Management (IPAM)

Server check box.

Figure 6

In the Add features that are required for IP Address Management (IPAM)
Server popup, click Add Features, and then click Next.

Figure 7

On the Confirm installation selections page, click Install.

Figure 8

That completes the IPAM feature installation.

Figure 9

Phase 2 Configure IPAMrelated GPOs

Now that we have the IPAM feature installed on this server, our next step is to configure the
IPAM related Group Policy Objects (GPO) that are necessary to work with the managed servers
on the network.

On the IPAM-Server, in the Server Manager Navigation pane, click IPAM.

Figure 10

In the IPAM Overview pane, click Connect to IPAM server, Connected to

IPAM-SERVER.LANZTEK.COM, and then click OK.

Figure 11

Click Provision the IPAM server, and then click Next

Figure 12

On the Select provisioning method page, ensure that the Group Policy
Based method is selected, in the GPO name prefix box, type IPAM, and
then click Next.

Figure 13

On the Confirm the Settings page, click Apply and wait until provisioning
is completed.

Figure 14

Phase 3 Configure IP management server discovery

Once provisioning is successfully completed, we move to configure and activate server
discovery to allow IPAM to find the DNS and DHCP servers that we want to centrally manage.

On the IPAM Overview pane, click Configure server discovery.

Figure 15

In the Configure Server Discovery settings dialog box, click Add, and then
click OK.

Figure 16

In the IPAM Overview pane, click Start server discovery.

Figure 17

The discovery may take several minutes, the yellow bar indicates when it is
done.

Figure 18

Phase 4 Configure managed servers

Now we are ready to work with DNS and DHCP servers discovered by IPAM on the execution
of phase 3.

In the IPAM Overview pane, click Select or add servers to manage and
verify IPAM access.

Figure 19

Notice that the IPAM Access Status is blocked. At this point the IPAM server
has not yet been granted permission to manage these servers via Group
Policy.

Figure 20

On the taskbar, right-click the Windows PowerShell icon, rightclick Windows PowerShell, and then click Run as Administrator.

At the Windows PowerShell prompt, run the following command. Type Y, when
you are prompted to confirm the action.

Figure 21

Once the command is complete, we can go back to Server Manager and in

the details pane, right-click DC-DNS1, and then click Edit Server. In
the Add or Edit Server dialog box, set the Manageability
status to Managed, and then click OK.

Figure 22

Switch to DC-DNS1, on the taskbar, click the Windows PowerShell icon, and
at a Windows PowerShell prompt, type Gpupdate /force, and then press
Enter.

Switch back to the IPAM-Server. In Server Manager, in the IPAM console, rightclick DC-DNS1, and then click Refresh Server Access Status.

Figure 23

Repeat steps 5 and 6 to unblock the DHCP1 server.

In the IPAM Overview pane, click Retrieve data from managed servers.
This task may take several minutes to finish.

Figure 24
Phases 1 through 4 are necessary to install and configure IPAM to operate in our domain
environment. After IPAM successfully retrieves the data from the managed servers we can use
the IPAM centralized console to manage our DHCP and DNS servers. Below is an example of
how to configure a DHCP scope from IPAM.

Configure and verify a new DHCP scope with IPAM

1. On the IPAM-Server, in the IPAM navigation pane, under MONITOR AND
MANAGE, click DNS and DHCP Servers.

Figure 25
2. In the details pane, right-click the instance of DHCP1.lanztek.com that
contains the DHCP server role, and then click Create DHCP Scope.

Figure 26

3. In the Create DHCP Scope dialog box, complete the Scope configuration as
shown below.

Figure 27
4. On the IPAM-Server, in the IPAM navigation pane, under MONITOR AND
MANAGE, click DNS and DHCP Servers. Right-click DHCP1 and
select Launch MMC.

Figure 28
5. Notice that the scope has been created.

Figure 29
Many other DHCP and DNS related tasks can be executed from the IPAM server. IPAM relies on
the task scheduler to periodically gather information from DNS, DHCP, domain controllers and
network policy servers. An administrator can also retrieve data at any time from these servers by
exercising the Retrieve All Server Data option. It is important to note that IPAM is an agentless
technology that does not install any special software on other computers. Instead, it uses
Windows Remote Management to communicate, manage, monitor and collect data from the
managed servers.

In this article we explored the IPAM implementation on Windows Server 2012, including its
main components, requirements, benefits and limitations. The installation and configuration was
covered through four key phases that comprised of installing IPAM, configuring IPAM-related
GPOs, configuring IP management server discovery and configuring managed server. IPAM is a
very valuable feature in large networks where it can be used to reduce the complexity of
managing multiple DNS and DHCP servers across the enterprise.
Choosing a DHCP server availability solution

A tip to help you choose the right DHCP server availability solution for your environment.
Traditionally, DHCP server availability has been implemented on Windows Serverbased
networks using one or more of the following methods:

Split scopesThis approach involves splitting the IP address pool of a scope between
two DHCP servers, typically by assigning the primary server 80 percent of the addresses
in the scope and the secondary server the remaining 20 percent of the addresses. That
way, if the primary server goes offline for any reason, DHCP clients on the subnet can
still respond to lease renewal requests from the secondary server.

Server clusterThis approach involves using the Failover Clustering feature of

Windows Server 2008 or Windows Server 2008 R2 to cluster DHCP servers so that if the
primary DHCP server in a cluster fails, the secondary server can take up the slack and
continue leasing addresses to clients.

Standby serverThis approach uses a hot standby DHCP server with scopes and
options configured identically to your production DHCP server.

Each of the preceding approaches has the following disadvantages, which make them of limited
usefulness in ensuring DHCP server availability:

The split-scope approach provides limited IP availability during outages. As a result,

some clients might not receive addresses during a long-term DHCP server outage. In
addition, if your DHCP server scope is currently running at high utilizationwhich is
common for Internet Protocol version 4 (IPv4) networkssplitting the scope might not
be feasible.

The DHCP server-cluster approach has only one DHCP database located on the cluster
shared storage. That means there is a single point of failure for DHCP services on your
network. In addition, implementing Failover Clustering requires relatively complex setup
processes and maintenance tasks.

The hot-standby approach requires both careful configuration of the standby DHCP
server and manual intervention on the part of the administrator to ensure the failover
transition when your production DHCP server fails or goes offline. There is also

additional complexity in this approach when DHCP is configured to automatically update

DNS records, as is recommended in an Active Directory environment.
DHCP failover is a new approach to ensuring DHCP availability that is included in Windows
Server 2012. With this approach, two DHCP servers can be configured to provide leases from the
same pool of addresses. The two servers then replicate lease information between them, which
enables one server to assume responsibility for providing leases to all clients on the subnet when
the other server is unavailable. The result of implementing this approach is to ensure DHCP
service availability at all times, which is a key requirement for enterprise networks.
Implementing DHCP Server Failover

My latest book is now available for pre-order on Amazon. The book is called Installing and
Configuring Windows Server 2012 Training Guide and it's part of a new series of titles from
Microsoft Press that focus on learning the skills that IT pros need for performing their job using
Microsoft products. Here's what the cover looks like:
Much of my new book is focused on using PowerShell to manage Windows Server 2012, so this
article and the next one includes some short excerpts from my book to both whet your appetite
(to entice you into buying my book) and to show you some of the things you can do as an admin
using PowerShell. Note that the target audience of the book is Windows intermediate-level
admins who have several years of work experience but who might still be beginners when it
comes to using PowerShell, so I'm hoping that readers will find my book useful to learn how
they can start using PowerShell to simplify and automate the administration of Windows servers
in their environment.
This first excerpt is from Chapter 6 Network Administration and describes the new DHCP Server
Failover capability included in the DHCP Server role in Windows Server 2012. I've also included
one of the chapter's exercises, which shows how to implement DHCP Server Failover using
PowerShell. Note that these book excerpts haven't finished going through the editorial review
process yet, so they may change a bit in the published version.

Understanding DHCP failover

DHCP failover is a new approach to ensuring DHCP availability that is included in Windows
Server 2012. With this approach, two DHCP servers can be configured to provide leases from the
same pool of addresses. The two servers then replicate lease information between them, which
enables one server to assume responsibility for providing leases to all clients on the subnet when
the other server is unavailable. The result of implementing this approach is to ensure DHCP
service availability at all times, which is a key requirement for enterprise networks.
The current implementation of DHCP failover in Windows Server 2012 has the following
limitations:

It only supports using a maximum of two DHCP servers.

The failover relationship is limited to IPv4 scopes and subnets.

DHCP server failover can be implemented in two different configurations:

Load sharing mode Leases are issued from both servers equally, which
ensures availability and provides load balancing for your DHCP services (this
is the default DHCP server failover configuration).

Hot standby mode Leases are issued from the primary server until it fails,
whereupon the lease data is automatically replicated to the secondary server
which assumes the load.

Load sharing mode

A typical scenario for implementing the load sharing approach is when you want to have two
DHCP servers at the same physical site. If the site has only a single subnet, then all you need to
do is enable DHCP failover in its default configuration. If there are multiple subnets, deploy both
DHCP servers in the same subnet, configure your routers as DHCP relay agents (or deploy
additional DHCP relay agents in subnets), and enable DHCP server failover in its default
configuration.
Hot standby mode
When implementing the hot standby mode approach, you can configure a DHCP server so that it
acts as the primary server for one subnet and secondary server for other subnets. One scenario
where this approach might be implemented is for organizations that have a central hub site
(typically the data center at the head office) connected via WAN links to multiple remote branch
office sites. Figure 6-1 shows an example of an organization that has DHCP servers deployed at
each branch office and at the head office. Branch office servers are configured to lease addresses
to clients at their branch offices, while the central server leases addresses to clients at the head
office. Each branch office server has a failover relationship with the central server, with the
branch office assuming the role as primary and the central server as secondary. That way, if a
DHCP server fails at a branch office, the central server can take up the slack for the remote site.
For example, the DHCP server at Branch Office A is the primary server for the scope
10.10.0.0/16 while the DHCP server at the Head Office is the secondary for that scope.
Troubleshooting a DHCP Server

A look at the various reasons why a DHCP server might fail to lease IP addresses and the
solutions to those problems.
If you use DHCP servers to automatically configure the TCP/IP settings for workstations in your
organization, a DHCP failure can lead to a major disruption in service. After all, if a workstation
is not able to acquire an IP address, then it will have no way of accessing any of the resources on
your private network or on the Internet. In this article, I will discuss some techniques that you
can use to troubleshoot DHCP server failures.

Inappropriate Address Assignment

One very common DHCP related issue is the assignment of an unexpected IP address. For
example, suppose that your DHCP server was configured with an IP address scope of
192.168.0.1 to 192.1680.50. You would expect network hosts to be assigned IP addresses in this
range. Now, suppose that a workstation on your network appeared to be having problems
communicating with network servers. You issue an IPCONFIG /ALL command to view the
workstations IP address configuration. Instead of the expected address range, the workstation
has been assigned an address beginning with 169.254.
So what happened? If a host on your network is unexpectedly assigned an address beginning
with 169.254, you can rest assured that the address was not assigned by your DHCP server. What
actually has happened, is that the workstation has failed to contact a DHCP server. When this
occurs, the workstation will assign itself an IP address using a Windows feature known as
Automatic Private IP Addressing (APIPA).
Microsoft built Automatic Private IP Addressing into Windows as a way of helping those who
have very small networks. For example, if you were to create a small Windows network, you
would not have to manually configure IP addresses even if there were no DHCP server on the
network. APIPA would automatically assign a unique class B IP address to each machine on the
network. This is great for small home networks but completely inappropriate for larger networks.
If a workstation resorts to using an APIPA assigned address, it is because its requests for an IP
address have gone unanswered. There are several possible causes for this problem. Assuming
that the other computers on the network are able to acquire an IP address from your DHCP
server, you can rule out the DHCP server as the cause of the problem.
More than likely, the issue is related to the networking hardware installed in the workstation that
is having the problem. For example, the Network Interface Card might be assigned an incorrect
driver. Another possible cause of the problem is that the patch cable is not plugged into the
Network Interface Card, or is not connected to a switch on the other end.
Of course, just because only one computer on the network is having trouble obtaining an IP
address doesnt completely rule out the server as the cause of the problem. If other workstations
are successfully obtaining IP addresses, then you can be sure that the server is working properly.
However, it could be that the server has run out of IP addresses that it can assign to clients. You
can easily tell if this is the problem by comparing the size of the DHCP address scope to the
number of devices on your network that request IP addresses from the DHCP server.
Advertisement

Common DHCP Server Problems

If multiple workstations are experiencing problems with leasing IP addresses, then the problem is
most likely related to the DHCP server itself. If you suspect that the DHCP server is the cause of

the problem, then you might start off by doing some ping tests to verify that the DHCP server is
able to communicate across the network.
If the DHCP server is able to communicate with other computers on the network, then I
recommend verifying that the DHCP server has an IP address that is compatible with the scope
that the server is configured to assign addresses from. For example, if the DHCP servers scope
consists of addresses from 192.168.0.1 to 192.168.0.50, then the server will not actually be able
to assign those addresses unless the server itself has been assigned a static address in the same
subnet range, such as 192.168.0.0 or 192.168.0.51.
If this still doesnt solve the problem, then I recommend checking the basics. For example, you
should make sure that the DHCP server is still authorized by the Active Directory to lease IP
addresses. You should also check to verify that the scope is active, and that the necessary
services are running on the DHCP server.

IP Address Conflicts
Another problem that I have seen on occasions involves IP address conflicts among dynamically
configured addresses. When you create a DHCP scope, it is the DHCP servers responsibility to
make sure that addresses within the scope are only leased to one client at a time. If thats the
case, then how is it possible to have an IP address conflict for dynamically assigned addresses?
There are two situations that Ive run into that can cause this problem. The first time that I ever
ran into this problem, I was able to determine which PCs had been assigned at the duplicate
addresses. When I checked the TCP/IP configuration on those machines, I found that one of the
machines IP addresses had been manually configured. Its kind of a long story, but that
machines user was running an unauthorized application that required a static IP address. The
user got tired of having to reconfigure the application every time they used it, so they took the
address that had been dynamically assigned to them, and entered it as a static address.
The likelihood of this happening today is fairly slim. When a particular situation occurred,
Windows 98 was the current operating system. Windows 98 lacks many of the security features
that we take for granted today. A properly secured workstation running Windows XP or Windows
Vista should be resistant to end user reconfigurations. Even so, I wanted to at least mention this
issue because it gives you something to look for if you have trouble solving the problem.
A much more common cause of this problem is that multiple DHCP servers are in use, and those
DHCP servers have overlapping scopes. If you only have a single DHCP server on your network,
do not make the mistake of immediately dismissing this idea as a possible cause of your
problem. In all likelihood, there is probably a rogue DHCP server that is conflicting with your
primary DHCP server.
Windows 2000 Server and Windows Server 2003 are both designed in such a way to prevent
rogue DHCP servers from causing problems. A DHCP server can only issue IP addresses after it

has been authorized by the Active Directory. The problem is that this only applies to Windowsbased DHCP servers. DHCP servers running other operating systems are free to lease IP
addresses to clients without having to be authorized by the Active Directory.
So has a user really gone through the trouble of installing a rogue, Linux based DHCP server?
Probably not. A much more likely explanation is that a wireless access point, or a router intended
for cable or DSL Internet connections is causing your problem. Such devices almost always have
DHCP servers built in. These devices typically use a scope range of 192.168.0.x or 192.168.1.x.
If this happens to be the same IP address scope that your primary DHCP server uses, then you
may run into a situation in which both DHCP servers are issuing addresses from the same
address pool.

Conclusion
In this article, Ive explained that there are a number of potential causes for DHCP failures. In
most cases, these failures are related to simple communications problems between the DHCP
server and the workstations that are trying to lease addresses.
Configure DHCP options using Netsh

You can use the Netsh command to configure DHCP options from the command line.
You can use the Netsh command to configure DHCP options from the command line. DHCP
options are additional information a DHCP server provides to clients that lease addresses. This
additional info typically includes the default gateway address, DNS server addresses, DNS
domain names, and WINS server addresses. DHCP options can be configured at the server, scope
or reservation level.
For example, to configure a scope option that assigns 10.10.20.1 as the default gateway address
to clients that lease addresses from the 10.10.20.0 scope, use the following command:
netsh dhcp server scope 10.10.20.0. set optionvalue 003 IPADDRESS 10.10.20.1
To verify the result, type this command:
netsh dhcp server scope 10.10.20.0 show optionvalue
If you want to assign the option at the server level instead of the scope level, use this instead of
the first command above:
netsh dhcp server 10.10.20.0 set optionvalue 003 IPADDRESS 10.10.20.1
Creating a DHCP Scope using a Batch File

By creating a batch file of Netsh commands you can automate the creation of DHCP scopes. For
example, the following batch file creates a scope 172.16.11.0 with address range .220 through .
250, exclusion range .225 through .230, excluded single address .244, reserved address .133, and
default gateway .1 on DHCP server 172.16.11.30:
REM -- Batch file to create a scope on a DHCP server
REM
REM -- Create scope 172.16.11.0 on DHCP server 172.16.11.30
netsh dhcp server 172.16.11.30 add scope 172.16.11.0
255.255.255.0
"Main Office"
REM
REM -- Assign address range 172.16.11.220 to 172.16.11.250
to new
scope
netsh dhcp server 172.16.11.30 scope 172.16.11.0 add
iprange
172.16.11.220 172.16.11.250
REM
REM -- Exclude address range 172.16.11.225 through 172.16.11 230 from
new scope
netsh dhcp server 172.16.11.30 scope 172.16.11.0 add excluderange
172.16.11.225 172.16.11.230
REM
REM -- Exclude single address 172.16.11.244 from new scope
netsh dhcp server 172.16.11.30 scope 172.16.11.0 add excluderange
172.16.11.244 172.16.11.244
REM
REM -- Reserve address 172.16.11.133 for mail server
netsh dhcp server 172.16.11.30 scope 172.16.11.0 add reservedip
172.16.11.133 0003FF54888C
REM
REM -- Configure scope option 003 to assign default gateway of
172.16.11.1 to clients
netsh dhcp server 172.16.11.30 scope 172.16.11.0 set optionvalue 003
IPADDRESS 172.16.11.1

Creating and managing DHCP scopes using Netsh

You can use the Netsh command to create and manage DHCP scopes from the command line. A
scope is a pool of IP addresses that a DHCP server can lease to clients that need them. You can
use this approach to write batch scripts of Netsh commands you can run on a DHCP server to
quickly configure it.
For example, to create a scope named "Second Floor" that has network ID 10.10.20.0 and subnet
mask 255.255.0.0, use the following command:
netsh dhcp server add scope 10.10.20.0 255.255.0.0 "Second Floor"
Then to add the address range 10.10.20.100 to 10.10.20.150 to this scope, use this command:
netsh dhcp server scope 10.10.20.0 add iprange 10.10.20.100 10.10.20.150
And if you want to exclude the address 10.10.20.125 from your scope, do this:

netsh dhcp server scope 10.10.20.0 add excluderange 10.10.20.125 10.10.20.125

You can even create a reservation for a specific address like 10.10.20.144 like this:
netsh dhcp server scope 10.10.20.0 add reservedip 10.10.20.144 0004FE42A3BE
Here 0004FE42A3BE is the MAC address of the system you want to reserve the address for.
Working with the Desired State Configuration Feature

Introduction
One of the big side effects to server virtualization has been rampant virtual machine sprawl.
Because it has become so ridiculously easy to create virtual machines, organizations find
themselves having to manage more virtual machines than they probably ever expected to. The
end result of this has been that even smaller organizations find themselves facing management
scalability problems that once only existed in large environments.
Needless to say, this trend has resulted in the development of numerous products that are
designed to automate virtual machine management and deployment. However, Microsoft has
included some large-scale management capabilities natively in the Windows operating system.
Some of these capabilities can be found in the Desired State Configuration feature. The Desired
State Configuration feature is an incredibly versatile feature that allows you to make sure that
virtual machines are deployed and maintained in a consistent manner.
If you havent heard of the Desired State Configuration feature before, it may be because its
something that not a lot of organizations use. Dont get me wrong. Its not that the tool is bad, or
anything like that. Its just that the Desired State Configuration feature is based around
PowerShell. Theres a little bit of work involved in getting it running, and the documentation for
the tool can be a little bit intimidating. That being the case, many organizations choose to adopt
third-party tools rather than delving into PowerShell.
If you can get past the inherent difficulties in working with PowerShell, the Desired State
Configuration feature is really a great tool. Quite frankly, Im really surprised that nobody has
developed a graphical front end for it yet.
My goal in writing this article series, is to take some of the mystery out of the Desired State
Configuration tool. While its true that there is no getting around working in PowerShell,
working with the tool does not have to be as difficult as it is often made out to be. My approach
to this article series is going to be to break the information down as simply as I possibly can, and
walk you through the various steps required to get the Desired State Configuration tool up and
running.
Advertisement

What Can the Desired State Configuration Feature Do?

Before you invest a lot of effort into learning how to use the Desired State Configuration Feature,
you are probably wondering what it can really do to help your organization. As previously
mentioned, the Desired State Configuration Feature is all about providing a level of automated
management. The idea is that if you have multiple virtual machines that need to be configured,
you can use a PowerShell script to ensure that those virtual machines are configured in a
consistent manner. Assuming that the script is properly written, the use of PowerShell takes the
potential for human error count of the equation. Furthermore, even though getting the Desired
State Configuration feature set up requires a bit of work up front, it often saves a lot of
administrative effort in the long run.
So with that said, I think I have generalized enough. Lets talk about some specific things that
you can do with the Desired State Configuration feature.
One of the easiest things that you can do with the Desired State Configuration Feature is to
enable or disable individual Windows Server roles or features. As a matter of fact, thats exactly
what Im going to be demonstrating with the first walk through.
Now admittedly, using a PowerShell script to enable or disable roles or features probably sounds
like more effort than its worth. After all, you can manually configure roles and features with
only a few mouse clicks. So why use a PowerShell script?
Keep in mind that the Desired State Configuration tool was designed to deal with the challenges
of managing large-scale environments. With that in mind, yes, using PowerShell to configure an
individual server probably is overkill. But what if you needed to configure 100 Web servers?
Given that Web servers are directly exposed to Internet traffic (behind a firewall of course), they
need to be secure. As such, administrators must be very careful about which roles and features
they enable on a Web server. A PowerShell script could be used to make sure that all of the
individual Web servers that make up a web application are configured with exactly the right set
of roles and features, and that all of the servers are configured in an identical manner.
Just as you can manage roles and features using the Desired State Configuration feature, you can
also ensures consistency of other elements as well. For example, you can use the tool to
configure things like registry settings, files, and folders.
Okay, as you can see, the Desired State Configuration Tool is really useful for server
configuration. However, there is one big question that must be addressed. Why would you use
the Desired State Configuration Tool as opposed to some other native tool? After all, it is
arguably easier to set up a virtual machine with a desired configuration, run SYSPREP, and then
use the SYSPREP image to deploy clones of the virtual machine. So why use the Desired State
Configuration Feature?

If your only goal is to automate virtual machine deployment, you probably are better off using
some other tool. There are a number of graphical tools that can clone virtual machines without
requiring the administrator to delve into PowerShell. However, the Desired State Configuration
Feature is useful for more than just virtual machine provisioning.
As a matter of fact, the Desired State Configuration Tool isnt even really what I would call a
virtual machine deployment tool. You would actually have to use some other tool to deploy the
virtual machines. The Desired State Configuration Tool simply applies a desired configuration to
the virtual machines after they have been deployed.
But I still havent answered the question about why you would use this tool, as opposed to
something else. Most of the deployment and configuration tools that are available on the market
tend to focus solely on virtual machine image management and deployment. One of the things
that makes the Desired State Configuration Tool different from most of the third-party tools that I
have worked with (although there are exceptions) is that the Desired State Configuration Tool
can do configuration monitoring and remediation.
In other words, the Desired State Configuration Tool makes it possible to periodically analyze
virtual machines to make sure that they are still running an approved configuration. If
configuration drift is discovered, then you can use the Desired State Configuration tool to fix the
problem by forcing the virtual machine back into a compliant state.

Conclusion
I have barely even begun to scratch the surface in talking about all of the great things that the
Desired State Configuration tool can do. Even so, I would rather show you how the tool works
rather than continuing to talk about what it does. That being the case, I want to spend the next
article in this series talking about how you can start getting the Desired State Configuration tool
ready to use.

Introduction
In my first article in this series, I explained that the Desired State Configuration feature is a tool
that you can use to verify that a server adheres to the required configuration, and to take
corrective action if configuration drift is discovered. In this article, I want to continue the
discussion by showing you some techniques for using the Desired State Configuration Feature.
Now that you understand some of the things that can be done by using the Desired State
Configuration Tool, I want to talk about how the tool works. As previously alluded to, the
Desired State Configuration Tool is based on PowerShell. In fact, when you build a
configuration, that configuration works in almost an identical manner to a PowerShell function.
But Im getting a little bit ahead of myself.
Advertisement

Stages of Operation
The first thing that you need to understand about the way that the Desired State Configuration
tool works is that there are three different stages of operation. The first of these stages is known
as the Authoring Phase. This is the part of the process where you specify the desired
configuration through PowerShell. The syntax for authoring a configuration is fairly easy, and I
will show you some examples of the configuration process later on as we go along. For right
now, the most important thing that you need to know is that the configuration that you define is
used to build a Managed Object Format (MOF) file.
The second step in the process is something that Microsoft commonly refers to as the staging
phase. The staging phase is the part of the process in which your MOF file (and any custom
providers that you might have) is made ready for use. The staging phase can work in a few
different ways, but most commonly adheres to a pull model. Im not going to get into the
anatomy of the staging process too much right now because I think that it will probably make a
lot more sense if you can see the process in action. As such, I will revisit the topic later on.
The last stage in the process doesnt seem to have a formal name. A lot of the Microsoft
documentation refers to this step as the make it so stage. This is the step in which the desired
configuration is applied.

An Introduction to Providers
In the previous section, I briefly mentioned the concept of custom providers, but I didnt really
talk about what custom providers are. Custom providers are a mechanism by which you can
extend the Desired State Configuration tools functionality. The creation of custom providers are
beyond the scope of this article series, but you do need to understand the concept of providers.
A providers job is to manage a specific aspect of the configuration process on the target system.
For example, in the first article in this series, I mentioned that it was possible to use the Desired
State Configuration Tool to ensure that a server role is installed on the target system. The process
of adding or removing roles and features is handled by a provider.
There are twelve providers that are built into the Desired State configuration tool. These twelve
providers should be adequate for most purposes, but you can build custom providers should the
need arise. Incidentally, some of the Microsoft documentation refers to providers as Resources
rather than calling them providers.
Here is a list of the providers that are included with the Desired State Configuration Tool:

DSC Archive Resource Allows for the decompression of ZIP files on the
target system

DSC Environment Resource This provider allows you to configure

environment variables on the target system.

DSC File Resource Allows you to manage files and folders on the target
system.

DSC Group Resource Allows you to manage local group membership on the
target system

DSC Log Resource Can be used to log configuration messages

DSC Package Resource This provider allows for application installation on

the target system. It supports the use of Windows Installer packages and
Setup.exe packages.

DSC WindowsProcess Resource Allows for the configuration of Windows

processes on the target system.

DSC Registry Resource This provider allows you to configure registry keys
and their corresponding values on target systems.

DSC Windows Feature Resources This is the provider that is used to install
roles and / or features on a target system.

DSC Service Resource Allows for the management of system services on the
target system.

DSC User Resource Allows for the configuration of local user accounts on
the target system.

As you can see, the built in providers allow for a somewhat granular level of control over a target
system. You can control everything from user accounts and group membership to registry values
and feature installations.
You may recall that in the first article I mentioned that the Desired State Configuration tool isnt
a full blown deployment tool, but rather a tool for checking (and if necessary, correcting) a
systems configuration. That functionality becomes a lot more apparent as you look at the list of
built in providers. For example, a true deployment tool would likely contain resources for joining
a system to the Active Directory. But such functionality is conspicuously missing from the
Desired State Configuration Tool.

PowerShell Functions
One last subject that I need to talk about before I show you how to actually use the Desired State
Configuration Tool is PowerShell functions. The reason for this is that the entire declaration
process through which you define your systems desired state is based on a PowerShell key word
called Configuration. In actuality however, the Configuration keyword is really a function.

So what is a PowerShell function? To put it simply, a function is really nothing more than a name
that is assigned to a block of PowerShell code. This allows you to execute the code simply by
using the functions name. You can use functions to build libraries of reusable code.
When you create a function, you must provide a function name, an optional set of parameters,
and a script block. The script block is the code that will be associated with the function name.
Earlier I said that the Desired State Configuration tool uses a keyword called Configuration, and
that Configuration is actually a function. More correctly, Configuration is the function name. We
dont have to define Configuration as a function name because it has already been defined, but
we can provide parameters and a script block.
To give you a more concrete example of how a function works in PowerShell, lets create a really
simple function. In PowerShell it is possible to display the current date and time by entering the
Get-Date cmdlet. Lets pretend however, that we wanted to make it easier to get the current date
and time by creating a function called Time. The code might look something like this:
Function Time {Get-Time}
The line of code shown above is actually a function. We are declaring a function name by
entering Function Time. The Function keyword tells PowerShell that we are creating a function,
and Time is the name of the function. In this case, {Get-Time} is our script block. This particular
function does not contain any parameters. If we wanted to execute this function, we could simply
enter the word Time and the function would run the script block, which in turn would display the
current date and time.

Conclusion
In this article, I have spent quite a bit of time talking about the inner workings of the Desired
State Configuration feature. In the next article in this series, I will put this information to work
and show you how to create a configuration.

Introduction
In the previous article in this series, I introduced you to several concepts that you need to
understand in order to use the Desired State Configuration Feature. In this article, I want to
continue the discussion by showing you how to build a configuration file.
As previously explained, the Desired State Configuration feature makes use of .MOF files.
However, we cant build a .MOF file from scratch. Instead, we have to create a PowerShell script
and use that script to generate a .MOF file.
I spent quite a bit of time in the previous article discussing PowerShell functions, and I also
mentioned that Microsoft has introduced a PowerShell function called Configuration. The
Configuration function will be the basis of our script. The first thing that we will need to do is to

assign the configuration a name. The name should be something descriptive that hints at the
scripts purpose. For the purposes of this article, I am going to use PoseyConfig as my
configuration name.
The next thing that you will need to create is a node block. A node block is really simple. It
specifies the name of the node (or nodes) for which the configuration will be applied.
To show you how the configuration name and node blocks work, lets pretend that we want to
use the Desired State Configuration feature to make sure that the Hyper-V role is installed on a
server named Lab4. The basic structure of the configuration file would look like this:
Configuration PoseyConfig
{
Node Lab4
{
#This is where the scripts actual code would go.
}
}
The first thing that you have to understand about the block of code shown above is that the
indentions are not important. I used indentions as a way of better illustrating the various
components that make up the script, but you dont actually have to use indentions.
So as you look at the code above, you will see that the first line starts by calling the
Configuration function. We are also applying my chosen configuration name. Like any other
function, the entire configuration is enclosed in braces {}.
The third line of my script is Node Lab4. This is a node block that tells PowerShell that the
configuration should be applied to a computer named Lab4.
The code beneath the node block is enclosed within its own set of braces {}. In this particular
case, the node block only contains a comment. You will notice that the comment line begins with
a pound sign #. In PowerShell, lines of code beginning with a pound sign are treated as
comments and do not execute.
In essence, we have created a configuration script that contains a node block that doesnt do
anything. As I explained in the previous article, the actual configuration tasks are handled by

providers. PowerShell includes twelve native providers and it is also possible to build custom
providers.
Earlier I said that for the sake of demonstration, I would build a configuration script that would
make sure that the Hyper-V role was installed on a server named Lab4. We used a node block to
reference the Lab4 server, but we are going to have to use a provider to check for the existence of
the Hyper-V role. The provider that we will be using is the DSC Windows Feature Resources
provider.
In order to use this provider, you need to know what name PowerShell uses for the role or feature
that you want to reference. The easiest way to get this information is to open PowerShell and
type Get-WindowsFeature. Doing so will cause Windows to display a list of all the roles and
features, as shown in Figure A. As you can see in the Figure, the Hyper-V role is simply called
Hyper-V. PowerShell confirms that this role is currently installed, but our configuration file will
help us to make sure that the role stays installed.

Figure A: You can use the Get-WindowsFeature cmdlet to retrieve a list of all of the Windows
Server roles and features.

If your goal is to use the configuration file to make sure that a particular role (or feature) is
installed, then there are two lines of code that you will need to be familiar with. The first of these
lines is the Ensure line.
The Ensure line tells PowerShell what you want to do with the specified role or feature. You can
either ensure that the role or feature is installed, or you can make sure that it is not installed. If
you want to make sure that the specified role or feature is installed then you would set Ensure to
Present. If you want to make sure that the specified role or feature is not installed then you
would set Ensure to Absent.
The other line of code that you will need to write is the Name line. The Name line simply
provides the name of the role or feature that you are checking. So with that said, lets revisit the
script that I created earlier and add the code to make sure that the Hyper-V role is installed. Here
is what the script would look like:
Configuration PoseyConfig
{
Node Lab4
{
WindowsFeature HyperVExample
{
Ensure = Present
Name = Hyper-V
}
}
}
Much of the script shown above is identical to what I previously showed you, but lets go
through the new section line by line. Once again, our node block is encapsulated in braces {} and
all of the new code exists within the node block braces.
So with that said, the first new block of code is WindowsFeature HyperVExample. There are a
couple of things going on in this line of code. First, we are referencing the DSC Windows
Feature provider, because that is the provider that is able to check for the existence of roles and

features. As you will recall however, I mentioned that it is possible to create custom providers.
When you create a custom provider, what you are really creating is a function. It should therefore
come as no surprise that the natively included providers are also functions. Hence,
WindowsFeature is a provider name, but it is really a function name.
So why is that important? Well, after I specified WindowsFeature, I entered HyperVExample.
HyperVExample is a name that I made up. I am assigning the name to this particular block of
code, just as I assigned the name PoseyConfig to the configuration file as a whole.
As you look through the script, you will notice that I am not using HyperVExample anywhere
else. In this case, I have assigned HyperVExample as a name, but I am not actually doing
anything with it. The reason why I chose to include this name is because most real world
configuration files are far more complex than what I have shown above. Those files may use
multiple providers to perform multiple tasks. Assigning a name to a task gives you the
opportunity to reference the task from elsewhere in the script. For instance, you can check to
make sure that a named task has completed successfully before you launch another task.
Like any other function, the WindowsFeature function uses braces to encapsulate its code. There
are only two commands within the actual function. We are ensuring that the specified role is
present and then we are providing the name of the role.
Advertisement

Conclusion
In this article, I have walked you through the creation of a sample configuration script. In the
next article in this series, I will show you how to use this script to create a MOF file. After I
show you how to use the desired state configuration, my plan is to revisit the script and show you
some additional scripting techniques.
In the previous article in this series, I showed you how to create an example script that was
designed to make sure that the Hyper-V role was installed onto a server named Lab4. In this
article, I want to show you how to use the script that we created previously. After that I want to
come back to the script and show you how to adapt it to make it more useful.
For the sake of reference, here is the script that we built in the previous article:
Configuration PoseyConfig
{
Node Lab4
{
WindowsFeature HyperVExample
{
Ensure = Present
Name = Hyper-V

}
}
The first thing that we need to do is to create a place on the server for our script to reside. For the
purposes of this article, I am going to place the script in a folder named C:\DSC. I created the
folder by opening PowerShell and entering the following commands:
CD\
MD DSC
You can see what this looks like in Figure A.

Figure A: I have created a folder named DSC.

Now, we need to copy the script to the folder that was just created. The easiest way to
accomplish this is to type (or copy and paste) the script into Notepad and then save the Notepad
document into the C:\DSC folder.
There are three important things that you must keep in mind as you create the script. First of all,
if you copy and paste my script then you will need to slightly modify the script. Remember that
Lab4 (which is referenced in the script) is the name of one of my lab servers. You will need to
change this to match the name of your own server. As an alternative to specifying a server name,
you can use localhost to make the script machine independent.
The second important thing to remember is that the script outlined above is really just a function.
A function doesnt do anything by itself. You can only invoke a function by calling it. The easiest
way to accomplish this is to append the function name to the end of the script. Since my function
name is PoseyConfig for instance, I would append PoseyConfig to the end of the script. The
complete script would look like this:

Configuration PoseyConfig
{
Node Lab4
{
WindowsFeature HyperVExample
{
Ensure = Present
Name = Hyper-V
}
}
}
PoseyConfig
The third thing that you need to know about the script is that you will need to save the file using
the .PS1 extension. This identifies the code as a PowerShell script. I will be naming the file
PoseyConfig.PS1.
Once you have created the script, you can go ahead and execute the script. In doing so, you will
have to reference the name of the script. In my case, the script is named PoseyConfig.PS1.
Therefore, I executed the script by using the following commands:
CD\
CD DSC
./PoseyConfig.ps1
You can see what this looks like in Figure B.

Figure B: This is what it looks like when you execute the script.
If you happen to receive an error message when running the script, it could be related to a
restrictive execution policy. You can remove execution policy restrictions by entering the
following command:
Set-ExecutionPolicy Unrestricted
Just keep in mind that execution policies exist for your protection, so it is a good idea to set the
execution policy to Restricted or to RemoteSigned when you are done.
As you can see in the figure above, the script has created a .MOF file. The .MOF file is named
Lab4.MOF and it exists in the C:\DSC\PoseyConfig folder.

So as I explained early on in this series, the script that we created really doesnt do anything by
itself. The scripts job is to generate a .MOF file, not to enforce a desired state. We have to use
the .MOF file to generate a desired state.
A MOF file is really nothing more than a text file that contains configuration information. As a
matter of fact, the .MOF file that we created can be open in Notepad. You can see the contents of
the .MOF file in Figure C.

Figure C: This is what the .MOF file looks like.

Of course this brings up an interesting question. If the .MOF file is really just a text file then why
do we have to generate it using a PowerShell configuration script? Why cant we just build a
.MOF file manually? It is actually possible to manually construct a .MOF file, but it is usually
easier to use a PowerShell function to generate a .MOF file than it is to create a .MOF file from
scratch. I realize that the file shown above isnt very complicated, but remember that we are
using the simplest possible Desired State Configuration. Most real world desired state
configurations are far more complex and therefore generate much longer and more
complicated .MOF files.

So now that we have a .MOF file, what do we do with it? We can invoke the .MOF file by using
a PowerShell cmdlet called Start-DscConfiguration. This cmdlet reads the .MOF file and then
determines which PowerShell cmdlets need to be run in order to achieve the configuration goals.
For example, the script that we have been using is designed to test for the presence of the HyperV role. As such, one of the cmdlets that is run as a part of the testing process is Get-Windows
Feature.
With that said, lets go ahead and put our .MOF file to work. To do so, you will need to invoke
the Start-DscConfiguration command from the C:\DSC folder that we created earlier. The
command that we will be using is:
Start=DscConfiguration Wait Verbose Path .\PoseyConfig
The Wait parameter tells Windows that you want to run the command interactively. The
Verbose switch tells Windows that you want verbose output. That way, you can see what is really
going on with the command.
You will also notice that we are using the Path switch followed by .\PoseyConfig. The reason
for this is that Windows placed my .MOF file into a folder named PoseyConfig that exists as a
child of the DSC folder. The full path is C:\DSC\PoseyConfig.
You can see what happens when we run the command in Figure D. Because we ran the command
in verbose mode, you can see the Get-WindowsFeature cmdlet that was used to verify that
Hyper-V is installed on the server. You can also see that the command took 15.041 seconds to
complete.

Figure D: Here is what happens when we run the command.

I realize that some of you might be wondering what happens if we run the command without
verbose mode. You can see that result in Figure E.

Figure E: Here is the command without the Verbose parameter being used.
As you can see in the figure above, there is no visible output without the Verbose parameter.
Advertisement

Conclusion
In the next article in this series, I want to do a couple of things. First, I am going to show you
what happens when you run the script against a server that does not have the required role
installed. Next, I want to spend some time showing you some other things that you can do with
the script. That way, you will be able to build your script out to really achieve your desired
configurations.

Figure 1: Implementing DHCP failover in hot standby mode in a hub and spoke site scenario.

Exercise 1: Implementing DHCP failover using Windows PowerShell

In this exercise you will ensure DHCP availability for clients in the corp.contoso.com domain by
using Windows PowerShell to install the DHCP Server role on both servers, create a scope on
SERVER1, and configure and verify DHCP failover.

1. Log on to SERVER1, open Server Manager, select the All Servers page and
make sure that both servers are displayed in the Servers tile. If SERVER2 is
not displayed, add it to the server pool.
2. Open a Windows PowerShell prompt and run the following command to install
the DHCP Server role on both servers:
Invoke-Command -ComputerName SERVER1,SERVER2 -ScriptBlock {InstallWindowsFeature `
-Name DHCP -IncludeManagementTools -Restart}
Note that although you specified the -Restart parameter, the servers did not
restart after role installation because a restart was determined as being
unnecessary.
3. Authorize both DHCP servers in Active Directory by executing the following
commands:
Add-DhcpServerInDC -DnsName SERVER1
Add-DhcpServerInDC -DnsName SERVER2
4. Use the Get-DhcpServerInDC cmdlet to verify that the servers have been
authorized in Active Directory.
5. Create a new scope on SERVER1 and activate the scope by running the
following command:
Add-DhcpServerv4Scope -ComputerName SERVER1 -StartRange 10.10.0.50 `
-EndRange 10.10.0.100 -Name "corp clients" -SubnetMask 255.255.0.0 -State
Active
6. Use the Get-DhcpServerv4Scope cmdlet to verify that the new scope has
been created on SERVER1 and is active.
7. Use Get-DhcpServerv4Scope -ComputerName SERVER2 to verify that SERVER
2 currently has no scopes on it.
8. Run the following command to create a DHCP failover relationship in load
balance mode between the two servers with SERVER 2 as the partner server
and failover implemented for the newly created scope:
Add-DhcpServerv4Failover -Name "SERVER1 to SERVER2" -ScopeId 10.10.0.0
`
-PartnerServer SERVER2 -ComputerName SERVER1 -LoadBalancePercent 50 `
-AutoStateTransition $true
9. Use the Get-DhcpServerv4Failover cmdlet to view the properties of the new
failover relationship.
10.Use Get-DhcpServerv4Scope -ComputerName SERVER2 to verify that the
scope has been replicated from SERVER1 to SERVER2.
11.Turn on CLIENT1 and log on to the client computer.

12.Open a command prompt and use the ipconfig command to view the current
IP address of the computer. If the client computer is currently using an
address in the APIPA range (169.254.x.y) then use ipconfig /renew to acquire
an address from a DHCP server on your network. Verify that the address
acquired comes from the scope you created earlier.
13.Verify that the client computer's address is recorded as leased in the DHCP
database of SERVER1 by executing the following command:
Get-DhcpServerv4Lease -ComputerName SERVER1 -ScopeId 10.10.0.0
14.Verify that the client computer's address is recorded as leased in the DHCP
database of SERVER1 by executing the following command:
Get-DhcpServerv4Lease -ComputerName SERVER1 -ScopeId 10.10.0.0