We read Sean Daily's "Recovering DHCP" (September 2001, InstantDoc ID 21841) with interest. A while back, we were involved in a major Windows 2000 migration project that consisted of more than 40,000 DHCP clients. Our team used the Microsoft Windows 2000 Server Resource Kit Supplement One DhcpExim tool to try to migrate DHCP scopes for this project. We found the tool unreliable because it modifies the target and source machines' registries in an unexpected manner.
DhcpExim behaved as we hoped during our initial tests. However, in our tests we migrated numerous scopes at once rather than migrating small batches over several days, as we would do in production (per our customer's requirements). We encountered a problem when we migrated a batch of scopes (Batch A) one night, then used the same servers to migrate another batch (Batch B) the following night. The newly migrated Batch B scopes functioned fine, but the Batch A scopes wouldn't provide DHCP leases to client requests.
From what we could tell, DhcpExim modified the Windows NT 4.0 machine's registry scope entries to make them look like Win2K entries. The tool then exported the entries to the Win2K machine. When the DHCP server started on the Win2K machine, the server changed the NT 4.0 source machine's DHCP registry settings and moved the entries to the new registry location on the Win2K machine. We speculated that DhcpExim was running twice on each machine. When the tool ran the second time, it changed the RangeFlags registry subkey.
On the Win2K system we were migrating to, DhcpExim changed the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Dhcp Server\Configuration\Subnets\192.168.1.0\IPRanges\192.168.1.10 subkey values from
RangeBootpAllocated 0 RangeBootpMaxAllowed ffffffff RangeFlags 1
to
RangeBootpAllocated ffffffff RangeBootpMaxAllowed 1 RangeFlags 0
The tool seemed to shift the subkey values, and DHCP subsequently wouldn't serve addresses. We couldn't find a TechNet article that referenced the RangeFlags value, but we suspected the value needed to be 1 or 3 to serve DHCP. We later found the Microsoft article "DHCP Server Does Not Issue IP Leases After You Run Dhcpexim.exe" (http://support.microsoft.com/default.aspx?scid=kb;en-us;q287031), which confirmed our assumption. According to the article, to correct the registry corruption we needed to manually set each scope to respond only to DHCP requests. We started the Microsoft Management Console (MMC) DHCP snap-in, right-clicked each scope, selected the Properties tab, then selected the Advanced tab. Finally, we selected the DHCP Only radio button. This action changed the subkeys to
RangeBootpAllocated ffffffff RangeBootpMaxAllowed ffffffff RangeFlags 3
DHCP subsequently resumed serving addresses. DHCP also held these values when we stopped or restarted the DHCP server service. An alternative solution we discovered was to manually delete and recreate the dysfunctional scopes. Neither of our initial solutions was efficient enough for our customer.
We conducted additional tests and reported our findings to Microsoft Premier Support. Finally, we created a process that used only scripts to migrate scopes' registry settings. The scripts copied the scopes from the NT 4.0 registry, reformatted the scopes to comply with the Win2K registry, imported the scopes into the Win2K DHCP registry on the target server (placing the scopes in the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Dhcp Server\Configuration\Subnets registry subkey), and enabled the scopes. Thus, we were able to move the DHCP leases in an active state. Our new process let us migrate scopes incrementally rather than migrating entire servers at once. Our migration project then proceeded smoothly. In light of our experience, we suggest using DhcpExim only when necessary and only after thorough testing. In addition, we recommend using the tool only once per machine and only for migrating entire servers.
