A friend came to me this week with an issue he had earlier – he had to change the subnet of a clientís network, and issues with the Windows 2003 Domain Controller appeared. Hereís how to avoid (or fix) the problem. For this HowTo, Iíll be using a current network of 192.168.1.2/24, with the server being itís own DNS and WINS, and a gateway of 192.168.1.1. Weíll be changing the server to 172.31.2.2/24, and using the domain name ďfoobar.localĒ.
- Why are you changing the subnet? Most often, Iíve had to do this for customers because a business partnerís subnet has conflicts that are coming up during VPN tunnel creation. Iíve had other reasons, and you might too – but thatís the most common Iíve seen – 2 sites that are both 192.168.1.0/24 trying to build a VPN tunnel to each other.
- Now that you have a good reason to go through the pain, determine your layout – Iím going to write this for a single DC environment and point out a few changes for a double-DC environment. If you have more, you should be able to extrapolate the requirements from there, but you can also leave some comments and I can write another post if required. Iíll also be writing cmd scripts for most changes, rather than attaching huge (pixel-size) images.
- Determine the new subnet.
- Add the reverse lookup zone to DNS for your new network. In this case, in the DNS wizard, youíd make the reverse zone ď172.31.2? (filling in all boxes). This makes the zone name ď2.31.172.in-addr.arpaĒ or ď172.31.2.xĒ in the DNS console.
- Open Active Directory Sites and Services. Right-Click ďSubnetsĒ and add in the new subnet (172.31.2.0 with a Subnet Mask of 255.255.255.0). Youíll see the subnet listed as CIDR notation in the box (172.31.2.0/24) for verification. Pick the site that the new subnet belongs in (probably Default-First-Site-Name), and click ďOKĒ. This guarnantees that AD will recognize the new site properly.
- Determine the new IP for the DC, and *add* it to the DCís adapter. Do NOT remove the existing IP, yet. Donít add the new gateway, yet. Just add the new IP, and save the settings.
netsh interface ip add address "local area connection" 172.31.2.2 255.255.255.0
(This command assumes that your DC has a static IP address. I havenít seen a site use DHCP for their DCs yet, but itís a possibility. This command on a DHCP address will set only a SINGLE address with no gateway, and could leave you with 0 remote access to the server.)
- Verify that the new IP is showing up on the server.
- Get the server to register its new info in DNS
- Wait and watch the Application and System event logs for DNS related errors. Also check that the DNS server is publishing the new IP address, not just as the server name, but also as the domain name, and the DCs (This can take up to, but shouldnít take longer than, 15 minutes):
Also, open the DNS console and look inside ď_msdcs.foobar.localĒ to see that the GUID of the server is listed with both IPs.
- Once the server is advertising the new IP, you can swap the system to use the new IP range completely. Itís not time to remove the old IP yet though. This is the time to change the gateway, DNS servers, and WINS server. Since the server is listening on, and advertising on, the old and new IPs, DNS shouldnít have any issues.
netsh interface ip set address "local area connection" static 172.31.2.2 255.255.255.0 172.31.2.1 10
netsh interface ip add address "local area connection" 192.168.1.2 255.255.255.0
netsh interface ip set dns "local area connection" static 172.31.2.2
netsh interface ip set wins "local area connection" static 172.31.2.2
This can, like all other steps, also be done in the GUI quite easily, by just shifting the orders of some things (IPs), and replacing others (DNS/WINS/Gateway).
- Now re-register the server with itself, looking for error messages in the Application and System logs.
- Remember that changes to DNS can take up to 15 minutes to appear, as you watch the logs for errors, and check dns.
What youíre looking for in the nslookup is to see the address of every domain controller in your domain. If this is a single server (like a Small Business Server 2003 network), you should, at this point, see 2 or 3 addresses (depending on how you set up your public network, for SBS2003).
- If everything looks good here, this is a good time to test some logons to make sure things are working properly. This is the point in the project where I normally create the new DHCP scope, deactivate (not delete) the old scope, and change the LAN settings on the router. This is also a good time to reboot some of the client PCs to make sure that they can boot up properly, get IP addresses in the new subnet, login without errors (remember to check that Application log!), and get online without issues.
Because we havenít removed the old IP from the server yet, the biggest issue you *should* run into is a client who gets an IP from the old subnet, or is statically set. Theyíll log in ok, but wonít be able to get to the internet (unless youíve got SBS2003, and the server is also your router). At this point in time, itíll be easy to figure out if the new IP is working – clients that can log in and get access to resources are logging in to the IP address for the DC thatís local to them – if theyíre in the new subnet, then your new IP is working. You can now reboot your DC as a final test (or act of faith, as your experience may prompt).
- When the DC comes back up, log in, and remove the old IP address – this is easiest in the GUI, but if youíre doing it with netsh, I prefer to just reset the DC settings completely.
netsh interface ip set address "local area connection" static 172.31.2.2 255.255.255.0 172.31.2.2 10
Now itís cleanup time.
- Open Active Directory Sites and Services. Delete the old subnet.
- Open up your DNS server and make sure your forwarders are correct – lots of small offices skip this step – your forwarders should be the IP addresses of the DNS servers that your ISP gave you. Donít put these into your DHCP scope DNS servers list, or even in the list of DNS servers on your server – they go in the ďforwardersĒ section here.
- Thatís it. Your clients are set up and ready to go, your server is healthy, and now you get to tackle the problem that made you have to change the IP in the first place!
For those who are having issues, because theyíre finding this after attempting the change, or for my friend who prompted me to write this, here are some suggestions:
- Add the old IP back to the server, run <code>ipconfig /registerdns</code> and wait for the old IP to take. Now verify that the serverís logging in properly, and not giving error messages.
- Do you have all the zones in DNS, so that registration can take? Many small sites forget to put in the reverse zones into the DNS server.
- Go back and check Active Directory Sites and Services to verify that both the old and new subnets are listed. While youíre in transition, all subnets should be listed in all locations.
- If your server is screwed up badly enough that you canít even log in, boot into Active Directory Services Restore Mode, make sure that your networking changes are set properly, and that your DNS server has itís forwarders set up right. This is a good way to check the base level of your serverís health, then bring it back online to try to log into AD.
- Thereís no reason to need to rebuild the server, but if itís a small enough location (AD doesnít change very often, or if it does, the changes are minor), and you have good backups, take a look at how long this is taking you, and how much longer youíll spend attempting to fix the problem. Going back to the backup from the previous night and restoring ONLY the system state in Directory Services Restore Mode might be the fastest and best solution. Then you can follow the steps in here in order, and grow fewer ulcers.
Next week sometime Iíll do a similar version for multi-DC, multi-Site AD networks – itís a lot shorter and easier.