AD Replication errors

[Guest]

I recently inherited a domain in which there was no documentation. In going
over the AD Replication Monitor, I noticed a problem with inter-site
replication. We have a single domain with 3 sites. It appears that
intra-site replication is functioning, however replication between sites is
failing with the following errors:

------------------------------------------------------------------------------------------

Event Type: Error
Event Source: NTDS KCC
Event Category: (1)
Event ID: 1311
Date: 9/4/2004
Time: 6:51:05 AM
User: N/A
Computer: DC-DS1
Description:
The Directory Service consistency checker has determined that either (a)
there is not enough physical connectivity published via the Active Directory
Sites and Services Manager to create a spanning tree connecting all the sites
containing the Partition CN=Configuration,DC=altarum,DC=pri, or (b)
replication cannot be performed with one or more critical servers in order
for changes to propagate across all sites (most often due to the servers
being unreachable).

For (a), please use the Active Directory Sites and Services Manager to do
one of the following:
1. Publish sufficient site connectivity information such that the system can
infer a route by which this Partition can reach this site. This option is
preferred.
2. Add an ntdsConnection object to a Domain Controller that contains the
Partition CN=Configuration,DC=altarum,DC=pri in this site from a Domain
Controller that contains the same Partition in another site.

For (b), please see previous events logged by the NTDS KCC source that
identify the servers that could not be contacted.

----------------------------------------------------------------------------------------------

Event Type: Warning
Event Source: NTDS KCC
Event Category: (1)
Event ID: 1265
Date: 9/4/2004
Time: 6:51:05 AM
User: N/A
Computer: DC-DS1
Description:
The attempt to establish a replication link with parameters

Partition: DC=altarum,DC=pri
Source DSA DN: CN=NTDS
Settings,CN=AA-DS3,CN=Servers,CN=AnnArbor,CN=Sites,CN=Configuration,DC=altarum,DC=pri
Source DSA Address: 48b860a6-2891-4d95-a2ae-83f13bceb6fb._msdcs.altarum.pri
Inter-site Transport (if any): CN=IP,CN=Inter-Site
Transports,CN=Sites,CN=Configuration,DC=altarum,DC=pri

failed with the following status:

The DSA operation is unable to proceed because of a DNS lookup failure.

The record data is the status code. This operation will be retried.
Data:
0000: 4c 21 00 00 L!..

---------------------------------------------------------------------------------------

When I attempt to force replication via the AD Replication Monitor, I
receive the following error:

There was an error during queuing the synchronization. The error code was:
ERROR_REPLICA_SYNC_FAILED_THE DSA OPERATION IS UNABLE TO PROCEED BECAUSE OF A
DNS LOOKUP FAILURE.

I have verified both DNS Forward and reverse lookup connectivity and can
reach the replicating domain controllers without any issue.

We did test to see if changes were being replicated and were able to get 1
successful sync 2 days ago, but since then test changes made to the directory
do not appear to be synching.

One side note, this problem may be due to a change made to the DNS server.
Our reverse lookup zones were had multiple stale records, and scavaging was
turned on briefly to test whether we could clean these up.

I am debating doing a restore of the DNS server in effort to repair this
issue, but not being certain that this is really where the problem started, I
have been hesitant to do so.

I need to get inter-site replication up and functional as soon as possible,
and would appreciate any assistance you can give me.

Thanks,
Michelle

 

[Joe Richards [MVP]]

You shouldn't need to restore the DNS Server, simply force registration from the
DC's (ipconfig or restart netlogon) and look in DNS to see if the records get
registered. You can tell what records should be registered by looking at the
netlogon.dns file in the c:\windows\system32\config folder.

joe

 

[Guest]

I have attempted an ipconfig /registerdns from the DCs involved in inter-site
replication and all seemed fine until I get to the aa-ds2. When I attempt to
do an ipconfig /registerdns I receive the following error:

Error: The system cannot find the specified file.
:Refreshing DNS names

Also the netlogon.dns file on aa-dc2 only references aa-dc1. Is this in
error?

I was able to succesfully do a net stop and net start netlogon however.
Should this suffice?

Attempting to force replication via AD replication monitor is still
reporting the DSA error previously mentioned.

Thanks for the speedy response!
Michelle

 

[Joe Richards [MVP]]

Also the netlogon.dns file on aa-dc2 only references aa-dc1. Is this in

error?

