AD Replication: What Does "Fully Routed" Mean?

[Douglas H. Quebbeman]

I'm having trouble with replication, and in the process of trying to fix
it, I'm breaking it worse.

Without starting at the beginning, let's jump into the middle.. I'm getting
Event ID 1311, and
that after deleting my site links and checking "Bridge All Sites".

My sites _are_ fully routable the way I'd define it: I'm using RRAS & VPN
tunnels to connect
the sites, with static routing tables on each server that allows each server
to have IP connectivity
to every other server. I've verified that I can ping all the servers from
each servers.

So, w/r/t Active Directory replication, does "fully routed" mean something
different from what
I've got?

My enterprise has three sites, three subnets, three domains, each in
one-to-one correspondance.
The southernmost site was running Windows 2000 Server, but we've
transitioned it to a Win2k3
Server. The old server has been demoted after moving it out of the southern
site and to our HQ;
I realized only after it arrived here that I should have demoted it while it
was still in place.

Still, I seem to have gotten it demoted. So now, there is one domain
controller in each site, except
here at HQ, we are adding a new domain controller.

I can supply output from dcdiag, netdiag, dnslint, etc... thanks in advance
for any & all help,

-doug q

 

[Herb Martin]

I'm having trouble with replication, and in the process of trying to fix
it, I'm breaking it worse.

Without starting at the beginning, let's jump into the middle.. I'm getting
Event ID 1311, and
that after deleting my site links and checking "Bridge All Sites".

Bridge all sites and creating site links are NOT comparable.

You need to both create (enough) site links and (in general)
leave the Bridge all sites checked (the default.)

Without Site Links -- no replication (to that site.)

My sites _are_ fully routable the way I'd define it: I'm using RRAS & VPN
tunnels to connect
the sites, with static routing tables on each server that allows each server
to have IP connectivity
to every other server. I've verified that I can ping all the servers from
each servers.

That's a good sign -- and of course you must pass
the actual traffic (not just ICMP for ping.)

Ok, put back the Site Links to (roughly) correspond to
the WAN links. Use a cost roughly inverse to the speed
of the line (or high if you wish to discourage that path),
e.g.,
T3 = 3
T1 = 1
ISDN = 1000
Dial = 2000

But note, if you had a permanent ISDN and a another demand
dial ISDN you might well mark the second one 1500, 2000 or
even higher.

The idea is to DESCRIBE the underlying WAN to the KCC
so that it will calculate the best replication partners/paths.

So, w/r/t Active Directory replication, does "fully routed" mean something
different from what
I've got?

Well, technically you have to make sure the DCs can
pass their own traffic, not just ping.

Are you firewalling any of these (with selective port/protocol
filters)? Or are the DCs open to each other?

If the latter, the ping is probably good enough as a test for now.

My enterprise has three sites, three subnets, three domains, each in
one-to-one correspondance.

Likely you biggest problem (once you create the sites)
will be DNS (most replication issues are really DNS
issues once the underlying infracture IP/sites etc. are
setup.)

The southernmost site was running Windows 2000 Server, but we've
transitioned it to a Win2k3
Server. The old server has been demoted after moving it out of the southern
site and to our HQ;
I realized only after it arrived here that I should have demoted it while it
was still in place.

Yes, and you will get errors for that until you use NTDSUtil
to remove it (but they are generally benign errors so this can
wait probably until you fix the other stuff), later you can Google:

[ ntdsutil "metadata cleanup" remove domain dc ]

Still, I seem to have gotten it demoted. So now, there is one domain
controller in each site, except
here at HQ, we are adding a new domain controller.

What about single master roles? The 2 Forest wide roles
and the 3 (EACH) domain specific roles?

What about GCs? Do you have at least one (or more) GCs
per site?

I can supply output from dcdiag, netdiag, dnslint, etc... thanks in advance
for any & all help,

Let's do the obvious, then run the DCDiag.

DNS for AD
1) Dynamic for the zone supporting AD
2) All internal DNS clients NIC\IP properties must specify SOLELY
that internal, dynamic DNS server (set.)
3) DCs and even DNS servers are DNS clients too -- see #2

