DC Replication Issue

R

Ryan

Hi all,

After promoting an additional DC, I started to have Directory Service
Replication issue (including FRS). Initially, I have 3 DCs in single domain
with the PDC holding all the FSMO roles. When I access AD Sites and Servies
and click on each server, I can only see other 2 DC appearing on each server
(which should have been 3). Server1 can only see Server2 and Server4
(replication successful on bothe servers as well). Server2 can only see
Server1 and Server3. Server3 can see Server2 and Server4. Server4 can only
see Server1 and Server3. Conclusion: Server1 can't "communicate" with
Server3 (and vice versa) while Server2 can't communicate with Server4 (and
vice versa). I have run dnslint and the result successfully captured the 4
server GUID.

The error log for FRS error is 13508, I have followed the error log to
create a new replication path. I tried to use FRSDIAG but get an error
certain registry not registered, do i need to add-in any component for the
tool to run? A new replicated sripts and policies (both attached with some
ID) folders were created and can be successfully replicated. So, which
folder would be the "effective" sysvol share folder (the one with ID or
original, can I manually remove or rename these folders?)?

I found missing keberos and kpasswd service location of the newly promoted
server in the DNS forward lookup zone. I have manually added them. What is
the impact of adding these entries. It does not solve the problem I faced
though. Any advice would be very much appreciated, thank you.

Ryan
 
M

Mark Renoden [MSFT]

Hi Ryan

It's not necessary for all DC's to have replication going with every other
DC. When the replication topology is set up automatically, it usually forms
a ring (within a site) so what you're describing sounds about right.

Have you left things long enough for things to settle? It might be the case
that data is still being pushed around to accomodate the new DC.

FRS replication depends on AD replication which depends on name resolution
and network connectivity. You might check AD Replication by creating a test
user account on one DC, allowing things to replicate and check that this
account appears on other DC's some time later.

You can test FRS replication by dropping a text file into SYSVOL and
checking where it goes. Again, leave time for replication to occur. It's
often effective to drop a text file on each DC and call them server1.txt,
server2.txt etc. This way you can easily see what's replicating with what.

13508's are only usually a problem if there's no following 13509. It
indicates a temporary lack of communication that might be a DNS or network
issue.

HTH
--
Mark Renoden [MSFT]
Windows Platform Support Team
Email: (e-mail address removed)

Please note you'll need to strip ".online" from my email address to email
me; I'll post a response back to the group.

This posting is provided "AS IS" with no warranties, and confers no rights.
 
R

Ryan

Thanks for the reply. The PDC log error 1373 and 1528 in the directory
services event. The error is pretty much relate to replication error
attempt through SMTP, intra-domain replications should go through RPC. I do
have another trusted domain, maybe that is the problem. I have not tested
on the inter-site connection, how can I go about testing if the 2 sites are
still communicating?

Back to the intra-site replications. I have tried manually adding the link
for each server but the manually added link will not replicate. I've
compared the properties of the manually added link with the ones
automatically generated, the "fully qualified domain name of object" of the
manually added object is the server name instead of the server's GUID. Is
there a way to force the server to be registered? The result I run on
Repadmin shows successful replication on the servers I can see in the AD
sites and services, but not those replications that are "missing". The new
server was promoted for about 5 days and it worries me that each server
still having problem to "see" 1 of the other 3 servers.

Thank you.


Mark Renoden said:
Hi Ryan

It's not necessary for all DC's to have replication going with every other
DC. When the replication topology is set up automatically, it usually
forms a ring (within a site) so what you're describing sounds about right.

Have you left things long enough for things to settle? It might be the
case that data is still being pushed around to accomodate the new DC.

FRS replication depends on AD replication which depends on name resolution
and network connectivity. You might check AD Replication by creating a
test user account on one DC, allowing things to replicate and check that
this account appears on other DC's some time later.

You can test FRS replication by dropping a text file into SYSVOL and
checking where it goes. Again, leave time for replication to occur. It's
often effective to drop a text file on each DC and call them server1.txt,
server2.txt etc. This way you can easily see what's replicating with
what.

13508's are only usually a problem if there's no following 13509. It
indicates a temporary lack of communication that might be a DNS or network
issue.

HTH
--
Mark Renoden [MSFT]
Windows Platform Support Team
Email: (e-mail address removed)

Please note you'll need to strip ".online" from my email address to email
me; I'll post a response back to the group.

This posting is provided "AS IS" with no warranties, and confers no
rights.



Ryan said:
Hi all,

After promoting an additional DC, I started to have Directory Service
Replication issue (including FRS). Initially, I have 3 DCs in single
domain with the PDC holding all the FSMO roles. When I access AD Sites
and Servies and click on each server, I can only see other 2 DC appearing
on each server (which should have been 3). Server1 can only see Server2
and Server4 (replication successful on bothe servers as well). Server2
can only see Server1 and Server3. Server3 can see Server2 and Server4.
Server4 can only see Server1 and Server3. Conclusion: Server1 can't
"communicate" with Server3 (and vice versa) while Server2 can't
communicate with Server4 (and vice versa). I have run dnslint and the
result successfully captured the 4 server GUID.

The error log for FRS error is 13508, I have followed the error log to
create a new replication path. I tried to use FRSDIAG but get an error
certain registry not registered, do i need to add-in any component for
the tool to run? A new replicated sripts and policies (both attached
with some ID) folders were created and can be successfully replicated.
So, which folder would be the "effective" sysvol share folder (the one
with ID or original, can I manually remove or rename these folders?)?

I found missing keberos and kpasswd service location of the newly
promoted server in the DNS forward lookup zone. I have manually added
them. What is the impact of adding these entries. It does not solve the
problem I faced though. Any advice would be very much appreciated, thank
you.

Ryan
 
M

Mark Renoden [MSFT]

Hi Ryan

I haven't found much on the 1373/1528's that you've mentioned. The only
thing I've come up with is that you need some libraries that are part of
Outlook Express. Previous resolution for a Microsoft customer was to
install Outlook Express by reinstalling Internet Explorer from the Internet
Explorer web site.

With respect to your intra-site replication, I'd start by removing the
manually created links and do some testing with temporary user accounts.
For example, on server1, create a user called sv1 and see which servers get
a copy. You can even force replication by right-clicking the connection
objects in Sites and Services and selecting "Replicate now". Pay special
attention to the direction of the objects ... there's a from - to
relationship there. ie you want to replicate from server1 to serverX after
creating a user account on server1.

As I mentioned, the description you provided earlier of the existing
connection objects sounds correct. You've got a ring topology which is
what's expected ...

1 - 2
| |
4 - 3

If an object is created at 1, it'll replicate to 3 via 2 or 4 ... this is
correct.

Kind regards
--
Mark Renoden [MSFT]
Windows Platform Support Team
Email: (e-mail address removed)

Please note you'll need to strip ".online" from my email address to email
me; I'll post a response back to the group.

This posting is provided "AS IS" with no warranties, and confers no rights.


Ryan said:
Thanks for the reply. The PDC log error 1373 and 1528 in the directory
services event. The error is pretty much relate to replication error
attempt through SMTP, intra-domain replications should go through RPC. I
do have another trusted domain, maybe that is the problem. I have not
tested on the inter-site connection, how can I go about testing if the 2
sites are still communicating?

Back to the intra-site replications. I have tried manually adding the
link for each server but the manually added link will not replicate. I've
compared the properties of the manually added link with the ones
automatically generated, the "fully qualified domain name of object" of
the manually added object is the server name instead of the server's GUID.
Is there a way to force the server to be registered? The result I run on
Repadmin shows successful replication on the servers I can see in the AD
sites and services, but not those replications that are "missing". The
new server was promoted for about 5 days and it worries me that each
server still having problem to "see" 1 of the other 3 servers.

Thank you.


Mark Renoden said:
Hi Ryan

It's not necessary for all DC's to have replication going with every
other DC. When the replication topology is set up automatically, it
usually forms a ring (within a site) so what you're describing sounds
about right.

Have you left things long enough for things to settle? It might be the
case that data is still being pushed around to accomodate the new DC.

FRS replication depends on AD replication which depends on name
resolution and network connectivity. You might check AD Replication by
creating a test user account on one DC, allowing things to replicate and
check that this account appears on other DC's some time later.

You can test FRS replication by dropping a text file into SYSVOL and
checking where it goes. Again, leave time for replication to occur.
It's often effective to drop a text file on each DC and call them
server1.txt, server2.txt etc. This way you can easily see what's
replicating with what.

13508's are only usually a problem if there's no following 13509. It
indicates a temporary lack of communication that might be a DNS or
network issue.

HTH
--
Mark Renoden [MSFT]
Windows Platform Support Team
Email: (e-mail address removed)

Please note you'll need to strip ".online" from my email address to email
me; I'll post a response back to the group.

This posting is provided "AS IS" with no warranties, and confers no
rights.



Ryan said:
Hi all,

After promoting an additional DC, I started to have Directory Service
Replication issue (including FRS). Initially, I have 3 DCs in single
domain with the PDC holding all the FSMO roles. When I access AD Sites
and Servies and click on each server, I can only see other 2 DC
appearing on each server (which should have been 3). Server1 can only
see Server2 and Server4 (replication successful on bothe servers as
well). Server2 can only see Server1 and Server3. Server3 can see
Server2 and Server4. Server4 can only see Server1 and Server3.
Conclusion: Server1 can't "communicate" with Server3 (and vice versa)
while Server2 can't communicate with Server4 (and vice versa). I have
run dnslint and the result successfully captured the 4 server GUID.

The error log for FRS error is 13508, I have followed the error log to
create a new replication path. I tried to use FRSDIAG but get an error
certain registry not registered, do i need to add-in any component for
the tool to run? A new replicated sripts and policies (both attached
with some ID) folders were created and can be successfully replicated.
So, which folder would be the "effective" sysvol share folder (the one
with ID or original, can I manually remove or rename these folders?)?

I found missing keberos and kpasswd service location of the newly
promoted server in the DNS forward lookup zone. I have manually added
them. What is the impact of adding these entries. It does not solve
the problem I faced though. Any advice would be very much appreciated,
thank you.

Ryan
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top