Yes and might I say a scary one. There is nothing inherent in a DC that would do
that, someone had to do something on dc2. I would look that machine over very
carefully and if I didn't find what was causing that, would demote it out of the
forest and rebuild from scratch and then repromote. I wonder if someone tried to
ghost a DC or something.

joe

 

[Guest]

Some background info about the network that I thought I should mention prior
to rebuilding dc2. AA-DS1 is a DC on the network. It in fact is the root DC
and is currently holding all FSMO roles. With that in mind, should I still
be concerned about the netlogon.dns file held on aa-dc2?

Michelle

 

[Ace Fekay [MVP]]

In

I have attempted an ipconfig /registerdns from the DCs involved in
inter-site replication and all seemed fine until I get to the aa-ds2.
When I attempt to do an ipconfig /registerdns I receive the following
error:

Error: The system cannot find the specified file.

<snip>

I've seen this error if the DHCP Client service is disabled. We all know of
course, that service is required for DNS resolution and other netowrk
functionality (registration, etc), whether the system is set to static or
DHCP.

264539 - Dynamic DNS Updates (and other functions) Do Not Work if the DHCP
Client Service is not running::
http://support.microsoft.com/default.aspx?scid=kb;EN-US;264539

--
Regards,
Ace

Please direct all replies ONLY to the Microsoft public newsgroups
so all can benefit.

This posting is provided "AS-IS" with no warranties or guarantees
and confers no rights.

Ace Fekay, MCSE 2003 & 2000, MCSA 2003 & 2000, MCSE+I, MCT, MVP
Microsoft Windows MVP - Windows Server - Directory Services

Security Is Like An Onion, It Has Layers
HAM AND EGGS: A day's work for a chicken;
A lifetime commitment for a pig.

 

[Guest]

Restarting the DHCP client service has resolved this error, however I am
still receiving replication errors during intersite replication.

I have run dcdiag and dnslint in hopes of pinpointing the problem and in
both cases I am receiving errors that the GUIDs for the remote servers are
not registered on one or more DNS servers. DNSLint does show the replication
GUIDs present but indicates the following:

------------------------------------------------------------------------------------
CNAME records for forest GUIDs not found:
GUID:015301eb-f7f4-442a-9b4b-141dc92a9cd._msdcs.altarum.pri
DC: TX-DS1

GUID: acef4f79-44ef-40df-8566-ac37023705._msdcs.altarum.pri
DC: DC-DS1

-------------------------------------------------------------------------------------

I've pondered with the idea of recreating site links to see if this will get
replication back up and running, but wasn't sure if this is the way to go or
I should just give up on trying to troubleshoot this and rebuild as Joe
suggested.

Thoughts?
Michelle

 

[Guest]

An update on the situation. As I was having difficulties with my remote
connection to the office I had to come in to reboot our Citrix server. Upon
doing so, and doing a little further investigation with workstations in the
building, it appears that DHCP is also not doling out addresses, although the
server logs do not indicate any distress. I am able to ping the DHCP server
as well as other servers on the network and browse the web. Configuring
workstations with a static IP also will resolve the issue, however when
attempting to use dynamic IPs. Also, when attempting to browse to our main
file server, I am being prompted for login credentials, and no matter what
credentials I supply I receive an error that 'the credentials supplied
conflict with an existing set of credentials'. It appears this problem is
just getting bigger and bigger.

Any input or ideas on where else to look to troubleshoot would be greatly
appreciated.

Thanks!
Michelle

 

[Ace Fekay [MVP]]

In

An update on the situation. As I was having difficulties with my
remote connection to the office I had to come in to reboot our Citrix
server. Upon doing so, and doing a little further investigation with
workstations in the building, it appears that DHCP is also not doling
out addresses, although the server logs do not indicate any distress.
I am able to ping the DHCP server as well as other servers on the
network and browse the web. Configuring workstations with a static
IP also will resolve the issue, however when attempting to use
dynamic IPs. Also, when attempting to browse to our main file
server, I am being prompted for login credentials, and no matter what
credentials I supply I receive an error that 'the credentials
supplied conflict with an existing set of credentials'. It appears
this problem is just getting bigger and bigger.

Any input or ideas on where else to look to troubleshoot would be
greatly appreciated.

Thanks!
Michelle

The conflicting credentials issue either means you have a session open
between your machines, your machine is not part of the domain and the
machine has an identical user/password account. Try supplying the domain
name in front of the username, such as::

domainname\username
password

