From http://support.microsoft.com/default.aspx?scid=kb;en-us;275278&id=kb;en-us;275278 (see
note in method 1 below).
NOTE:
This implementation process may not be suitable if the server that functions as
the primary server is subject to heavy loads or the domain controllers in the
forest root are geographically dispersed.
So the
issue you face is this: Name resolution must continue in the event that the
WAN link fails.
Since
your DC is using an off-site host for DNS, this cannot possibly work.
Unless your DC knows how to find an alternate route through thin air anyway
:)
If you
don't use the same server as itself for DNS resolution replication has occurred,
then when the WAN link goes down, your workstations cannot find the resources
they need to authenticate.
Result? you end up with a down site until the WAN
link comes back.
Your
possible solutions look like this:
Either
put a second DNS in that remote site with the full zone information and let
them use each other for resolution to avoid a possible island issue during
DCPromo events or human error, or put all of the records on the remote DC and
let it become an authentication 'island' in the case that the WAN link goes
down.
As
long as nothing changes during the WAN link outage, specifically the DNS
zone information for DC location, then you should resume normal operations
when the link comes back as long as it's not so long that garbage collection
kicks in (60 days by default).
In
short, islanding is really only a problem when you first create a DC (dcpromo)
or when you make a human mistake and remove the records needed. WAN links
are more of a threat in this case based on the information
posted.
Test,
Test, Test, and then run it through testing to make sure you have the
results you want.
Al
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rimmerman, Russ
Sent: Thursday, October 14, 2004 1:58 PM
To: [EMAIL PROTECTED]
Subject: RE: [ActiveDir] Still troubleshooting, still no resolution
But if primary is itself, what about the old "DNS
islanding" issue?
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mulnick, Al
Sent: Thursday, October 14, 2004 12:15 PM
To: [EMAIL PROTECTED]
Subject: RE: [ActiveDir] Still troubleshooting, still no resolution
Didn't we have this conversation once before?
:)
Think about that. If the remote DC has a replica of
the DNS entries it needs, why is it going across a WAN link? It doesn't
make sense since it already knows how to find everything it
needs.
IMHO, primary should be itself. Secondary?
Not sure it really needs one (check itself and if that fails check someone else
that has the same information?), but you *could* put the remote DNS host
there.
It would be good for you to test this scenario in your lab
before relying on it in the future as well.
Al
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rimmerman, Russ
Sent: Thursday, October 14, 2004 11:47 AM
To: [EMAIL PROTECTED]
Subject: RE: [ActiveDir] Still troubleshooting, still no resolution
Could it be because the domain controller at all our remote
sites has their network adapter properties set to the primary and secondary dns
servers at the headquarters site? How should the dns settings be on a DC
that is running DNS in a remote site? Primary across the wan, secondary to
itself?
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mulnick, Al
Sent: Thursday, October 14, 2004 10:36 AM
To: [EMAIL PROTECTED]
Subject: RE: [ActiveDir] Still troubleshooting, still no resolution
Russ, is server ldap/ccc.ourdomain.com your local DC in
that site?
And is this the site name CN=CAM-DHQ of that
site?
