Solved

NTDS KCC Event ID: 1265 (Replication attempt) Access is denied.

Posted on 2007-04-10
11
4,168 Views
Last Modified: 2012-06-21
Remote office server isn't replicating AD. W2k AD domain, 3 local DC servers, one remote (connected via VPN), all in the same domain.  I have a separate WINS server in the local office too.

Recently, we had some connectivity issues between here and the remote office.  The DSL line there was flaky, which knocked the VPN down.  Then the parent company decides to replace all of my firewalls with theirs so we'd be on the same platform, but they neglected to reset my VPN from here to the remote office for several weeks.

The end result is that it's been a long time since my remote server connected via FRS to my local office AD.  I finally got a T1 in the remote office as well as got the VPN back up and running.  Now the servers won't replicate to the remote site or vice versa....

This is from the remote server (with similar entries for attempts to connect to the other 2 servers):

The attempt to establish a replication link with parameters
 
 Partition: CN=Schema,CN=Configuration,DC=domname,DC=net
 Source DSA DN: CN=NTDS Settings,CN=NPUS01,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=domname,DC=net
 Source DSA Address: e472068c-424e-4387-b0dc-35de9689642c._msdcs.domname.net
 Inter-site Transport (if any): CN=IP,CN=Inter-Site Transports,CN=Sites,CN=Configuration,DC=domname,DC=net
 
 failed with the following status:
 
 Access is denied.
 
 The record data is the status code.  This operation will be retried.



The local PDC knows it's trying because repadmin displays this in reference to the remote server:

CN=Schema,CN=Configuration,DC=domname,DC=net
    Default-First-Site-Name\NPOH4 via RPC
        objectGuid: 769c1398-7b56-483a-b71c-1693f26d93cb
        Last attempt @ 2007-04-10 12:57.49 failed, result 5:
            Access is denied.
        Last success @ 2007-01-06 14:56.35.
        1502 consecutive failure(s).

CN=Configuration,DC=domname,DC=net
    Default-First-Site-Name\NPOH4 via RPC
        objectGuid: 769c1398-7b56-483a-b71c-1693f26d93cb
        Last attempt @ 2007-04-10 12:57.49 failed, result 5:
            Access is denied.
        Last success @ 2007-01-06 14:56.35.
        1502 consecutive failure(s).

DC=domname,DC=net
    Default-First-Site-Name\NPOH4 via RPC
        objectGuid: 769c1398-7b56-483a-b71c-1693f26d93cb
        Last attempt @ 2007-04-10 12:57.48 failed, result 5:
            Access is denied.
        Last success @ 2007-01-06 14:56.35.
        1502 consecutive failure(s).

I did find some errors in my DNS setup earlier on in the day such as the ISP set for primary DNS instead of local DNS on the remote server.  I had the remote server set as local DNS while the connectivity problems were around, so I've tried the FRS with the local office DNS as primary as well my remote DNS.

I don't need the 3rd DC locally, but I've waited to get this FRS issue cleared up before demoting that server. I've also had some other problems that seem to be related to this, but I can't be sure. The problems center around network connection and/or credentials for the connection.  That's what made me look into the FRS, as I thought I finally had it working.  Oops.
0
Comment
Question by:ricklr
  • 6
  • 5
11 Comments
 
LVL 30

Accepted Solution

