Category Archives: Windows Server 2008

Windows 2012 DHCP – Migration and Fault Tolerance

A long overdue feature in Windows Server 2012 is the ability to have a truly distributed DHCP infrastructure. You used to have to use the 80/20 split scope configuration which was at best administratively burdensome, and at worst unmanageable for a large enterprise. Alternatively, you’d have to run a Windows cluster for DHCP – who actually wants to do that? Windows Server 2012 now offers distributed DHCP failover.

I’ll start by talking about migrating your DHCP configuration from Windows 2008 to Windows 2012. First, you obviously have to install Windows 2012 and add the DHCP role. Microsoft has made it ridiculously easy to export and import the configuration with PowerShell – you can complete the process with 2 commands.

Open a PowerShell window on your 2012 server and run
Export-DhcpServer -ComputerName your2008DHCPserver.foo.com -Leases -File C:\path\to\exportfilename.xml -verbose

export 2008 DHCP configuration

Exporting Windows 2008 DHCP configuration

A bit of advice from my lab environment – if you have a clock mismatch between domain controllers, you won’t be able to run these remote Powershell commands. If you’re getting strange errors in your lab, check the clocks on your DCs. My 2012 DC was many hours behind my 2008 DC and I couldn’t run any commands. I fixed the clock and the problem disappeared.

When your export is complete, run the import.
Import-Dhcpserver -Leases -File C:\path\to\exportfilename.xml -BackupPath C:\windows\temp\ -verbose

import dhcp configuration

Importing DHCP configuration from a Windows 2008 export

 

dhcp import complete

Import of 2008 DHCP configuration completed.

 

The 2008 imported scopes on the 2012 DHCP server.

The 2008 imported scopes on the 2012 DHCP server.

 

 

Moving on to configuring the failover –

Configuring failover on a DHCP scope

Configuring failover on a DHCP scope

Not much to see here, but if you don’t have any scopes visible you aren’t going to be able to go much farther. One possible solution to the problem is in this post.

First screen of the failover wizard

First screen of the failover wizard

Specify another Windows 2012 server with the DHCP role already installed.

Specifying a failover partner in the failover wizard

Specifying a failover partner in the failover wizard

 

The failover relationship must be named. Maximum client lead time refers to amount of time the surviving DHCP host will wait before assuming complete control over the scopes. For mode, you can pick either load balanced or hot standby – basically an active-active or active-passive relationship.

Defining the failover relationship

Defining the failover relationship

 

Finish will kick off the process.

Last screen of the failover wizard

Last screen of the failover wizard

Failover progresses to completion

Failover progresses to completion

The scope and leases are now visible from the secondary DHCP server.

The failover scope as seen on the secondary DHCP server

The failover scope as seen on the secondary DHCP server

I will now shut down the primary DHCP host and leave the secondary host online. You can see my Linux guest with the DHCP address of 192.168.237.201.  After shutting down primary DHCP, I reboot this Linux guest.

Client IP prior to reboot

Client IP prior to reboot

The guest comes back with the same .201 IP address, this time served by the secondary DHCP host.

Client IP after reboot - DHCP served by failover host.

Client IP after reboot – DHCP served by failover host.

Now I boot a second Linux guest and it draws a .220 IP address from the secondary DHCP host.

A second client VM booted with primary DHCP server disabled

A second client VM booted with primary DHCP server disabled

Here are the leases as seen from the secondary DHCP host. Both of the Linux hostnames are the same because I didn’t bother customizing them in the guest. However, the MAC addresses are different and each VM is drawing the correct IP.

DHCP leases on failover host

DHCP leases on failover host

I now bring the primary DHCP host back up. Immediately after boot, you can see that the lease for the .220 IP is not listed.

DHCP leases on DC2 after reconnected

DHCP leases on DC2 after powerup

We could wait for the hosts to do this themselves, but we’re impatient and force a replication.

Forcing scope replication to pull leases from failover host

Forcing scope replication to pull leases from failover host

Now the .220 lease is visible from the primary host.

DHCP leases on primary host

DHCP leases on primary host

Now we take down the secondary DHCP host, leaving only the primary online. Reboot both of the Linux guests and they both correctly draw the .201 and .220 IP address.

DHCP IP on client 1 after reboot

DHCP IP on client 1 after reboot

Client 2 rebooted

DHCP IP on client 2 after reboot

Once you have this set up you can configure your network infrastructure with multiple DHCP addresses. Vendors have various names, but Cisco refers to this as the ip helper address. DHCP requests will always be sent to both DHCP hosts, but each scope is active on one host at a time. One DHCP request will be acknowledged and the other will be ignored.

Windows 2012 DHCP Failover – Cannot enable

I tried setting up the new Windows 2012 DHCP failover and got it working, but I couldn’t get some of my scopes that I’d imported from 2008 to 2012 working. If I built the same scope (or what I THOUGHT was the same scope) from scratch in 2012, I could configure failover.

I posted in the Microsoft forums but didn’t find resolution. However, one month later somebody posted the solution on my thread. My 2008 scopes happened to have both DHCP and BOOTP enabled, and you can’t enable failover on a scope set to both DHCP and BOOTP.

Windows 2008 primary IP – DNS registration

Update 2011-07-16
We filed a request to have the 2008 R2 solution listed below backported to Windows 2008 SP2, but the request came back denied yesterday. The escalation engineer’s comment: “Considering that Windows Vista and 2008 SP1 hit End of Life this month, the resources were not available for a fix.” That will close the book on this issue – if you need the SkipAsSource functionality in Windows 2008, you have to use 2008 R2.

