Migrating DHCP from Windows 2003 to Windows 2012 and setting up failover: Part 1

DHCPThe principles of DHCP are simple and Microsoft has not changed its core since before Windows NT days, however its not something you shouldn’t undertake lightly or ill-prepared. Most of your client devices will rely on DHCP to function and failing to migrate seamlessly will only cause disruptions to your business.

This article is to help document how to migrate multiple active DHCP servers to a new DHCP server running on Windows Server 2012. We will finalise the configuration by creating a failover for all scopes to a secondary server. I am writing the to include all the necessary information that I think is required to complete this successfully.UPDATE: Added information regarding to “DNS dynamic update registration credentials”

Every scenario will differ slightly however these steps should be useful for most migrations. In my environment I will be migrating my DHCP servers as part of a larger Domain Controller upgrade/migration project and will only document the DHCP aspect.
Current DHCP configuration:

  • DC01 – DHCP server with scopes for all systems at headquaters campus
  • DC02 – DHCP server with scopes for all systems at warehouse campus

Proposed Configuration:

  • DC03 – DHCP server with all scopes
  • DC01 (rebuilt) – DHCP failover server

History

I wont cover what already most people reading this blog know but I will advise you all to have a glance here (http://en.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol) and spend a moment refreshing your memory.

Key points are:

  • DHCP stands for Dynamic Host Configuration Protocol
  • Based off standards in RFC 1531 (http://tools.ietf.org/html/rfc1531)
  • Common settings sent to clients are IP Address, default route, DNS servers and DNS Domain
  • UDP port 67 for sending data to the server
  • UDP port 68 for data to the client
  • DHCP operations fall into four basic phases: IP Discovery, IP Lease Offer, IP Request, and IP Lease Acknowledgment (often abbreviated as DORA)

Preparing your network

There are a number on tasks to do before you start migrating DHCP. Below are the prerequisite steps I had to perform.

  • Configure IP Helper addressWe have multiple subnets in our environment and our old (and new) DHCP servers will live in one subnet. For clients in other subnets to be able to communicate to the DHCP server (without itself having its own IP address) we configure these IP Helper addresses to direct the requests to specific servers. Note you can have multiple IP Helpers to direct your request to. For my migration most of our subnets have the following IP Helpers:
    • IP Helper 1 – DC01 DHCP
    • IP Helper 2 – DC02 DHCP
    • IP Helper 3 – DC03 DHCP
    • IP Helper 4 – SCCM Server for Client PXE booting

    When a client sends a broadcast, the message will be sent to all DHCP servers and the SCCM server. If the broadcast is for DHCP, all 3 DHCP servers will go to action it, however part of the broadcast includes the subnet that the client belongs to. In turn you will only get a response from the DHCP server hosting that scope. (May differ if you have split scope DHCP configured)

    The IP helper will forward UDP broadcast packets of the following types:

    • Trivial File Transfer Protocol (TFTP)
    • Domain Name Service (DNS)
    • Network Time Service
    • NetBIOS Name Server
    • NetBIOS Datagram Server
    • BootPC and DHCP
    • TACACS requests
  • Clean up existing DHCP configuration
    Looking into our existing DHCP I noticed there were a number of scope options and settings that, over time, have been miss-configured and could do with correcting. In my situation I decided to do this before migration as it means I’m not migrating things I don’t need to. My examples of things needing change:

    • STANDARD/OPTION 046 WINS/NBT Node Type was still configured, even though OPTION 044 was removed. This can easily be removed as its not being used.
    • Microsoft/OPTION 001 Microsoft Disable Netbios Option was only configured on one scope for testing and never propagated to all scopes
    • Disabled scope that has not been used for years – removed completely
    • Obsolete/old Reservations that are no longer required
    • Address Pool exclusions that have been configured to cater for systems no longer in place
  • Reduce lease time
    Reduce lease time on your DHCP scopes that will be migrated. This reduces risks in the event that there is a problem, because your clients will automatically renew after that point.

Installing DHCP on Windows Server 2012

This process alone has been documented quite heavily online so I will document the PS cmdlets only. Please refer to resources down the bottom for more detailed process with GUI installation.

  1. Build Windows Server 2012 with static IP address (eg. 192.168.1.2)
  2. Install feature: Add-WindowsFeature  -IncludeManagementTools dhcp
    Note: IncludeManagementTools switch is required if you plan on managing DHCP from the console of the machine
  3. Create DHCP security groups: netsh dhcp add securitygroups
  4. Restart the service for settings to take effect: Restart-service dhcpserver
  5. Authorizing the DHCP server in Active Directory: Add-DhcpServerInDC  <hostname of the DHCP server>  <IP address of the DHCP server>. Eg. Add-DhcpServerInDC DC02 192.168.1.2
    Note: This is only needed for a domain-joined setup.

The above steps have all the details removed as the steps are fairly self explanatory. Personally I use Server Manager to install this feature as its so simple to follow the wizard.

Initial configuration

DHCP configure optionsNow that you have your new DHCP service running and the server is healthy, you can go into DHCP Management Console and start preparing to migrate your DHCP scopes. The first thing I do is manually add the server predefined scope options that are required for all scopes.  To do this, expand your server name, expand IPv4, right click on Server Options and select ‘Configure Options…’.

In my case the two default scopes are:

  • 006 DNS Servers  – Two IP’s for our two Active Directory servers that host DNS
  • 015 DNS Domain Name – The Active Directory name that DNS hosts

DHCP Set predefined optionsThere is also a requirement for us to add an additional scope that is not a default. To do this we need to set predefined options. To do this expand your server name, right click on IPv4 and select ‘Set Predefined Options…’.

Once there, Click on ‘Add…’ and fill in the options. In my situation I needed to add OPTION 252 WPAD however the same steps can be used to add any Predefined Option.

Details I used:

  • Name: WPAD
  • Data Type: String
  • Code: 252
  • Description: WPAD discovery point for proxy server

Click Ok to save the predefined option. Follow the same steps as above to add the new option to your Server Options.

My configuration looks like the following screenshot. At this point the server is ready for me to migrate DHCP configuration from Windows 2000, 2003, 2008 and 2012 DHCP servers.

DHCP - set predefined optionsDHCP - final server configuration

I also configure the DNS dynamic update registration credentials.

A DHCP server can enable dynamic updates in the DNS namespace for any one of its clients that support these updates. Scope clients can use the DNS dynamic update protocol to update their host name-to-address mapping information whenever changes occur to their DHCP-assigned address. (This mapping information is stored in zones on the DNS server.) A DHCP server can perform updates on behalf of its DHCP clients to any DNS server, but it must first supply proper credentials.These credentials are used by DHCP to dynamically update the DNS server and should be configured if the DHCP and DNS server resides on the same operating system.

To do this the user must be part of either ‘Administrators’ or ‘DHCP Administrators’ group. In my environment i created a domain user account, and added membership to ‘DHCP Administrators’ group. I believe in 2003/2008 you could add the user to ‘DnsUpdateProxy’ group, however the Windows 2012 suggest using the ‘DHCP Administrators’ group.

  1. Click Start, point to Administrative Tools and then click DHCP.
  2. In the console tree, right-clickIPv4, and then click Properties
  3. Click Advanced, click Credentials, type the credentials that the DHCP server supplies when registering names using DNS dynamic updates, and then click OK.

Migrating initial scope for testing

I may be overly cautious however when it comes to potentially causing havoc to the business I like to test things work before affecting everyone. The initial scope I am migrating will be our VDI clients VLAN where we only have 38 currently registered IP addresses.

Note: The following steps need to be made in a short span of time so read through them all before executing, and prepare yourself for it.

  1. Logon to the DHCP Server with the test scope that you want to migrate
  2. Load the DHCP MMC console, navigate to the scope, right click on it and select Deactivate. This will prevent new leases from being created.
  1. Open a command prompt. If you are running Windows Server 2008/2012 be sure to load it with elevated privileges (Right click -> Run As Administrator)
  2. Type cd\ and press enter to navigate to the root of the drive (default will be C:\ drive)
  3. Type NETSH DHCP SERVER export dhcp-vlan7.db 192.168.7.0 and press enter. This will export all details about that VLAN to a binary file in the root of the drive.
  4. Logon to the DHCP Server you want to migrate to.
  5. Open a command prompt. If you are running Windows Server 2008/2012 be sure to load it with elevated privileges (Right click -> Run As Administrator)
  6. Type PUSHD \\DC1\C$ and press enter. (Where DC1 is the server name that you logged onto in step 1, and C$ is the root drive that you navigated to in step 3). PUSHD/POPD is a great little trick that allows you to temporarily map a network share and assign it a drive letter.
  7. Type NETSH DHCP SERVER import dhcp-vlan7.db 192.168.7.0 and press enter. This will import all details about the VLAN into the DHCP database.
  8. Load the DHCP MMC console on the new server. You may need to refresh the console for the new scope to become visible. Once visible, navigate to the scope, right click on it and select Activate. This will allow new leases to be created on the new server.

You have now successfully migrated the data for that VLAN and your clients should be able to pick up from where they left off. I do suggest you monitor that machines are renewing their existing addesses (extending their leases) and no clients are having problems. Should there be any issues and you want to revert back, simply run step 10, then step 2. This will bring it back to your original server however if a client has tried to renew their lease, you will have to work on that client individually to rectify the  issue. In my situation I had issues with my Wyse VDI terminals and it took some time to reset their DHCP details. Windows PC’s are much easier by running the following command:

IPCONFIG /RELEASE && IPCONFIG /RENEW

Migration of all Leases

From this point you are confident in migrating the rest of your scopes from all your old DHCP servers. You can do them all in one hit, or stagger them just to be sure there are no other problems. I staged my migration as an extra precaution.  The steps in the previous section explain how to do this for one scope. Below are examples that you can change for step 5 & 9, otherwise the rest can stay the same.

  • NETSH DHCP SERVER export dhcp-vlan7.db 192.168.7.0
    This, as documented above exports just one scope to a database file
  • NETSH DHCP SERVER export dhcp-vlan7and8.db 192.168.7.0 192.168.8.0
    This exports 2 scopes at the same time. You can apply the same principle to export more than two scopes. The file name ” dhcp-vlan7and8.db” can be called anything – I gave it a sensible name so I knew what to import later.
  • NETSH DHCP SERVER export dhcp.db all
    This exports ALL scopes into the database. Note if you do export all the scopes, and you decide to import all scopes on the new DHCP server, you may overwrite existing scope data. This can cause inconsistencies and problems when it comes to issuing leases.

Configuring DHCP Failover

This section will be coming soon in a separate post.

Resources

  1. Using Network Shell Utility (NETSH) to migrate DHCP configuration is definitely not a good idea, if you are planning to configure DHCP failover. This can result in DHCP lease replication issues or reporting different failover states:
    http://support.microsoft.com/kb/2751456

    The suggested update probably will solve the problem, but if you are planning a migraion and DHCP failover, you’d better use the migration tools and avoid this issue.

    • Thank you for sharing this information. I was not aware of the bug and will help me when enabling DHCP Failover once I get to it. I will be able to validate whether the update does fix the issue for me. In my scenario I was not able to use the recommended PowerShell commands to extract the scopes from our Windows Server 2003 DHCP server, therefore I was forced to use the NETSH utility.
      Do you know with what version of PowerShell on 2003 is the Export-DhcpServer or Import-DhcpServer implemented?

      Cheers,
      Ivan

  2. Just wanted mention that I tried the netsh steps on a 2012 Domain Controller and it failed. I then did the same process on a 2012 Member Server and it worked fine. I then promoted it to a DC and then it continued to function.

  3. Hi Ivan,
    I hit some problem during my co DHCP migration & hope you can advise what went wrong. Here is the background.

    On 6th Apr
    1. Migrated only level 3 users to the new DHCP server.
    2. Deactivate the specific scope for level 3 users in the old DHCP server.
    3. Everything works well for next 2 weeks. (DHCP lease is set to 4 hrs)

    On 22 Apr
    1. Export specific scope for level 3 users from the new DHCP server. “e.g: dhcplvl3”
    2. Export all scopes from old DHCP server. (including the deactivated level 3 users) “e.g: dhcpdb” (lease is 8 days)
    3. Import “dhcpdb” to new DHCP
    4. Import specific scope “dhcplvl3” to new DHCP

    Problem: All lvl 3 users are able to grab new ip from the new DHCP, while the rest of the scopes cannot.

    Do you have any idea where went wrong?

Leave a Reply

QR Code Business Card
%d bloggers like this: