Moving a DC to a new network

[Michael]

Depends what you class as 'huge', but possibly roaming profiles, print jobs, internet traffic.

 

I suppose you should investigate what the user on this PC is doing in Site B.

[Davit2005]

On a related note, if you have 2 DC's, both Global Catalogs, DNS servers etc. does it cause problems if you have both DNS servers set as Primary and AD Integrated. And if you do should you have DC1/DNS LAN Primary DNS IP set to itself and secondary dns server IP set to the other DC/DNS and vice versa on the other DC/DNS.

 

Both DC's are on the same site/LAN.

[Michael]

@Davit2005 - That's perfectly normal what you've described.

[DLAS]

There shouldn't be any print jobs going through the VPN - each site has it's own print server.

 

Site B has an OU in group policy that prevents the use of roaming profiles for now.

 

Ideally the only sort of communication we want down the link (as you've said earlier) is between the Domain Controllers.

 

As for the machine that was the destination for alot of traffic, there isn't anything odd about it or how it's being used at all. The majority of the traffic going down the link was from the Site A DC and was SMB protocol.

Edited May 10, 2012 by DLAS

[otsiletirelo]

if its a dc then it means after assigning it the ip address of the new building you have to join the existing computers to its domain.otherwise it wont work.

[Davit2005]

Hi All,

At the moment we have one 2003 DC/DNS (holding the FSMO master roles) and a second DC/DNS running 2008 R2. From what I remember when I had them both set as Primary DNS servers (AD integrated) when browsing the 2003 DNS console it seemed to be missing some functionality. Is this possibly due to 2008 not communicating to 2003 properly, maybe some extra security blocking the comunication?

 

Over summer I will be introducing another 2008 R2 as a DC/DNS and moving the roles accross and hopefully demoting the 2003 DC/DNS.

 

I'll transfer this to a new post if need be ;-D

Edited May 10, 2012 by Davit2005

[Michael]

Traffic between DCs is very light on resources, so it won't be that. Does internet traffic go down the VPN link or does each site have it's own internet connection?

 

if its a dc then it means after assigning it the ip address of the new building you have to join the existing computers to its domain.otherwise it wont work.

 

Everything is all on the same domain, so this won't be the problem. DHCP server has also been configured correctly at both ends too. This keeps traffic needed to go over the link to a minimum, so it must be something else.

 

What about users copying files from one site to the other?

[Michael]

Hi All,

At the moment we have one 2003 DC/DNS (holding the FSMO master roles) and a second DC/DNS running 2008 R2. From what I remember when I had them both set as Primary DNS servers (AD integrated) when browsing the 2003 DNS console it seemed to be missing some functionality. Is this possibly due to 2008 not communicating to 2003 properly, maybe some extra security blocking the comunication?

 

Over summer I will be introducing another 2008 R2 as a DC/DNS and moving the roles accross and hopefully demoting the 2003 DC/DNS.

 

I'll transfer this to a new post if need be ;-D

 

Yep I would start a new thread. It sounds to me your servers are not replicating properly, that's all.

[DLAS]

Traffic between DCs is very light on resources, so it won't be that. Does internet traffic go down the VPN link or does each site have it's own internet connection?

 

Everything is all on the same domain, so this won't be the problem. DHCP server has also been configured correctly at both ends too. This keeps traffic needed to go over the link to a minimum, so it must be something else.

 

What about users copying files from one site to the other?

 

Each site has it's own Internet connection, so I wouldn't expect it to be internet traffic. I'm absolutely convinced it's related to the DC at Site A in some way due to the fact that when I 'block' it from the network (Using a feature on the router) then the traffic over the VPN is basically non existent. The minute I 'allow' it back on to the network the traffic down the VPN tunnel increases dramatically and the connection at Site A becomes more or less unusable.

 

It's all 1 way as well, so looking at the VPN from Site A's router shows all the data is being transmitted from Site A, whereas it's barely receiving anything from Site B.

 

I just can't see what would be causing it... absolutely stumped.

 

As I said, Wireshark shows the majority of the traffic to be SMB protocol, but there are other protocols that the DC is sending, like SPOOLSS and DCERPC.

[Michael]

When you allow Server A to connect, does its CPU use on Task Manager go up too?

[DLAS]

There's no particularly noticeable increase in resource consumption at all on Server A - the CPU is sitting constantly around 5-10% as the server isn't used for too much these days. When the VPN was established there was no constant increase.

 

By the way - thanks for your continued help with this!

Edited May 10, 2012 by DLAS

[Michael]

It's no problem, but I am just as curious as you are what's creating all this mysterious traffic!

[Arthur]

It should also be mentioned, when you configure a static IP on both servers, it should always point to itself first.

I thought that recommendation had changed with newer Microsoft server OSs?

 

Under 2003 it used to be, set the primary to itself and then set the secondary and tertiary to be two other DC's, usually the same for all others.

 

In our last couple ADRAP's the best practice has changed to set the primary and secondary DNS to be the same servers for everyone, and then set the tertiary DNS server to be the local DC's IP or 127.0.0.1 (we use 127.0.0.1, but that will cause dcdiag.exe to report failures when it does DNS tests, even though DNS functionally will work fine in this config) - so essentially the reverse of the 2003 best practices.

 

By no means is that a hard and fast rule, but if you have a large number of DC's in your environment (like we do) it does ensure DC SRV records are always updated on the same server which minimizes replication conflicts. Keeping localhost or the local IP as the third entry ensures DNS stays functional in the event network connectivity to the primary and secondary DC's is lost. (Source)

[DLAS]

Now we're well after hours I've been in a position where rather than removing the server from the network, I've been able to remove all the clients from Site B.

 

Without any clients at Site B the VPN is also very low on badnwidth usage, and the connection at Site A works perfectly.

 

So it's definitely some communication from Server A to Site B client PC's because the problem goes away when either -

 

*Server A is removed from the network* or *all clients are removed from the network*

 

I suppose this test at least rules out any communication issues between Server A and other networking equipment - routers, switches etc...

 

Now just to figure out exactly what it's sending to the client machines via VPN... I'm going to do a pretty lengthy mid-day packet capture from the server tomorrow to get a better idea of what is being communicated. Hopefully that will help.

[Michael]

The problem I see (if you set it that way) is if a DNS server becomes offline, you're quickly going to get errors and potentially users unable to logon.

 

Setting a DC to itself first, then any secondary DC means that servers can potentially work separately for days (for example) until you restored the link.

 

I've had it happen where a link between two 2008 DCs have gone down and it created no problems. The servers continued to serve requests so I know how I set things up works

[DLAS]

It's no problem, but I am just as curious as you are what's creating all this mysterious traffic!

 

 

It was WSUS!

[Michael]

 

It was WSUS!

 

Great find, I never thought of that at all. It should be simple enough to fix so certain clients talk to the right WSUS server.

 

The easiest way would be to use Server A as the parent, so it feeds updates to Server B once (overnight) and this should help with bandwidth.

[DLAS]

That's pretty much what we've done. Cheers!

 

Everything is ticking along nicely now on the domain.

[Michael]

Good job