Michelle, I n eed to ask, since you had the DHCP Client service disabled on
that one machine, is it disabled on other machines? Are there any other
services that you have disabled? We'll need specific config info to better
assist. At this point its a stab in the dark and guessworlk.

What are if any, errors on the DHCP server Event logs? ANy errors at all in
any machines' Event logs?

Please post this from a DCs, and from a client so we can get a better idea
of your configuration (for starters)

1. Unedited ipconfig /all
2 The actual AD DNS domain name
3. The exact spelling of the zone in DNS and if updates are enabled on it.

Thanks

--
Regards,
Ace

Please direct all replies ONLY to the Microsoft public newsgroups
so all can benefit.

This posting is provided "AS-IS" with no warranties or guarantees
and confers no rights.

Ace Fekay, MCSE 2003 & 2000, MCSA 2003 & 2000, MCSE+I, MCT, MVP
Microsoft Windows MVP - Windows Server - Directory Services

Security Is Like An Onion, It Has Layers
HAM AND EGGS: A day's work for a chicken;
A lifetime commitment for a pig.

 

[Guest]

Hi Ace,

Thanks for the response.

After spending a grueling day off in the office today trying to fix this, it
appeared that another admin had put up a linux test server that was running
DHCP server on it and it took over the DHCP on the network. Downing that
system resolved the DHCP issue. Downing all of our DNS servers (we have 3
internal windows servers, 1 internal linux server) and bringing them back up
again seemed to re-establish the connection to our network file server.

So at this point the network is again functional, but intersite replication
still does not appear to be working. All diagnosis that I have run still
seems to point to missing guids for the remote replication partners. Is
there an easy way to re-establish these guids?

Thanks,
Michelle

 

[Guest]

I forgot to answer your questions in the previous post:
1. Ipconfig of the domain controller is as follows:

-------------------------------------------------------------------------------------
Windows 2000 IP Configuration
Host Name . . . . . . . . . . . . : aa-ds2
Primary DNS Suffix . . . . . . . : altarum.pri
Node Type . . . . . . . . . . . . : Broadcast

IP Routing Enabled. . . . . . . . : No

WINS Proxy Enabled. . . . . . . . : No

DNS Suffix Search List. . . . . . : altarum.pri

Ethernet adapter Local Area Connection:

Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : Netelligent 10/100TX PCI UTP Controller
Physical Address. . . . . . . . . : 00-08-C7-CF-8B-1C

DHCP Enabled. . . . . . . . . . . : No

IP Address. . . . . . . . . . . . : 198.108.7.2

Subnet Mask . . . . . . . . . . . : 255.255.255.0

Default Gateway . . . . . . . . . : 198.108.7.1

DNS Servers . . . . . . . . . . . : 198.108.7.
-----------------------------------------------------------------------------------

2. The AD domain name is: altarum.pri

3. The zone in dns is also named altarum.pri and has dynamic updating
enabled (but not secure updates only).

I have confirmed that there are DNS entries for all name servers in the
forest and have run ipconfig /registerdns on the replicating partners just to
be sure. Hopefully this information will be helpful with the replication
problem.

Thanks again for all the help,
Michelle

 

[Ace Fekay [MVP]]

In

I forgot to answer your questions in the previous post:

<snip>


Hi Michelle,

Thanks for posting the info. It actually looks good, and from what you say
all the SRV records under the zone exist, is great!

An admin installed a Linux DHCP? OUCH!!! Hang him from his....

As for replication, go into AD Sites and Services, drill down under your
sites, then servers, and choose a mahcine, then its NTDS settings, rt-click
and choose 'Check Topology". Then on the rt side, you can see the partner
connections that the KCC generated. You can rt-click on one of them, and say
"replicate now". If it comes back with an error, please let me know what it
is.

Btw- I assume rour IP range is a public range and you're aware of that?

Ace

 

[Guest]

Hi Ace,

I've done the check topology via AD sites and services and did not receive
any errors. When forcing replication through this, I do not receive any
errors with the intra-site replication and only received a msg that
replication can't take place immediately due to the rep. partner being in a
different site.

I did remote into the replication partner in DC and created a test account
last week that replicated to the AA office, however, in disabling and then
deleting that account yesterday to test whether replication was still in fact
occurring, it doesn't appear that it is. When using AD replication monitor,
I am still receiving the following error when attempting to force replication
--------------------------------------------------------------------------------------
There was an error during queuing the synchronization. The error code was:
ERROR_REPLICA_SYNC_FAILED_THE DSA OPERATION WAS UNABLE TO PROCEED BECAUSE OF
A DNS LOOKUP FAILUR
--------------------------------------------------------------------------------------