by:
LauraEHunterMVP earned 250 total points
ID: 18884612
Has the remote office DC been able to replicate with the main office DC at -all- within the last 60 days?  (That 1-06-07 date would indicate that that's a "No.") If not, then take it offline, as it is useless from an Active Directory perspective.  Windows 2000 AD has a 60-day "tombstone lifetime" which handles replicated object deletions; if a DC hasn't been able to replicate for longer than that tombstone lifetime, bringing it back online will do more harm than good and will introduce issues of lingering objects and USN rollback.

Read through this KB article to see if this is the issue you are experiencing, though from your description it sounds like that's the case: http://support.microsoft.com/kb/885875. Assuming that is the case, you will need to remove the remote DC from AD, clean up the metadata associated with it (http://support.microsoft.com/kb/216498), and then re-promote it after you've resolved any physical/VPN connectivity and/or DNS resolution errors.

Hope this helps.

Laura E. Hunter - Microsoft MVP: Windows Server - Networking
0
 

Author Comment

by:ricklr
ID: 18886939
I thought I had it working last month, but apparently not, so it probably has not connected since January.  I wasn't aware of the 60 day span.  Too bad too.  This was one part of my network that never really gave me any trouble until the DSL down there decided to be a problem last fall.  Which leads me to my next question....I only have one server is this remote office.  It is the DC for there, file share, print share, DNS, and probably something I'm not thinking of at the moment.  The local users will still be able to use the server as they've always done, just log ins might be a bit slow, correct?  
0
 

Author Comment

by:ricklr
ID: 18886945
And by the way, thank you so very much for your quick response.  I'm still reading up on the steps to fix this....the previous thought just occurred to me and I wanted to write it down before forgetting about it.
0
 
LVL 30

Expert Comment

by:LauraEHunterMVP
ID: 18888476
Assuming there are no connectivity or name res. issues between remote office and main office, remote office users will authenticate against the DC in your main office until you rebuild the branch office DC. Logons will likely be slow, as you guessed, but it'll work.
0
 

Author Comment

by:ricklr
ID: 18901987
I just tried to run dcpromo just in case it would actually let me do this the "right" way.  When it runs, it gives me the error:
The operation failed because:
Managing the network session with pdcname.domainname.net failed
Logon failed: the target account name is incorrect.

This makes me think what may have been the original problem of not syncing properly to the AD to begin with was one of the background processes somehow has a username/pw screwed up.  Possible?

I guess it's really immaterial because it's been a little over 3 months since it synced anyway.  It would be nice if it would clean up after itself tho.....
That'd save me a ton of time....
0
 
LVL 30

Expert Comment

by:LauraEHunterMVP
ID: 18902503
Did you perform a metadata cleanup of the failed DC's computer account within AD?  You need to do this after any "abnormal" demotion of a DC, particularly if you want to re-introduce the re-installed DC using the same name.  Use the steps listed here if you have not already done so: http://support.microsoft.com/kb/216498
0
 

Author Comment

by:ricklr
ID: 18902708
I think I've finally cleaned up after it.  Had to do a few extra steps to get the computer acct out of AD, then clean up DNS.  Curiously, I had that server set with DNS on it as a secondary because of the previous connectivity problems I had before fixing my VPN.  My DNS setup on that remote server seemed to have went bye bye, but the service is still installed on that server.  Do I just set a new scope in there or is there anything else I need to be careful of?
0
 

Author Comment

by:ricklr
ID: 18902713
OK, scratch part of that....DNS is still on the server.... the old servername is still in the forward zone, which I need to delete now.  The reverse zone is gone altogether.  I guess I'm asking if I just delete the old servername from the forward zone and then just set up new forward and reverse zones like a new dns setup?
0
 
LVL 30

Expert Comment

by:LauraEHunterMVP
ID: 18902732
Assuming that you've done the metadata cleanup, then you should be able to move forward just as if you were setting up a new DC.  Since this was a 2K DC, though, you might want to double-check the following:

[1] DNS records, as you've already seen
[2] WINS entries, if you have WINS set up
[3] Confirm that it's gone from AD Sites & Services
[4] Open up ADSI Edit (from the Windows Support Tools) and confirm that there isn't still an entry for it under "ou=Domain Controllers,<DomainDN>"
0
 

Author Comment

by:ricklr
ID: 18902760
DNS is cleaned up. WIns is cleaned.  AD sites done.  ADSI done.  Login scripts changed.  AD users updated. YAY!!!!  All the permissions seems to be intact as well.  That's really nice.  I was concerned that I might have to set all that up again.   ugh.  But, it's not a problem now!  Thanks for your help.  

Did I miss anything?

Thanks again for your timely response and your help!  Have a great day and may God bless you!
0
 
LVL 30

Expert Comment

by:LauraEHunterMVP
ID: 18902789
You're quite welcome.  It sounds as though you're in good shape from here, hope it all goes well from here on in.
0

Join & Write a Comment

I know all systems administrator at some time or another has had to create a script to copy file from a server share to a desktop. Well now there is an easy way to do this in Group Policy. Using Group policy preferences is not hard. The first thing …
NTFS file system has been developed by Microsoft that is widely used by Windows NT operating system and its advanced versions. It is the mostly used over FAT file system as it provides superior features like reliability, security, storage, efficienc…
This tutorial will walk an individual through the steps necessary to join and promote the first Windows Server 2012 domain controller into an Active Directory environment running on Windows Server 2008. Determine the location of the FSMO roles by lo…
This tutorial will walk an individual through the process of transferring the five major, necessary Active Directory Roles, commonly referred to as the FSMO roles from a Windows Server 2008 domain controller to a Windows Server 2012 domain controlle…

747 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

9 Experts available now in Live!

Get 1:1 Help Now