How will changing office IP Range impact on Active Directory????

  • Thread starter Thread starter Paul
  • Start date Start date
P

Paul

My company needs to change from the 192.168.x.x range to a 10.10.x.x range.
We are currently on Win2K and XP clients and are using active directory.

We've got 4 smaller (50 or so people) remote offices where we have DC's, and
are using MS DNS.

Since we've never done something like this we are afraid to simply change
IP's on the servers etc. This might screw up things for Active Directory we
fear, and of course we want as little downtime as possible for the company.

I've tried to find info on what kind of procedures to follow on the web but
have unfortunately not been able to find it.

What approach would be best? what Best Practices and procedures should we
follow? Who has done this & might have pointers? Any advise, tips or
recommended reading?

thanks!

Paul
 
<inline>

Paul said:
My company needs to change from the 192.168.x.x range to a 10.10.x.x
range. We are currently on Win2K and XP clients and are using active
directory.
Click to expand...

The obvious question I have to ask is *why*? Why go through all that in
order to change IPs from one private addressing scheme to another?

We've got 4 smaller (50 or so people) remote offices where we have DC's,
and are using MS DNS.
Click to expand...

Are you using DHCP?

Since we've never done something like this we are afraid to simply change
IP's on the servers etc. This might screw up things for Active Directory
we fear, and of course we want as little downtime as possible for the
company.
Click to expand...

If you plan this correctly, you will have little downtime - but you will
have some downtime. It's a long weekend job.

It's not just the servers. All the clients (of course) must be changed. In
addition, you have the routers and VLANs.

Then, you need to change scopes on all the DHCP Servers, clear the WINS
database, etc.

Then there is troubleshooting. Before you start this, save some time and
search for unknown Hosts and LMHOSTS files - and get rid of them.

I've tried to find info on what kind of procedures to follow on the web
but have unfortunately not been able to find it.
Click to expand...

Create a script for everyone to follow. Do a dry run with the team, test it
in the lab, do another dry run ... IOW - get the proceedure down pat.

Ensure you have a backout plan.

Establish a command center and man it. Get radios or phones for everyone.
Know what everyone's job is during the project, ensure each step is done and
follow up. Keep status in the "war room".

What approach would be best? what Best Practices and procedures should we
follow? Who has done this & might have pointers? Any advise, tips or
recommended reading?
Click to expand...

1 - Select a team from all sectors of your operaton

2 - fully document your current networ

3 - Create a basc plan for the mgraton and revew t wth the team.

4 - Create a detaled plan

5 - Dry-run

6 - Revew and rewrte

7 - Execute plan


-ds
 
WHY? is a really good question.

Actually just went through this recently. Needed to add an ISA server into
an existing environment with the corporate stipulation that the internal IP
of the most external FW not change. In other words, bad planning....

I embarked on this project, spent about 3 days in the lab before being
pulled off to other projects, and here are my notes (and they are notes). I
got damn close, but I WAS NOT 100% successful. (my only remaining error was
the BITS error. Seemed harmless, but still flagged red...)

To my knowledge this has not been implemented onsite to date. Note also
that my Exchange test environement started as a base install, but was not a
functioning environment, so I didn't have a reliable way to test through any
issues there.

I provide these notes NOT as a PROCESS DOCUMENT, but only so that you may
learn from it. Please check it out and make any changes that you think are
appropriate, but don't follow exactly....

Enough disclaimer? How 'bout: Don't blame me when this doesn't work...

;-)

Do Until Problems = 0
research, plan, test
loop


NOTE: the Event Descriptions are copied from EventID.net...


--
HTH,
=d=


Dana Brash
MCSE, MCDBA, MCSA

(e-mail address removed)


Change IP Testing



Document Purpose:

Develop a process by which we can change the Subnet configuration of an
existing domain with attention to maintaining the function of network
services. These services include DNS, DHCP, AD, Exchange and Veritas.



Steps:



1. Change Gateway IP address (In our Case ISA Server)

a. Changed IP and DNS to use 172.16.1.0/24 subnet

b. In ISA Server, Changed Internal Network Subnet configuration from
172.16.0.x/24 ? 172.16.1.x/24

c. Reset ISA Services



DC

2. Change the IP Information

a. Changed IP and DNS to use 172.16.1.0/24 subnet

3. DNS

a. Change the Reverse Lookup Zone IP Info (delete and re-create)

b. Changed the Host (A) Records, made sure that the PTR records got
created

c. Walk through the entire Forward lookup zone and confirm the correct
subnet.

i. gc._msdcs.lab.local

ii. Domain.DnsZones.Lab.Local

iii. Forest.DnsZones.lab.local

d. Check the Server level for Forwarders to make sure they point at the
right place if anywhere.

4. DHCP ~~ Change the Zone Information

a. On open DHCP, the IP information for the registered servers should
refresh with the right information.

b. Un-authorize the old DHCP servers

c. Change the Scope Information on the General Tab > Range overlap
errors

d. Create an Identical Scope in place with the new Subnet info. Check
Exclusions, and Scope Options