Restart NetLogon on any DC if you change any of the above that
affects a DC and/or use:

nltest /dsregdns /serverC-ServerNameGoesHere

Ensure that DNS zones/domains are fully replicated to all DNS
servers for that (internal) zone/domain.

Also useful may be running DCDiag on each DC, sending the
output to a text file, and searching for FAIL, ERROR, WARN.

Single Lable domain zone names are a problem Google:
[ "SINGLE LABEL" domain names DNS 2000 | 2003 microsoft: ]

 

[Douglas H. Quebbeman]

In

message


Bridge all sites and creating site links are NOT comparable.

You need to both create (enough) site links and (in general)
leave the Bridge all sites checked (the default.)

Without Site Links -- no replication (to that site.)

Ok... in trying to solve other problems (postings coming soon), I hoped that
simplifying the configuration (as much as possible) would be a good start.

That's a good sign -- and of course you must pass
the actual traffic (not just ICMP for ping.)

I'm not doing any packet filtering on the RRAS links... all traffic should
be passing from one site to another.

Ok, put back the Site Links to (roughly) correspond to
the WAN links. Use a cost roughly inverse to the speed
of the line (or high if you wish to discourage that path),
e.g.,
T3 = 3
T1 = 1
ISDN = 1000
Dial = 2000

But note, if you had a permanent ISDN and a another demand
dial ISDN you might well mark the second one 1500, 2000 or
even higher.

The idea is to DESCRIBE the underlying WAN to the KCC
so that it will calculate the best replication partners/paths.

As small as we are, I'd never messed with routing costs... but it
sounds like a good idea anyway.

Well, technically you have to make sure the DCs can
pass their own traffic, not just ping.

Are you firewalling any of these (with selective port/protocol
filters)? Or are the DCs open to each other?

No filtering; the VPN/PPTP tunnels are there to move traffic
through the firewall, all ports are open in the tunnel, but closed
outside the tunnel (except for standard systems services like SMTP).

If the latter, the ping is probably good enough as a test for now.


Likely you biggest problem (once you create the sites)
will be DNS (most replication issues are really DNS
issues once the underlying infracture IP/sites etc. are
setup.)

My DNS logs are clean, and DNSLint doesn't list any errors when I
run it with /ad /s localhost /v. But I *am* having WINS replication
issues...

The southernmost site was running Windows 2000 Server, but we've
transitioned it to a Win2k3
Server. The old server has been demoted after moving it out of the
southern site and to our HQ;
I realized only after it arrived here that I should have demoted it while
it was still in place.

Yes, and you will get errors for that until you use NTDSUtil
to remove it (but they are generally benign errors so this can
wait probably until you fix the other stuff), later you can Google:

[ ntdsutil "metadata cleanup" remove domain dc ]
Ok...

Still, I seem to have gotten it demoted. So now, there is one domain
controller
in each site, except here at HQ, we are adding a new domain controller.

What about single master roles? The 2 Forest wide roles
and the 3 (EACH) domain specific roles?

What about GCs? Do you have at least one (or more) GCs
per site?

I want GCs in each site, since the WAN links do go down from time to time.
The southernmost site is having problems becoming a GC... that site fails
the
nSecDesc test...

In the HQ, the GC is also the FSMO, and I get some complaints about that,
and it sees the new server and suggests moving the role to it, but again, I
think
I can wait on this.

Let's do the obvious, then run the DCDiag.

DNS for AD
1) Dynamic for the zone supporting AD
2) All internal DNS clients NIC\IP properties must specify SOLELY
that internal, dynamic DNS server (set.)
3) DCs and even DNS servers are DNS clients too -- see #2

I have a NAS unit here, Windows Powered, that's acting as a secondary
DNS server; I have it mapped to my NIC on my WS as secondary, so I
can still browse the web when the main server is down. That seems to violate
#2 in your list above...

Restart NetLogon on any DC if you change any of the above that
affects a DC and/or use:

nltest /dsregdns /serverC-ServerNameGoesHere

Ensure that DNS zones/domains are fully replicated to all DNS
servers for that (internal) zone/domain.