Also deleting this test account from the AA servers has not replicated to
remote sites, which is a definite indication that everything is not quite
working as it should.

Thanks for sticking with me through this, I'm a pretty novice admin, so this
has been one of the toughest errors I've had to troubleshoot. Also, I am
aware that we are using a public address on our network, and changing to a
private addressing system for our internal does not appear to be an option in
my understanding due to web servers and a few other systems running on our
network. We've got a pretty serious firewall in place, and any access to the
outside world is done with a padded address from what I understand. Here's
another lovely tidbit, the previous admin, in her infinite wisdom had not
placed more than one domain controller on the remote sites and has even
placed DHCP on the main domain controller in our DC site, something I
understand is a major no no. Gotta love inheriting networks!

Michelle

 

[Guest]

I've run some additional tests on the servers and here ares some of the
results I've gotten, some I thought helpful, some rather curious.

In running netdiag /v on the serve
---------------------------------------------------------------------------------
TX-DC1:
Testing trust relationships... Failed
PASS - All the DNS entries for DC are registered on DNS server
'204.106.25.15'.
Trust relationship test. . . . . . : Failed
Test to ensure DomainSid of domain 'ALTARUM' is correct.
Secure channel for domain 'ALTARUM' is to '\\aa-ds1.altarum.pri'.
[FATAL] Cannot set secure channel for domain 'ALTARUM' to PDC emulator.
[ERROR_NO_LOGON_SERVERS]
Find PDC emulator in domain 'ALTARUM':
[WARNING] Cannot find PDC emulator in domain 'ALTARUM'.
[ERROR_NO_SUCH_DOMAIN]

DC-DS1:
Testing trust relationships... Failed
PASS - All the DNS entries for DC are registered on DNS server '127.0.0.1'.
Trust relationship test. . . . . . : Failed
Test to ensure DomainSid of domain 'ALTARUM' is correct.
Secure channel for domain 'ALTARUM' is to '\\aa-ds1.altarum.pri'.
[FATAL] Cannot set secure channel for domain 'ALTARUM' to PDC emulator.
[ERROR_NO_LOGON_SERVERS]
Find PDC emulator in domain 'ALTARUM':
[WARNING] Cannot find PDC emulator in domain 'ALTARUM'.
[ERROR_NO_SUCH_DOMAIN]

AA-DS2:
Testing trust relationships... Passed
PASS - All the DNS entries for DC are registered on DNS server '198.108.7.9'
and other DCs also have some of the names registered.
Trust relationship test. . . . . . : Passed
Test to ensure DomainSid of domain 'ALTARUM' is correct.
Secure channel for domain 'ALTARUM' is to '\\aa-ds1.altarum.pri'.
Secure channel for domain 'ALTARUM' was successfully set to PDC emulator
'\\aa-ds1.altarum.pri'.
Find PDC emulator in domain 'ALTARUM':
Found this PDC emulator in domain 'ALTARUM':
DC. . . . . . . . . . . : \\aa-ds1.altarum.pri
Address . . . . . . . . : \\198.108.7.9
Domain Guid . . . . . . : {2F33C2A8-5E95-493A-A035-1C095E3167EA}
Domain Name . . . . . . : altarum.pri
Forest Name . . . . . . : altarum.pri
DC Site Name. . . . . . : AnnArbor
Our Site Name . . . . . : AnnArbor
Flags . . . . . . . . . : PDC emulator GC DS KDC TIMESERV WRITABLE
DNS_DC DNS_DOMAIN DNS_FOREST CLOSE_SITE 0x
------------------------------------------------------------------------------------------------
There were no other pertinent errors in netdiag /v

Next I ran repadmin /showreps on all inter-site rep partners, and here are
the results I've received
-----------------------------------------------------------------------------------------------
TX-DS1:
==== INBOUND NEIGHBORS ======================================

CN=Schema,CN=Configuration,DC=altarum,DC=pri
AnnArbor\AA-DS1 via RPC
objectGuid: 3121f9d2-f5ee-4d22-a1d9-a93ab0b42cd1
Last attempt @ 2004-09-06 12:23.35 failed, result 8524:
The DSA operation is unable to proceed because of a DNS lookup
failure.
Last success @ 2004-09-02 12:23.34.
100 consecutive failure(s).