5. TEST to ping Google.com to make sure DNS and IP config is working OK



Exchange

1. Change the IP information

a. Changed IP and DNS to use 172.16.1.0/24 subnet

b. Changed the Primary Lookup Zone to have the SOA be the DC

c. Changed the DC~{!/~}s Host Record to the correct IP address

d. Confirmed in DNS ON the DC that DNS Zones will replicate to all DNS
Servers

e. Rebooted system to populate Zone

f. Confirmed that it populated

g. Deleted Stray records

h. Ran Scavenge Stale Resource Records

i. Authorized the DHCP Server with the new IP address, and everything
appears OK now.



Exchange services all started, and everything appears fine. BUT we should
develop a better test bed to make sure we don~{!/~}t have a problem.



On Domain Controller, many Userenv: 1058 and 1030 errors indicate problems
reading GPO~{!/~}s. Can read, no fruit yet

DNS error 4015



On Exchange Server

NtFrs error 13562 DFS

~{!0~}Following is the summary of warnings and errors encountered by File
Replication Service while polling the Domain Controller <domain controller
DNS name> for FRS replica set configuration information. Could not find
computer object for this computer. Will try again at next polling cycle.~{!1~}



DFS errors on Exchange server:

Ran dfsutil /Clean /Server:lab-ex /Share:Test (name of DFS root share)
/Verbose

Ran successfully

Ran:

Dfsutil /Clean /Server:lab-dc /Share:Test /Verbose

Ran Successfully



BITS hung on starting, but started briefly after that:

Service Control Manager error 7022

Service: "Background Intelligent Transfer Service" - See Q314862

http://support.microsoft.com/?kbid=314862



http://www.eventid.net/display.asp?eventid=40961&eventno=1398&source=LsaSrv&phase=1



http://support.microsoft.com/?kbid=823712

CAUSE

This behavior occurs when you restart the server that was promoted to a
domain controller. In this scenario, the Windows Time service (W32Time)
tries to authenticate before Directory Services has started. There are no
adverse effects on computers that experience the warning events that are
described in the "Symptoms" section.



http://support.microsoft.com/?kbid=824217

CAUSE

This issue may occur if the File Replication Service (Ntfrs.exe) tries to
authenticate before the directory service has started.

WORKAROUND

To work around this issue, ignore these two warning events if the directory
service starts successfully. If the events continue to appear after Windows
has successfully restarted, you may have to troubleshoot the directory
service.



Dhcpserver error 1059



We had this error while there was a domain controller booted that should not
have been there. This old machine was installed weeks ago as the domain
controller with the same domain name but then sorted out because of hardware
problems. After this old DC was down, restarting the DHCP-Server resulted in
a clean startup without any error. For hours there were 2 DC's there both
with global catalogs, etc. but different security ids for the domain.



Un-authorized the OLD dhcp servers~{!-~} should put this step up above, when
configuring DHCP.



Many issues with GPO~{!/~}s and stuff, removed the GPO and will rebuild





On ISA server:

DnsApi error 11165

This event will appear if the DNS Suffix on the TCP/IP properties on the
Network card is invalid. In our case, the PC was setup with domainx in the
field, rather than domainx.com. Once the DNS Suffix matched the AD or at
least is a vaild "domain.extension" this error stops.



Changed the setting to register with DNS on the Public NIC





Log:

Step 1

Change Gateway IP address (In our Case ISA Server)

Changed IP and DNS to use 172.16.1.0/24 subnet

In ISA Server, Changed Internal Network Subnet configuration from
172.16.0.x/24 ? 172.16.1.x/24

Checked to make sure that WPAD (Firewall Client Publishing settings) are
hostname based, and not DIRECTLY affected by IP change.

Should work once DNS has the proper subnet info. Will double check.

Reset ISA Services



Step 2

Change the IP Information on the DC

Changed IP and DNS to use 172.16.1.0/24 subnet

Tried reconnecting Firewall Client, failed to detect.

DNS

Change the Reverse Lookup Zone IP Info (delete and re-create)

Changed the Host (A) Records, made sure that the PTR records got
created

Walk through ALL the Forward lookup zone and confirm the correct
subnet.

gc._msdcs.lab.local

Domain.DnsZones.Lab.Local

Forest.DnsZones.lab.local



Check the Server level for Forwarders to make sure they point at the right
place if anywhere.



Change the Zone Information in DHCP

On open DHCP, the IP information for the registered servers
should refresh with the right information.

Change the Scope Information on the General Tab > Range overlap
errors

Create an Identical Scope in place with the new Subnet info.
Check Exclusions, and Scope Options



Confirmed that we can reach Google.com



Step 3

Change the IP information on the Exchange Server

Changed IP and DNS to use 172.16.1.0/24 subnet

Changed the Primary Lookup Zone to have the SOA be the DC

Changed the DC~{!/~}s Host Record to the correct IP address

Confirmed in DNS ON the DC that DNS Zones will replicate to all
DNS Servers

Rebooted system to populate Zone

Confirmed that it populated

Deleted Stray records