Also useful may be running DCDiag on each DC, sending the
output to a text file, and searching for FAIL, ERROR, WARN.

Yes, we have some issues there. I've run DCDIAG with the switches

/e /c /v /fix

and you can see the output for all 4 servers at:

http://members.iglou.com/dougq/MyActiveDirectoryProblems.html

Single Lable domain zone names are a problem Google:
[ "SINGLE LABEL" domain names DNS 2000 | 2003 microsoft: ]

Although my internal domain names are bogus (not registered), they are
all .COMs...

Thanks,
-dq

 

[Herb Martin]

The idea is to DESCRIBE the underlying WAN to the KCC

As small as we are, I'd never messed with routing costs... but it
sounds like a good idea anyway.

I was not referring to routing costs but rather SiteLink costs,
which you cannot avoid because they default to something.
Make them sensible (previous suggesti

My DNS logs are clean, and DNSLint doesn't list any errors when I
run it with /ad /s localhost /v. But I *am* having WINS replication
issues...

And can all DCs pass a DCDiag test clean?

I realized only after it arrived here that I should have demoted it while
it was still in place.

Yes, and you will get errors for that until you use NTDSUtil
to remove it (but they are generally benign errors so this can
wait probably until you fix the other stuff), later you can Google:

[ ntdsutil "metadata cleanup" remove domain dc ]
Ok...

Still, I seem to have gotten it demoted. So now, there is one domain
controller
in each site, except here at HQ, we are adding a new domain controller.

What about single master roles? The 2 Forest wide roles
and the 3 (EACH) domain specific roles?

What about GCs? Do you have at least one (or more) GCs
per site?

I want GCs in each site, since the WAN links do go down from time to time.
The southernmost site is having problems becoming a GC... that site fails
the
nSecDesc test...

You will have problems, especially in Native modes if you
don't get a GC to every site.

In the HQ, the GC is also the FSMO, and I get some complaints about that,
and it sees the new server and suggests moving the role to it, but again, I
think
I can wait on this.

"the FSMO" indicates a slight misunderstanding.
There is ONE single master role that is recommended
to not be a GC (when you have multiple domains), and
that is the Infrstructure master. The Schema Master/
Domain Naming Master must be a GC.

You can have lots of GCs - at least one per site.

I have a NAS unit here, Windows Powered, that's acting as a secondary
DNS server; I have it mapped to my NIC on my WS as secondary, so I
can still browse the web when the main server is down. That seems to violate
#2 in your list above...

That is incorrect. DNS servers must forward to DNS servers which return
the same answers. DNS Clients assume that ALL DNS server know
the same stuff.

Fix this:

All DNS clients pointed to strictly the internal DNS server
set -- which must resolve ALL of your internal domains.

Remember that DCs, even DNS servers themselves are ALSO
DNS clients.

And then you can use Forwarding to resolve Internet names.

You cannot reliably use two distinct DNS server sets.
Don't try. (It may work just enough to convince you otherwise
since it will give intermittent results.)

Restart NetLogon on any DC if you change any of the above that
affects a DC and/or use:

nltest /dsregdns /serverC-ServerNameGoesHere

Ensure that DNS zones/domains are fully replicated to all DNS
servers for that (internal) zone/domain.

Also useful may be running DCDiag on each DC, sending the
output to a text file, and searching for FAIL, ERROR, WARN.

Yes, we have some issues there. I've run DCDIAG with the switches

/e /c /v /fix

and you can see the output for all 4 servers at:

http://members.iglou.com/dougq/MyActiveDirectoryProblems.html

Single Lable domain zone names are a problem Google:
[ "SINGLE LABEL" domain names DNS 2000 | 2003 microsoft: ]

Although my internal domain names are bogus (not registered), they are
all .COMs...

--
Herb Martin

In

message


Bridge all sites and creating site links are NOT comparable.

You need to both create (enough) site links and (in general)
leave the Bridge all sites checked (the default.)

Without Site Links -- no replication (to that site.)

Ok... in trying to solve other problems (postings coming soon), I hoped that
simplifying the configuration (as much as possible) would be a good start.

That's a good sign -- and of course you must pass
the actual traffic (not just ICMP for ping.)

