So you want to change your IP range?

By Ace Fekay, MCT, Microsoft MVP Directory Services

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.

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, 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):

  •   ( –
  • ( –
  • ( –
  • ( –
  • 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
  • Reference: Change the static IP address of a domain controller
  • 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.
  • 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.
  • 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
  • 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.
  • If using RRAS for NAT, change the configuration to the new internal interface’s IP.
  • Change all of your other servers’ IPs.
    1. Run ipconfig /registerdns
  • Change any static hosts, including printer cards, and other IP static entries.
    1. Restart the printers to take effect.
  • With Windows machines, start them up.
    1. If they haven’t been shut down, then run ipconfig /registerdns on each.
  • Make sure the above works, AD is functional, the DCs and servers can get to the printers, etc.
  • You can run tests such as for Windows 2000 – 2008 R2, dcdiag /v /fix, and if Windows 2003 and older, run netdiag /v /fix.
  • Check Event logs for any errors.
  • Change the internal IP of the router.
  • 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.

    Troubleshooting the Browser Service

    By Ace Fekay, MCT, MVP


    Keep in mind, each subnet has it’s own master browser, and if you are using WINS, the master browser works together with the WINS service to enumerate an infrastructure wide browse list.

    If not using WINS, it uses broadcasts, however, you’ll only see what’s on your own subnet, because NetBIOS broadcasts are more than likely blocked by routers, which is default, and many routers don’t allow NetBIOS broadcast across subnets to be enabled.

    And if you are in a multi-subnetted environment, and you want full browsing capabilities, to get around routers blocking NetBIOS broadcasts, it’s suggested to use WINS.

    And the default WINS settings out-of-the-box, work fine, as long as you set up DHCP WINS options correctly. There is no need to adjust WINS’ registry parameters, otherwise you’ll find yourself trying to change registry entries on multiple servers and mis-keying something. Here’s more info on configuring WINS:

    WINS – What Is It, How To Install It, WINS Replication Partner Design Guidelines, How to Configure DHCP Scopes For WINS Client Distribution, and more:


    Preferably install at least one server OS on each subnet:

    If there is a server OS, and it’s not multihomed, especially if a DC on the subnet and it’s not multihomed (multihoming a DC is a really bad idea), then it should win, unless there’s a problem with the machine itself, such as some sort of security setting in your antivirus blocking traffic, or firewall blocking traffic on it.

    If you find workstations are becoming masters, that means there are no server operating systems on those subnets, in such cases, the workstation will win Master Browser election.

    And I realize in many large infrastructures, it would be nearly impossible to put a server operating system on each subnet. However, as long as there is a desktop using the latest client operating system that is always up and running 24/7, that will do the trick.

    If a newer client OS were to be introduced, then it would start a master browser election, and win the election (OS version and server role is a factor in the election process). And any machine that someone clicks on Network Neighborhood or clicks a Browse button somewhere, would invoke an election, but if a desktop is running on the subnet 24/7, it will win the election, since it’s already up and running.

    If you don’t want any other client machine to win the election and were to opt for only that one machine, you can set a registry entry using a GPO to disable participating in the browse list for all the machines in the subnet other than the client machine you chose to keep up and running 24/7:

    Set the client machine of your choosing to:
    Emulator MaintainServerList=Yes, IsDomainMaster=True

    All other clients on the subnet, set it to:

    I’m not saying this is a perfect solution, but it’s something to consider. Otherwise, if no specific machine is up and running 24/7 on any given subnet, the browse list will be rebuilt each time everyone shuts down, then brings their machines up in the morning, and the cycle starts from scratch to rebuild the list of machines on that subnet.


    Third Party Devices Participating in the Browser Service

    I would like to point out that if you have any 3rd party devices, such as a Seagate BlackArmor NAS, it will jump in on the election process and may win, which in case will snafu your browse list. I had one of those devices at a customer site last year causing numerous problems with the browse list, which in turned snowballed to cause problems with Symantec BackupExec, and other services that rely on browsing.

    After some troubleshooting, I found that the BlackArmor NAS was consistently winning the election causing the problems. I couldn’t find anything specific on how to disable browser service participation on the device. It has the latest firmware. I contacted Seagate, and they said they couldn’t help me to disable the device’s ability to participate in the Browser Service.

    I finally moved it on to its own VLAN so it can be king of itself on that subnet, so to speak. I gave it it’s own island. Smile


    Browse List Propagation:

    We have to keep in mind with troubleshooting the browser service, there is a time period you have to wait for the list to fully enumerate and become available on the master. A good example is when a server is shut off on a segment, and the workstations kick in, or the server is rebooted, wins the election, and begins a new cycle to enumerate the browse list from WINS and/or broadcasts. This can take a minimal of 12 minutes, upwards to the 48-minute full propagation cycle in a multiple-segment domain environment.


    When to Troubleshoot

    Below are the generic troubleshooting steps I used to troubleshoot the browser service that helped me find out the BlackArmor device was the culprit.

    If you are seeing problems with the browser service, such as computers disappearing from the browse list, whether the cause is a third party device, Unix/Linux machine running Samba, or simply based on the infrastructure’s design, it might be a good idea to start troubleshooting to find the culprit.


    Prepare to Troubleshoot:

    • Make sure the Computer Browser service is Started. Make sure NetBIOS is enabled on al machines.
    • On Windows 2003 and 2000, install the Support Tools (from the Windows CDROM) in order to have the "browstat" utility available.
    • With Windows 2008 and newer, the utility is already installed as part of the operating system files.
    • If there are any antivirus software, third party firewalls, or firewall rules between locations blocking WINS traffic (TCP 42), it could block browser traffic, too. This of course, assumes the Computer browser service is running.


    Firewall blocks – Test it with PortQry

    You can use the Portqry.exe utility to test if the Browser, SMB, WINS and the ephemeral (service response) ports are permitted.

    • Browser: UDP 137/138, TCP 139
    • SMB: TCP 445
    • WINS: TCP 42
    • Ephemeral (Service Response Ports): Varies depending on OS:
    • Windows 2000/2003/XP: TCP/UDP 1024-5000
    • Windows 2008/Vista and newer: TCP/UDP 49152-65535

    Description of the Portqry.exe command-line utility

    Active Directory Firewall Ports – Let’s Try To Make This Simple 


    Multihomed DCs:

    And if you have any multihomed DCs, among numerous other problems, that is a major cause of browser problems. Multhoming DCs is not recommended for multiple reasons, including a "Multihomed Browser" scenario. I suggest to disable one of the interfaces.

    More info regarding multihoming DCs and why not to do it:

    Multihomed DCs (with more than one unteamed NIC or multiple IPs) with DNS, RRAS, iSCSI, and/or PPPoE adapters – A multihomed DC is not a recommended configuration, however there are ways to configure such a DC to work properly.


    Troubleshooting Steps:

    Run a browstat status to see who the browse master is for the segment. If it’s not the PDC Emulator, and some other device won the election, that can cause a problem.

    To check current status of the browse service on the domain, run:
    browstat status

    You should get a response similar to:
    Browsing is active on domain.
    Master browser name is: <serverName>

    Note, the machine that is the current master browser will either be, depending if the machine type exists on the segment: the PDC Emulator, a replica DC on the segment, a member server, joined workstation, or workgroup member, Unix or Linux with SAMBA, etc.

    If you find a device is winning the election, then we need to disable that ability in the device. If there are no features for that, contact their support department, or put the device behind it’s own subnet or VLAN to prevent it from winning the election on the production network.

    To find the current browse master on a segment, you’ll have to find the TransportID:
    First run:

    browstat getmaster \device\netbt_el59x1 <domainname>

    It will error out because the "netbt_el59x1" probably doesn’t exist, and will respond with the transports currently bound to the browser. Copy and paste the transport that does show up into your next command:

    browstat getmaster \Device\NetBT_Tcpip_{C2055954-4F86-446F-ACBA-E00BE731C3FB} <domainname>

    Force an election by running:
    browstat elect \device\netbt_ieepro1 <domainname>

    Then check the event logs to see which machine won the election. If it’s a device, such as I’ve found that Linux/Unix with SAMBA, or devices such as a Seagate NAS, may win the election and cause browsing havoc within an environment and get that familiar, but unwanting "Access Denied" when trying to browse.



    Troubleshooting the Microsoft Browser Services:


    Comments, corrections and suggestions are welcomed.
    Ace Fekay