When you setup DHCP server (on both servers), you must enable Conflict Detection and set this to 1.
Originally Posted by DLAS
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.
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 :)
Only just seen your further posts - thanks Michael.
That's exactly how we've set it up and it works perfectly!
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.
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
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.
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.
I missed the global catalog setting, that's fixed it.
Cheers again Michael.
You're welcome, glad it's all sorted! Happy days! :D
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?
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.
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.
@Davit2005 - That's perfectly normal what you've described.
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.
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.