I'm not doing any packet filtering on the RRAS links... all traffic should
be passing from one site to another.

Ok, put back the Site Links to (roughly) correspond to
the WAN links. Use a cost roughly inverse to the speed
of the line (or high if you wish to discourage that path),
e.g.,
T3 = 3
T1 = 1
ISDN = 1000
Dial = 2000

But note, if you had a permanent ISDN and a another demand
dial ISDN you might well mark the second one 1500, 2000 or
even higher.

The idea is to DESCRIBE the underlying WAN to the KCC
so that it will calculate the best replication partners/paths.

As small as we are, I'd never messed with routing costs... but it
sounds like a good idea anyway.

Well, technically you have to make sure the DCs can
pass their own traffic, not just ping.

Are you firewalling any of these (with selective port/protocol
filters)? Or are the DCs open to each other?

No filtering; the VPN/PPTP tunnels are there to move traffic
through the firewall, all ports are open in the tunnel, but closed
outside the tunnel (except for standard systems services like SMTP).

If the latter, the ping is probably good enough as a test for now.


Likely you biggest problem (once you create the sites)
will be DNS (most replication issues are really DNS
issues once the underlying infracture IP/sites etc. are
setup.)

My DNS logs are clean, and DNSLint doesn't list any errors when I
run it with /ad /s localhost /v. But I *am* having WINS replication
issues...

The southernmost site was running Windows 2000 Server, but we've
transitioned it to a Win2k3
Server. The old server has been demoted after moving it out of the
southern site and to our HQ;
I realized only after it arrived here that I should have demoted it while
it was still in place.

Yes, and you will get errors for that until you use NTDSUtil
to remove it (but they are generally benign errors so this can
wait probably until you fix the other stuff), later you can Google:

[ ntdsutil "metadata cleanup" remove domain dc ]
Ok...

Still, I seem to have gotten it demoted. So now, there is one domain
controller
in each site, except here at HQ, we are adding a new domain controller.

What about single master roles? The 2 Forest wide roles
and the 3 (EACH) domain specific roles?

What about GCs? Do you have at least one (or more) GCs
per site?

I want GCs in each site, since the WAN links do go down from time to time.
The southernmost site is having problems becoming a GC... that site fails
the
nSecDesc test...

In the HQ, the GC is also the FSMO, and I get some complaints about that,
and it sees the new server and suggests moving the role to it, but again, I
think
I can wait on this.

Let's do the obvious, then run the DCDiag.

DNS for AD
1) Dynamic for the zone supporting AD
2) All internal DNS clients NIC\IP properties must specify SOLELY
that internal, dynamic DNS server (set.)
3) DCs and even DNS servers are DNS clients too -- see #2

I have a NAS unit here, Windows Powered, that's acting as a secondary
DNS server; I have it mapped to my NIC on my WS as secondary, so I
can still browse the web when the main server is down. That seems to violate
#2 in your list above...

Restart NetLogon on any DC if you change any of the above that
affects a DC and/or use:

nltest /dsregdns /serverC-ServerNameGoesHere

Ensure that DNS zones/domains are fully replicated to all DNS
servers for that (internal) zone/domain.

Also useful may be running DCDiag on each DC, sending the
output to a text file, and searching for FAIL, ERROR, WARN.

Yes, we have some issues there. I've run DCDIAG with the switches

/e /c /v /fix

and you can see the output for all 4 servers at:

http://members.iglou.com/dougq/MyActiveDirectoryProblems.html

Single Lable domain zone names are a problem Google:
[ "SINGLE LABEL" domain names DNS 2000 | 2003 microsoft: ]

Although my internal domain names are bogus (not registered), they are
all .COMs...

Thanks,
-dq

 

[Douglas H. Quebbeman]

In