Ran Scavenge Stale Resource Records

On review of Event Logs, System errors show DHCP NOT AUTHORIZED

Open DHCPmgmt.msc

Service is down

Authorized the DHCP Server with the new IP address, and
everything appears OK now.



Exchange services all started, and everything appears fine. BUT we should
develop a better test bed to make sure we don~{!/~}t have a problem.



On Domain Controller, many Userenv: 1058 and 1030 errors indicate problems
reading GPO~{!/~}s. Can read, no fruit yet

DNS error 4015



On Exchange Server

NtFrs error 13562 DFS

~{!0~}Following is the summary of warnings and errors encountered by File
Replication Service while polling the Domain Controller <domain controller
DNS name> for FRS replica set configuration information. Could not find
computer object for this computer. Will try again at next polling cycle.~{!1~}



DFS errors on Exchange server:

Ran dfsutil /Clean /Server:lab-ex /Share:Test (name of DFS root share)
/Verbose

Ran successfully

Ran:

Dfsutil /Clean /Server:lab-dc /Share:Test /Verbose

Ran Successfully



BITS hung on starting, but started briefly after that:

Service Control Manager error 7022

Service: "Background Intelligent Transfer Service" - See Q314862

http://support.microsoft.com/?kbid=314862



http://www.eventid.net/display.asp?eventid=40961&eventno=1398&source=LsaSrv&phase=1



http://support.microsoft.com/?kbid=823712

CAUSE

This behavior occurs when you restart the server that was promoted to a
domain controller. In this scenario, the Windows Time service (W32Time)
tries to authenticate before Directory Services has started. There are no
adverse effects on computers that experience the warning events that are
described in the "Symptoms" section.



http://support.microsoft.com/?kbid=824217

CAUSE

This issue may occur if the File Replication Service (Ntfrs.exe) tries to
authenticate before the directory service has started.

WORKAROUND

To work around this issue, ignore these two warning events if the directory
service starts successfully. If the events continue to appear after Windows
has successfully restarted, you may have to troubleshoot the directory
service.



Dhcpserver error 1059



We had this error while there was a domain controller booted that should not
have been there. This old machine was installed weeks ago as the domain
controller with the same domain name but then sorted out because of hardware
problems. After this old DC was down, restarting the DHCP-Server resulted in
a clean startup without any error. For hours there were 2 DC's there both
with global catalogs, etc. but different security ids for the domain.



Un-authorized the OLD dhcp servers~{!-~} should put this step up above, when
configuring DHCP.



Many issues with GPO~{!/~}s and stuff, removed the GPO and will rebuild





On ISA server:

DnsApi error 11165

This event will appear if the DNS Suffix on the TCP/IP properties on the
Network card is invalid. In our case, the PC was setup with domainx in the
field, rather than domainx.com. Once the DNS Suffix matched the AD or at
least is a vaild "domain.extension" this error stops.



Changed the setting to register with DNS on the Public NIC
 
Also don't forget to change things that some people never take into
consideration---printers and switches with hard-coded IP's. You'll also
need to update any print server(s) you're using with printing to IP
addresses.

Sorry I just made the project a little bigger :x

Ken
 
Thanks for the great feedback Ken, Dave and Dana (great notes b.t.w, I'll be
using those!!). This is going to be a considerable help!

To answer the "Why?" question: to fit into the larger network of the parent
company, as some corporate changes are being pushed through.. In other
words: the pointy haired bosses have spoken... ;-)

On Dave's other question: the network is really straightforward; no VLAN's
for example, but yes we are using DHCP, in the hub as well as the remote
locations. (the DC's do DHCP as well). Frankly, I'm not too worried about
the clients, they are pretty standard XP (based on a corporate image) and
we realise; as you mentioned that with some proper project planning and
communication we'll get that done in a weekend job.

Dave's proposed approuch sounds like a good start, what I'm most worried
about however is the complications that we -don't- know about; i.e: what
will happen when we change the DNS's IP? How will changing the static IP
numbers on the DC's impact AD synchronization? What tools are there to check
that? etc.

I like Dana's idea of creating a lab where we might test things.... provided
I can find the time & resources.

Ken; you're quite right, sometimes planning the big picture tends to lead to
overseeing small things like the printers ;-)

Again: thanks for the input!!

Paul
 
Quick Tip: in addition to those who went before me...

Set printers to DHCP - using reserved addresses. You can test this and
start implementing it during business hours on all but the most overworked of
printers. Then set the ports on workstations & servers to point to use a name
of the printer rather than an IP address. This will save heaps of time on the
cutover day.

Hope it helps,

Cheers,
Svend.
 
good tip Svend! thanks!

Paul

Svend said:
Quick Tip: in addition to those who went before me...

Set printers to DHCP - using reserved addresses. You can test this and
start implementing it during business hours on all but the most overworked
of
printers. Then set the ports on workstations & servers to point to use a
name
of the printer rather than an IP address. This will save heaps of time on
the
cutover day.

Hope it helps,

Cheers,
Svend.
Click to expand...
 
Back
Top