CN=Configuration,DC=altarum,DC=pri
AnnArbor\AA-DS1 via RPC
objectGuid: 3121f9d2-f5ee-4d22-a1d9-a93ab0b42cd1
Last attempt @ 2004-09-06 12:23.35 failed, result 8524:
The DSA operation is unable to proceed because of a DNS lookup
failure.
Last success @ 2004-09-02 12:23.34.
99 consecutive failure(s).

DC=altarum,DC=pri
AnnArbor\AA-DS1 via RPC
objectGuid: 3121f9d2-f5ee-4d22-a1d9-a93ab0b42cd1
Last attempt @ 2004-09-06 12:23.35 failed, result 8524:
The DSA operation is unable to proceed because of a DNS lookup
failure.
Last success @ 2004-09-02 12:23.34.
99 consecutive failure(s).

DC-DS1:

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

CN=Schema,CN=Configuration,DC=altarum,DC=pri
Texas\TX-DS1 via RPC
objectGuid: 015301eb-f7f4-442a-9b4b-141dcb92a9cd
Last attempt @ 2004-09-06 13:27.15 failed, result 8524:
The DSA operation is unable to proceed because of a DNS lookup
failure.
Last success @ 2004-09-02 13:27.18.
99 consecutive failure(s).
AnnArbor\AA-DS2 via RPC
objectGuid: f0472b6f-e128-4b4d-9f83-b74d930005c0
Last attempt @ 2004-09-06 13:27.15 failed, result 8524:
The DSA operation is unable to proceed because of a DNS lookup
failure.
Last success @ 2004-09-02 13:27.18.
784 consecutive failure(s).

CN=Configuration,DC=altarum,DC=pri
Texas\TX-DS1 via RPC
objectGuid: 015301eb-f7f4-442a-9b4b-141dcb92a9cd
Last attempt @ 2004-09-06 13:27.15 failed, result 8524:
The DSA operation is unable to proceed because of a DNS lookup
failure.
Last success @ 2004-09-02 13:27.18.
98 consecutive failure(s).
AnnArbor\AA-DS2 via RPC
objectGuid: f0472b6f-e128-4b4d-9f83-b74d930005c0
Last attempt @ 2004-09-06 13:27.15 failed, result 8524:
The DSA operation is unable to proceed because of a DNS lookup
failure.
Last success @ 2004-09-02 13:27.18.
773 consecutive failure(s).

DC=altarum,DC=pri
Texas\TX-DS1 via RPC
objectGuid: 015301eb-f7f4-442a-9b4b-141dcb92a9cd
Last attempt @ 2004-09-06 13:27.15 failed, result 8524:
The DSA operation is unable to proceed because of a DNS lookup
failure.
Last success @ 2004-09-02 13:27.17.
98 consecutive failure(s).
AnnArbor\AA-DS2 via RPC
objectGuid: f0472b6f-e128-4b4d-9f83-b74d930005c0
Last attempt @ 2004-09-06 13:27.15 failed, result 8524:
The DSA operation is unable to proceed because of a DNS lookup
failure.
Last success @ 2004-09-02 13:27.18.
773 consecutive failure(s).

AA-DS2:
==== INBOUND NEIGHBORS ======================================

CN=Schema,CN=Configuration,DC=altarum,DC=pri
AnnArbor\AA-DS3 via RPC
objectGuid: 48b860a6-2891-4d95-a2ae-83f13bceb6fb
Last attempt @ 2004-09-06 13:17.35 was successful.
AnnArbor\AA-DS1 via RPC
objectGuid: 3121f9d2-f5ee-4d22-a1d9-a93ab0b42cd1
Last attempt @ 2004-09-06 13:17.35 was successful.
DC\DC-DS1 via RPC
objectGuid: acef4f79-44ef-40df-8566-ac3ca7023705
Last attempt @ 2004-09-06 13:17.35 was successful.
Texas\TX-DS1 via RPC
objectGuid: 015301eb-f7f4-442a-9b4b-141dcb92a9cd
Last attempt @ 2004-09-06 13:17.35 failed, result 8524:
The DSA operation is unable to proceed because of a DNS lookup
failure.
Last success @ 2004-09-02 15:52.36.
759 consecutive failure(s).