I was not referring to routing costs but rather SiteLink costs,
which you cannot avoid because they default to something.
Make them sensible (previous suggesti

Since I didn't enter any cost value, I assume I get the defaults...

And can all DCs pass a DCDiag test clean?

No, as shown in those posted DCDiag logs...

You will have problems, especially in Native modes if you
don't get a GC to every site.

I have a legacy NT machine I can't upgrade without breaking the application,
so I've been keeping the enterprise in mixed mode.

"the FSMO" indicates a slight misunderstanding.
There is ONE single master role that is recommended
to not be a GC (when you have multiple domains), and
that is the Infrstructure master. The Schema Master/
Domain Naming Master must be a GC.

You can have lots of GCs - at least one per site.

Indeed, how is it possible for anyone who installs a server
once every three or four years to master this MS Stuff?

Sorry- rhetorical question...

Once I get production moved to the new server, and get a
chance to clean up the old production server, when I redeploy it,
at that time, I can make it be the infrastructure master and not be a GC..

I suppoose I could split them now, too, and just reverse roles later,
but I don't want to make more work for myself than neeed be...

That is incorrect. DNS servers must forward to DNS servers which return
the same answers. DNS Clients assume that ALL DNS server know
the same stuff.

Fix this:

All DNS clients pointed to strictly the internal DNS server
set -- which must resolve ALL of your internal domains.

Remember that DCs, even DNS servers themselves are ALSO
DNS clients.

None my servers point to this alternate, non-AD-integrated DNS server-
just a couple of my workstations....

And then you can use Forwarding to resolve Internet names.

Yes, the AD-integrated DNS server at each site uses forwarding to resolve
Internet names...

You cannot reliably use two distinct DNS server sets.
Don't try. (It may work just enough to convince you otherwise
since it will give intermittent results.)

Since you used the term 'set' twice, and I don't recall encountering
the use of the term "DNS Server sets" in the resource kit books,
could you briefly explain?

And I'm still unclear as to what needs to be fixed...

Thanks,
-dq

 

[Herb Martin]

I was not referring to routing costs but rather SiteLink costs,

Since I didn't enter any cost value, I assume I get the defaults...

Yes, and all are equal, even if that means treating
a T3 as just as good as an ISDN.

You are describing you WAN network to the KCC
when you create site links and give them a cost.

You are directing the KCC when and how often to
replicate over that link by giving a Schedule and
a Frequency.

No, as shown in those posted DCDiag logs...

I will take a look, but generally it's going to be DNS.

I have a legacy NT machine I can't upgrade without breaking the application,
so I've been keeping the enterprise in mixed mode.

You probably still need the GCs per site, it just isn't
as fatal (critical) if you don't.

Indeed, how is it possible for anyone who installs a server
once every three or four years to master this MS Stuff?

Sorry- rhetorical question...

Once I get production moved to the new server, and get a
chance to clean up the old production server, when I redeploy it,
at that time, I can make it be the infrastructure master and not be a GC..

I suppoose I could split them now, too, and just reverse roles later,
but I don't want to make more work for myself than neeed be...


None my servers point to this alternate, non-AD-integrated DNS server-
just a couple of my workstations....

Neither should any of your clients.

Yes, the AD-integrated DNS server at each site uses forwarding to resolve
Internet names...

The point being not to mix internal and external DNS servers
in such settings.

Internal only in the client settings, external only in the Forwarding
settings (if you resolve the Internet and are not using the more
flexible Win2003 conditional forwarding.)

Since you used the term 'set' twice, and I don't recall encountering
the use of the term "DNS Server sets" in the resource kit books,
could you briefly explain?

It's not commonly used because most of the books don't go
into this level of practical advice or troubleshooting.

It is not a technical term but purposely chosen to mean
all those DNS servers that can fully resolve INTERNAL
name (when we say "internal DNS server set") no matter
which zones they hold, or even if they hold no zones.

For many people this server set holds only the SINGLE
internal domain/zone name but those people who have
multiple zones will have different definitions of what is
and is not in the "internal DNS server set."

The point being, an internal client must use strictly (internal)
DNS server(s) which can resolve ALL internal names.

I refer to that set of servers as the internal "DNS server set".

And I'm still unclear as to what needs to be fixed...

I don't see the DCDiag but you need to resolve all the WARN,
ERROR, and FAIL messages.

 

[Douglas H. Quebbeman]

In

Neither should any of your clients.