Update 2011-04-15
Microsoft support advises that there are no plans to bring the ‘netsh int ipv4 show ipaddresses level=verbose’ command to Windows 2008. It will only be available for 2008 R2.

Update 2011-04-10
I can confirm that KB2386184 does work on Windows 2008 R2, the netsh int ip command with the SkipAsSource flag works, and ‘netsh int ipv4 show ipaddresses level=verbose’ does display the flags on all IPs on the box. The issue I ran into was because of how the Hotfix downloader works. We don’t download patches directly from servers, so I was downloading from my workstation which is Windows 7 32-bit. I didn’t notice at the time, but it pushed a 32-bit version of the hotfix down because that’s what it detected on my workstation. When I tried installing the 64-bit version, it (not suprprisingly) worked.

I have our MS rep looking into why the same show ipaddress command doesn’t exist for 2008 SP2, KB975808.

Update 2011-04-06
My change request was closed. MS says they addressed the 2 biggest concerns – setting the SkipAsSource flag and being able to view the flag in the hotfix available at KB2386184. They opened a new ticket to address why I am unable to successfully install the hotfix – when I attempt the installation on 2008 R2, I get an error saying that the hotfix doesn’t apply to my system.

Update 2011-04-02
KB2386184 references a way to at least dump the existing SkipAsSource flag on Windows 7 and Windows 2008 R2, but I was unable to install the hotfix, it said the hotfix didnt apply to my 2008 R2 server. I have a meeting next week with a product manager, hopefully we can come to some resolution.

Update 2010-02-08
Heard back from Microsoft and option “a” below is being considered for backporting into Windows 2008. All of the features listed below are part of Windows 8.

Update 2009-12-17

We have filled out a design change request for Microsoft – we’re not holding our breath on implementation though.

a) There doesn’t appear to be a command to list out the IPs on the box and determine which ones are flagged SkipAsSource. When we have a server that’s reporting intermittent failures to connect to an SMTP server, it is not possible to figure out which IP is the offending IP.
b) The SkipAsSource flag should be in the GUI instead of a command line netsh.
c) You can only set the flag on an IP add, not on an existing IP.
d) We should be able to set the default behavior so new IPs that are added are automatically flagged SkipAsSource.

Update 2009-11-16
Microsoft advised the instructions in their hotfix were not 100% accurate, the syntax of the netsh command was incorrect. It has since been updated. I did get the hotfix to work with one caveat: the name of the interface can not start with a digit – the command fails unless the interface name starts with a letter i.e. interface 10.0.0.x won’t work, but if you name it i10.0.0.x it will work.

It’s not a great solution because 1) You can only use the netsh command to add an IP with the SkipAsSource flag, there’s no way to set it after it’s on the box, you have to delete and add it again 2) You have no command to display which IPs have the SkipAsSourceFlag set, 3) There’s no GUI option, 4) There’s no option for SkipAsSource to be the default setting for all IPs added to the box. But it’s the best we have for now.

2009-11-02
We’ve run into issues with Windows 2008. The first is that every IP on the box gets auto-registered in DNS. This causes issues with some of our monitoring software being unable to handle multiple IPs returned in the DNS query. The second is that there is no concept of “primary” IP on the box anymore. In Windows 2003, the first IP on the box is the primary IP and it’s the default IP for all outbound communication. In what appears to be a random fashion, 2008 picks different IPs for outbound traffic. This is causing problems as we’re having to add firewall rules for every new IP that we add to a box – we never know which IP is going to be used to hit a SQL box or SMTP server.

I found this MS article that explains how an IP is selected. This does seem to explain the behavior; however, it isn’t consistent. I also found a hotfix KB975808 that claims to fix the DNS registration and primary IP issue, but was unable to get it to work. The fix is a “SkipAsSource” flag addition to the netsh command, adding an IP with the flag enabled will force windows to skip the IP for DNS registration and outbound IP selection.

I opened a ticket with Microsoft and we’ll see what happens.

Windows must be reinstalled to activate

We got this message popping up on a Windows 2008 Enterprise server – we cloned 10 machines from the same template and only got this error on 1 of them – go figure. We used this to fix the licensing problem.

1. Run cmd.exe as Administrator
2. net stop slsvc
3. cd %windir%\ServiceProfiles\NetworkService\AppData\Roaming\Microsoft\SoftwareLicensing
4. rename tokens.dat tokens.bak
5. net start slsvc
6. cd %windir%\system32
7. cscript slmgr.vbs -rilc
8. Reboot
9. Key in your KMS key at the prompt after reboot – by this I mean the appropriate KMS client setup key, not the KMS key you apply to your KMS server.
10. Windows will activate from your KMS server
11. Reboot again to get rid of the black “not genuine” desktop.

Repairing Windows 2008 Server

Although we’ve had Windows 2008 in the environment for quite some time, but this is the first time I’d encountered a boot error stating that ntoskrnl is missing or corrupt. If you’ve never had to deal with this on Windows 2008, it can be a little confusing as there isn’t an option to do a repair install anymore.

You can boot from the installation media, then select “Repair”, then select Command Prompt. This will put you into an X: drive

You can run X:\Sources\Recovery\StartRep.exe and it will repair the boot error – at least it did for me in this instance.