By Ace Fekay, , MCT, MVP, MCSE 2012/Cloud, MCITP EA, MCTS Windows 2008/R2, Exchange 2007 & 2010, Exchange 2010 Enterprise Administrator, MCSE 2003/2000, MCSA Messaging 2003
Microsoft Certified Trainer
Microsoft MVP: Directory Services
Active Directory, Exchange and Windows Infrastructure Engineer
www.delcocomputerconsulting.com

 

So you are looking at a major IP migration from a public range to a private range and not simply extending the current scopes, or you simply want to change the current IP range.

One good reason to change the internal IP range, is the current range matches many of the retail box store router default IP subnets, such as from Linksys, Netgear, etc. The identical subnets cause issues when users at home are using VPN to the company network. If the subnets are identical, routing won’t work, therefore they are never able to connect or access internal company resources.

Depending on the size of the infrastructure, changing the IP range can either be easy, or pretty involved and will have a major undertaking on your hands. Let’s see…

 

First come up with an IP Range

Come up with a plan that includes an IP range for all servers and static set hosts, as well as an IP range for each floor, building, etc., depending on the scope of this project, and the subnets currently in place.

You could use the same subnet for the whole building, which makes it easier to deal with, but not necessarily as efficient with network traffic, and especially if the number of hosts is so large (into the thousands), it becomes a rather large subnet broadcast domain. Also with one big subnets, you are reducing the ability to create efficient AD Sites appropriately.

For example, if one were to choose one subnet for a large building with 3000 users, you could use one subnet, such as 10.10.0.0/16, which will give you 65,000 IPs:

If you want to keep with the separate subnets for each floor, which is ideal, of course considering if you have layer 3 VLAN capable switches, that may be your better bet. Some may think it complicates matters with DHCP and routing, but looking at the network efficiency, I think it’s a better bet.

For example, if you have multiple subnets or buildings with less than 4000 total hosts (servers, users, printers, etc.), a good example is the following breakdown, which will give you 4096 hosts for each subnet (and this is just an example – your mileage may vary):

• 10.10.0.0/20   (10.10.0.0 – 10.10.15.255)
• 10.10.16.0/20 (10.10.16.0 – 10.10.31.255)
• 10.10.32.0/20 (10.10.32.0 – 10.10.47.255)
• 10.10.48.0/20 (10.10.48.0 – 10.10.63.255)
• etc

 

Procedure (steps are not in stone)

1. Inventory all applications that have been configured with hardcoded IP addresses in their configuration, then change the IPs to the new IPs.
2. Ask users to shutdown all workstations.
3. Change the DC/DNS server’s’ IP addresses.
   1. In NIC properties, change it to the new IP address.
   2. In NIC properties, change the DNS IP addresses to the new IP.
   3. Re-register the DCs in DNS so it re-creates new records.
      1. ipconfig /all
      2. restart netlogon service
   4. Reference: Change the static IP address of a domain controller
      http://technet.microsoft.com/en-us/library/cc758579(WS.10).aspx
4. Check DNS:
   1. Server properties, Nameservers tab, insure the new IPs are listed.
   2. Remove the old ones and re-enter if needed.
   3. Check DNS zones – Make sure all old IP references are manually removed if the registration process above does not overwrite the old ones, which it should.
   4. Check the GC records (located in gc. _msdcs.domain.local).
   5. Check the LdapIpAddress records – the “same as parent” A records that each DC registers.
5. Create a new reverse zone for the planned IP subnets. Make sure updates are allowed.
   1. Delete the old reverse zone.
   2. In lieu of deleting and recreating the reverse zones, if you’re energetic:
      1. Change the AD integrated reverse zone to a Primary Standard zone (this takes it out of AD and puts it into a text file in system32\dns.
      2. Open the system32\dns\zoneName.dns file, and change all the IPs in the zone file, save it, reload the zone. You should see all the new IPs
      3. Then change it back to AD integrated again.
6. Change the DHCP Server’s scope.
   1. You will need to delete and re-create the scope from scratch.
   2. If you have Scope Options recreate the Scope Options.
   3. If you have Server Options, simply change the IP addresses they point to.
      1. If using WINS, change DHCP Option 044 to the new IP address of the WINS server.
      2. Option 003 is the router
      3. Option 006 is for DNS addresses
7. If using Windows RRAS for VPN, and you are using a static IP pool, change the pool to a range in the new IP range.
   1. If using any other VPN solution, likewise.
   2. If using a Relay Agent or IP Helper, change the IP it’s pointing to.
8. If using RRAS for NAT, change the configuration to the new internal interface’s IP.
9. Change all of your other servers’ IPs.
   1. Run ipconfig /registerdns
10. Change any static hosts, including printer cards, and other IP static entries.
    1. Restart the printers to take effect.
11. With Windows machines, start them up.
    1. If they haven’t been shut down, then run ipconfig /registerdns on each.
12. Make sure the above works, AD is functional, the DCs and servers can get to the printers, etc.
13. You can run tests such as for Windows 2000 – 2008 R2, dcdiag /v /fix, and if Windows 2003 and older, run netdiag /v /fix.
14. Check Event logs for any errors.
15. Change the internal IP of the router.
16. Recreate port-mappings (port translations) on the firewall, if required.

 

Do Multiple Internal Subnets exist?

1. If using multiple internal subnets that you are currently connected to, change the static route entries on the edge firewall/router to insure communications work to the other subnets. The same on their end.
2. Once again, check event logs for any errors.
3. Test internet connectivity from your DCs and servers.
4. DHCP – Take note of exclusions, reservations, SuperScopes, etc. Delete all scopes.
5. Create a new big scope, or multiples if you had separate scopes, Superscopes, etc.
6. Test DHCP by firing up a couple of workstations, logons, internet connectivity, printers, resource access, etc.
7. Once again, check event logs for any errors.

I’m sure I may have missed a few steps and only briefed over others, but it should give you a good start and a guideline, because every infrastructure is different and unique.

 

Comments, corrections and suggestions are welcomed.