This is a great learning experience. I'm trying to imagine how having my
workstation
pointing to two DNS servers could cause problems for Active Directory.

Or, does it only cause problems for the user (me) ? It sure solves them:
when I
have the server down for maintenance, as it stands now, I can't resolve
Internet
names without having the second DNS server in my NIC's config, UNLESS I
make the change back and forth every time I have to take the server down.

The point being not to mix internal and external DNS servers
in such settings.

Internal and external? The only references that exist to any external DNS
servers
are in the forwarders fields in the Win2k & Win2k3 DNS Server config...

I probably said something to lead you to think I had my workstation's NIC
pointing
to one internal DNS server and one outside the office. No, I have a NAS
running
Windows Powered, the applicance version of Windows Server, and it's running
the
MS DNS Service, as a secondary, "caching-only" server...

Internal only in the client settings, external only in the Forwarding
settings (if you resolve the Internet and are not using the more
flexible Win2003 conditional forwarding.)

To confirm, yes indeed, in each and every NIC configuration, I am pointing
ONLY to internal DNS servers. On a few workstations, such as mine, I'm
pointing to 2 internal servers, but most workstations point only to one.

It's not commonly used because most of the books don't go
into this level of practical advice or troubleshooting.

It is not a technical term but purposely chosen to mean
all those DNS servers that can fully resolve INTERNAL
name (when we say "internal DNS server set") no matter
which zones they hold, or even if they hold no zones.

For many people this server set holds only the SINGLE
internal domain/zone name but those people who have
multiple zones will have different definitions of what is
and is not in the "internal DNS server set."

The point being, an internal client must use strictly (internal)
DNS server(s) which can resolve ALL internal names.

I refer to that set of servers as the internal "DNS server set".

I don't see the DCDiag but you need to resolve all the WARN,
ERROR, and FAIL messages.

I posted the output from four invocations of DCDiag in my web storage
area; each DCDIAG.TXT file was the result of running

DCDIAG /E /C /FIX /V

on each of my 4 domain controllers, and the links the to four log files
can be found on this page:

http://members.iglou.com/dougq/MyActiveDirectoryProblems.html

I am posting these DCDiags precisely because I require assistance in
resolving the various warnings and errors... and I really appreciate all
the help I can get!

Regards,
-doug q

 

[Herb Martin]

None my servers point to this alternate, non-AD-integrated DNS server-

This is a great learning experience. I'm trying to imagine how having my
workstation
pointing to two DNS servers could cause problems for Active Directory.

It won't (don't smoke your brain <grin>). It will cause
problems for THAT client authenticating and for things
like your own resource and admin access.

Pointing it correctly will maintain all of the above
(authentication and privileges) while STILL allowing
you to resolve (and use) the Internet.

Or, does it only cause problems for the user (me) ? It sure solves them:
when I
have the server down for maintenance, as it stands now, I can't resolve
Internet
names without having the second DNS server in my NIC's config, UNLESS I
make the change back and forth every time I have to take the server down.

You should have two servers and really should never bring
them both down together.

During such a time (if they must be down) you should consciously
change your workstation and then change it back.

There is no guaratee the other way and it should not
be depended up.

Internal and external?

Point your clients at ONLY servers which can fully
resolve the internal names.

By external, I mean any DNS server than cannot resolve
those internal names.

The only references that exist to any external DNS
servers
are in the forwarders fields in the Win2k & Win2k3 DNS Server config...

And they should not reference internal (in almost all cases)
so that is NOT a mix.

I probably said something to lead you to think I had my workstation's NIC
pointing
to one internal DNS server and one outside the office. No, I have a NAS
running
Windows Powered, the applicance version of Windows Server, and it's running
the
MS DNS Service, as a secondary, "caching-only" server...

