Moving a DC to a new network

[DLAS]

Hi,

 

I've been given the job of moving a Windows 2003 DC to a new physical location (different building) and hence, a different network. The server is the DC and provides DNS for the network. It provides no other critical services to the network.

 

What's the best way of moving it?

 

Can I just move it, re-IP it, change the DNS records to match the new address, then point all our network devices to the new address to use as DNS? then I'm done?

 

This is the first time I will have undertaken a big move like this and would like it to go smoothly!

 

Thanks

[Michael]

Is it going to part of the same domain, separate domains or child domain for example?

 

Are the buildings linked via fibre?

[K.C.Leblanc]

Is it your only DC?

[DLAS]

I wish they were linked by fibre!!! It's just a VPN linking them at the moment, it will still be a part of the same domain.

 

...and yes, it's our only DC for this domain. An hour or so downtime is acceptable during the day today.

Edited April 30, 2012 by DLAS

[Michael]

So when you remove the server from Site A to Site B, will there be any server in Site A?

 

Ideally you should have DCs in each physical building, so in the event the VPN link goes down, both sites can continue working with only critical information travelling up and down the VPN link.

[DLAS]

There won't be a server in Site A after the move. The buildings are both on fixed circuits so hopefully the VPN should be reliable enough to last a couple of weeks until we get the clearance to install a fibre link between the 2 buildings. It's been up and running already with no interruptions for the last month or so. Unfortunately we just don't have the in house hardware to create and setup another DC right now...

 

Appreciate this is far from ideal but at the minute I don't have much choice as the network it's sat on is soon to be removed so any advice would be hugely appreciated.

 

Thanks

 

 

EDIT:

 

From doing some reading today, my current plan would be:

 

Move server to new building

Re-IP the server

run ipconfig /registerdns on the server

run dcdiag to check for any errors

change the IP on all of our network equipment that needs DNS to point to the new IP address

Edited April 30, 2012 by DLAS

[Michael]

So when the server's in Site B, what do users in Site A require? Will they be logging on with roaming profiles, mapped drives, deployed printers etc etc... it could potentially add a big strain on that single VPN link, although if it's only for weeks, you should be OK.

 

Ideally (even with a fibre link) you should budget for a physical DC at each site. With 2008/2008 R2, you can even have RODC (Read Only Domain Controllers), which is useful as users can authenticate, but no one can mess or change anything critical with the server.

[DLAS]

Ok, thanks Michael.

 

I may be able to get an old W2K3 server to use as an additional DC at the other site (I'll have to clear some crap off it first) and promote that until the network is fully defunct and we no longer need it. Are there any resources you'd recommend reading before I go ahead? It's something I've never done before but a quick google makes it look like it's pretty easy.

 

Site A already has a print server and file server, as you say the profiles could be the biggest strain.

[Michael]

- Install a new installation of Windows Server 2003 SP2

- Add to the domain, then promote to a DC

- I'd recommend adding DHCP Server, File and Print server roles

 

This would mean users can access as much information as they need locally instead of down the VPN link. The only thing going down the link should be internet traffic (optional), and servers replicating critical domain information. If the link goes down, then in theory everyone could carry on working whilst you get the VPN link back online.

[DLAS]

What consequences are there from not promoting from a fresh install?

[Michael]

What consequences are there from not promoting from a fresh install?

 

Instability for one, or out-of-date software components. If you install as new and patch, you know exactly what's installed.

[DLAS]

Ok, thanks Michael, you've been a big help.

[Michael]

You're most welcome Good luck!

[DLAS]

Ah, in fact I have 1 more question:

 

How do client computers decide which DC to authenticate to? Is it calculated in the least number of hops or something similar?

 

I've just performed a clean install on an old server, joined it to the domain and promoted it to a DC (which all went smoothly). I just want to be sure it's all working as intended now.

[K.C.Leblanc]

What consequences are there from not promoting from a fresh install?

 

When you promote a server all the local accounts disappear. On an established server it's more likely there's something running that's dependent on a local account.

[Michael]

Ah, in fact I have 1 more question:

 

How do client computers decide which DC to authenticate to? Is it calculated in the least number of hops or something similar?

 

I've just performed a clean install on an old server, joined it to the domain and promoted it to a DC (which all went smoothly). I just want to be sure it's all working as intended now.

 

When you setup DHCP server (on both servers), you must enable Conflict Detection and set this to 1.

 

In this example, Site A server is 192.168.1.1 and Site B server is 192.168.1.2.

 

In the list of DNS servers in DHCP server for Site A, specify 192.168.1.1, 192.168.1.2 then any external DNS.

 

For Site B specify 192.168.1.2, 192.168.1.1 then any external DNS.

[Michael]

It should also be mentioned, when you configure a static IP on both servers, it should always point to itself first. As above, copy the same method used in DHCP server.

 

This means the servers can still 'talk' but in the event the link goes down, everything will continue working as normal. Typically users can still logon, but depending on where the shares are hosted, they may or may not be able to access these, but I hope you get the general idea

[DLAS]

Only just seen your further posts - thanks Michael.

 

That's exactly how we've set it up and it works perfectly!

[DLAS]

Looks like I spoke too soon.

 

If I take the VPN link between the buildings down then the new DC at Site B won't authenticate users. It seems to work fine for DNS though - if I used NSlookup with Site B set as the DNS server on a client then I can resolve both internal and external hostnames to an IP.

 

If I try and RDP into the new DC at Site B when the VPN link is down then I get a

 

"The system cannot log you on due to the following error: the specified domain does either not exist or could not be contacted"

 

So at the minute users can only authenticate when the VPN link is up - should that be expected? When the link is up there's huge traffic going down the VPN from Site A that's slowing the connection at Site A. How much would you expect to be pushed down the VPN link with a physical DC at each site? It's almost like the DC at site A is still doing all the work.

 

Any ideas?

 

Thanks

Edited May 8, 2012 by DLAS

[Michael]

Server B's own static IP should be set to itself first, (in the DNS list) then to Server A's and then any external DNS as I mentioned here

[DLAS]

Hi Michael - that's exactly as we have it setup.

 

Dcdiag has just thrown up some errors we can look into though with the netlogon share.

[Michael]

Re-enable the VPN link, then on Server B, open up Active Directory Sites and Services and make sure Global Catalog is ticked.

 

Then open DNS in turn on both Server A and Server B and make sure Zone Transfers are enabled on both Forward and Reverse Lookup Zones.

 

Make sure the servers are replicating, then attempt to take the link offline again.

[DLAS]

I missed the global catalog setting, that's fixed it.

 

Cheers again Michael.

[Michael]

You're welcome, glad it's all sorted! Happy days!

[DLAS]

So, you're probably sick of me at this point but...

 

What would cause the DC at Site A to put a huge amount of traffic down the VPN to site B?

 

We've noticed that the performance at Site A is diminished due to the VPN stealing the bandwidth of the connection at that site. I'm certain it's the domain controller at Site A that's the problem because as soon as I block it from the network, then the VPN traffic is reduced to nearly nothing and the connection is back to performing perfectly. Then as soon as I re-allow the DC at Site A back to the network, it over taxes the VPN and cripples performance at that site.

 

I've grabbed a Wireshark capture that I ran on the DC at site A but interpreting it is a different story. It seems there's alot of traffic being pushed out to a specific machine at Site B. This machine is just a normal client PC with nothing unusual about it...

 

This one has me puzzled. Have you ever seen anything like that before?

 

Thanks