CN=Configuration,DC=altarum,DC=pri
DC\DC-DS1 via RPC
objectGuid: acef4f79-44ef-40df-8566-ac3ca7023705
Last attempt @ 2004-09-06 13:17.35 was successful.
Texas\TX-DS1 via RPC
objectGuid: 015301eb-f7f4-442a-9b4b-141dcb92a9cd
Last attempt @ 2004-09-06 13:17.35 failed, result 8524:
The DSA operation is unable to proceed because of a DNS lookup
failure.
Last success @ 2004-09-02 15:55.11.
753 consecutive failure(s).
AnnArbor\AA-DS1 via RPC
objectGuid: 3121f9d2-f5ee-4d22-a1d9-a93ab0b42cd1
Last attempt @ 2004-09-06 13:24.55 was successful.
AnnArbor\AA-DS3 via RPC
objectGuid: 48b860a6-2891-4d95-a2ae-83f13bceb6fb
Last attempt @ 2004-09-06 13:26.40 was successful.

DC=altarum,DC=pri
DC\DC-DS1 via RPC
objectGuid: acef4f79-44ef-40df-8566-ac3ca7023705
Last attempt @ 2004-09-06 13:17.35 was successful.
Texas\TX-DS1 via RPC
objectGuid: 015301eb-f7f4-442a-9b4b-141dcb92a9cd
Last attempt @ 2004-09-06 13:17.35 failed, result 8524:
The DSA operation is unable to proceed because of a DNS lookup
failure.
Last success @ 2004-09-02 15:55.18.
753 consecutive failure(s).
AnnArbor\AA-DS1 via RPC
objectGuid: 3121f9d2-f5ee-4d22-a1d9-a93ab0b42cd1
Last attempt @ 2004-09-06 13:26.04 was successful.
AnnArbor\AA-DS3 via RPC
objectGuid: 48b860a6-2891-4d95-a2ae-83f13bceb6fb
Last attempt @ 2004-09-06 13:28.00 was successful.

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

I've also read on another tech board that perhaps part of my problem is that
the previous admin removed all DCs from the default DC OU and placed them
within OUs she created for each site. Could this possibly be the problem?
Hopefully the logs I've posted shed some light on the issue.

Michelle

 

[Ace Fekay [MVP]]

In

I've run some additional tests on the servers and here ares some of
the results I've gotten, some I thought helpful, some rather curious.

In running netdiag /v on the server

I've also read on another tech board that perhaps part of my problem
is that the previous admin removed all DCs from the default DC OU and
placed them within OUs she created for each site. Could this
possibly be the problem? Hopefully the logs I've posted shed some
light on the issue.

Michelle

It could be part of the problem moving them. The Degault Domain Controllers
OU has the Default Domain COntrollers GPO. For starters, that controls
security, among other things. Put them all back where they belong please!
That has nothng to do with Sites.

What else was changed? ANy services turned off or disabled?
Is there a firewall somewhere between these machines?

--
Regards,
Ace

Please direct all replies ONLY to the Microsoft public newsgroups
so all can benefit.

This posting is provided "AS-IS" with no warranties or guarantees
and confers no rights.

Ace Fekay, MCSE 2003 & 2000, MCSA 2003 & 2000, MCSE+I, MCT, MVP
Microsoft Windows MVP - Windows Server - Directory Services

Security Is Like An Onion, It Has Layers
HAM AND EGGS: A day's work for a chicken;
A lifetime commitment for a pig.

 

[ptwilliams]

How did you create them?? If you did it manually, delete them all and
restart netlogon...

--

Paul Williams
_________________________________________
http://www.msresource.net


Join us in our new forums!
http://forums.msresource.net
_________________________________________


Hey Ace,

I think I've finally got this problem licked! After doing a bit more
investigation and drilling down into repadmin a bit, it came to me that the
error that I was seeing most often referenced the missing _msdcs guids. I
recreated CNAME records for all DCs on all DCs and replication kicked in
immediately.

Thanks for all the help with this!
Michelle

 

[Ace Fekay [MVP]]

In

Hey Ace,

I think I've finally got this problem licked! After doing a bit more
investigation and drilling down into repadmin a bit, it came to me
that the error that I was seeing most often referenced the missing
_msdcs guids. I recreated CNAME records for all DCs on all DCs and
replication kicked in immediately.

Thanks for all the help with this!
Michelle

You're welcome.

BUT, one thing, as Paul said and implied is that these are automatically
created by the netlogon service when it regsiters that info into DNS, hence
restarting the netlogon service normally creates these records. How did you
create them manually? Where did you get the GUID numbers for them? Is
Dynamic Updates enabled on the zone? Do all the DCs have the proper Primary
DNS Suffix on them?

Ace