It is it doing (only) external name resolution then it
is NOT a member of the internal set of DNS servers (despite
it's physical location.)

It's purpose sounds like EXTERNAL (i.e., Internet) resolution.
It should only be referenced in the DNS forwarders entries.

To confirm, yes indeed, in each and every NIC configuration, I am pointing
ONLY to internal DNS servers. On a few workstations, such as mine, I'm
pointing to 2 internal servers, but most workstations point only to one.

It's unreliable. It will not always autocorrect and
reconfigure when the internal DNS goes off line
and returns.

I posted the output from four invocations of DCDiag in my web storage
area; each DCDIAG.TXT file was the result of running

DCDIAG /E /C /FIX /V

Generally, DCDiag is fine (as long as you run it on each server.)

Fix is nice, but it won't fix everything so I run it once, then
run it again to see what errors remain.

on each of my 4 domain controllers, and the links the to four log files
can be found on this page:

http://members.iglou.com/dougq/MyActiveDirectoryProblems.html

I am posting these DCDiags precisely because I require assistance in
resolving the various warnings and errors... and I really appreciate all
the help I can get!

Try RepAdmin and ReplMon for checking your replication.

How do DNS servers from each domain resolve the DNS of
the "other domain" ?

Does each hold cross secondaries for the other or what?

Regards,
-doug q

 

[Douglas H. Quebbeman]

In

Try RepAdmin and ReplMon for checking your replication.
Ok...

How do DNS servers from each domain resolve the DNS of
the "other domain" ?

Does each hold cross secondaries for the other or what?

Each domain has a DNS server that has a forward lookup zone,
and is authoritative for that domain. Then, each DNS server also
has a forward lookup zone for the other two domains. And yes,
they are 'standard secndaries'.

Each DNS server also has a reverse lookup zone covering the
subnet for its corresponding site. No cross-secondaries here...

Regards,
-dq

 

[Douglas H. Quebbeman]

In

Try RepAdmin and ReplMon for checking your replication.

Here's what I got:

**************************************************************
REPADMIN /showreps DC=hqdom,DC=com
**************************************************************

HQ_Site\old_hq_server
DSA Options : IS_GC
objectGuid : aeb5ba3a-9fc0-4f10-ab33-d4842fb8a2c6
invocationID: 23d01027-ddaf-4e70-92a2-bd8a4481bae8

==== INBOUND NEIGHBORS ======================================

DC=hqdom,DC=com
HQ_Site\new_hq_server via RPC
objectGuid: 0ca6fbde-d311-47ef-af23-d04e37da0c3f
Last attempt @ 2005-01-19 16:52.16 was successful.

==== OUTBOUND NEIGHBORS FOR CHANGE NOTIFICATIONS ============

DC=hqdom,DC=com
HQ_Site\new_hq_server via RPC
objectGuid: 0ca6fbde-d311-47ef-af23-d04e37da0c3f


**************************************************************
REPADMIN /showreps DC=southdom,DC=com
**************************************************************

HQ_Site\old_hq_server
DSA Options : IS_GC
objectGuid : aeb5ba3a-9fc0-4f10-ab33-d4842fb8a2c6
invocationID: 23d01027-ddaf-4e70-92a2-bd8a4481bae8

==== INBOUND NEIGHBORS ======================================

DC=southdom,DC=com
HQ_Site\OLD_SOUTH_SERVER
DEL:ba447c07-2878-4b98-a285-b6a5ef141ade (deleted DSA) via RPC
objectGuid: e90e38ad-ad3b-41ba-b713-bdb08722b399
West_Site\west_server via RPC
objectGuid: d19e0173-1d3e-4964-a003-3cbfaae9b898
Last attempt @ 2005-01-19 16:39.03 was successful.
South_Site\south_server2k3 via RPC
objectGuid: ecbb97fa-2aed-4a7c-bc8f-197d6ccc7c5b
Last attempt @ 2005-01-19 16:39.03 was successful.

==== OUTBOUND NEIGHBORS FOR CHANGE NOTIFICATIONS ============


**************************************************************
REPADMIN /showreps DC=westdom,DC=com
**************************************************************

HQ_Site\old_hq_server
DSA Options : IS_GC
objectGuid : aeb5ba3a-9fc0-4f10-ab33-d4842fb8a2c6
invocationID: 23d01027-ddaf-4e70-92a2-bd8a4481bae8

DsReplicaGetInfo failed with status 8440 (0x20f8):
The naming context specified for this replication operation is invalid.


And I knew the problems were pointing 'westward'...

-dq