Monitor unlimited number of servers
Filter log events
Create email and web-based reports

Direct access to Microsoft articles
Customized keywords for major search engines
Access to premium content

Event ID: 1265 Source: NTDSKCC

Source
Level
Description
The attempt to establish a replication link with parameters Partition: DC=corpdom,DC=net Source DSA DN: CN=NTDS Settings,CN=DESCARTES,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=corpdom,DC=net Source DSA Address: f6535433-9ae5-41f8-984e-59f2b39138ea._msdcs.corpdom.net Inter-site Transport (if any): failed with the following status: <status>. The record data is the status code. This operation will be retried.
Comments
 
See ME249256 for a general approach in troubleshooting intra-site replication failures. See also the link for "Active Directory Replication" for additional information.

As per Microsoft: "If this error is being reported for Active Directory replication between two domain controllers of different domains which have a parent/child or tree root trust relationship, this error may be due to an absent critical object that represents the trust relationship between the two domains."

Status: "The DSA operation is unable to proceed because of a DNS lookup failure." See ME319202, this issue occurs because the DNS Database does not have a service (SRV) resource record for the domain controller.

Status: "The RPC server is unavailable." - See the link to error 1722.

Status: "Logon failure: unknown user name or bad password." - See ME328701, the trust relationship between domain may have to be reset.

Status: "Logon Failure: The target account name is incorrect." As per ME257844, this error may be due to an absent critical object that represents the trust relationship between the two domains.

From a newsgroup post: "I re-registered the Active Directory in the DNS and later found the problem was regarding a missing DC in the domain. After installing the second DC the problem went away."
This event can occur when promoting a domain controller to a global catalog server. Microsoft article ME910204 has some information on some typical status messages.

See ME911799 for additional information about this event.
This event is logged three times after adding an additional domain controller to your domain. After promoting the new server, Windows asks for a reboot. While rebooting, the existing domain controller(s) are already trying to establish NTDS connections with the new server. Since that one is temporarily unavailable, the connection fails and this warning is logged. As long as you see three 1264 NTDS KCC information events exactly 15 minutes later, there is nothing to worry about.

If you see this error in a domain with Windows 2003 SP1 domain controllers, try to set the DNS update policy from secure updates only to secure and non-secure.
See ME830379 for a hotfix applicable to Microsoft Windows 2000.

As per Microsoft: "This problem can occur when the password of the inter-domain trust account is not synchronized on both sides of the trust relationship". See ME816577, ME810089, ME839880, and ME297716 for more details.

ME291382 shows a list of Frequently Asked Questions about Windows 2000 DNS and Windows Server 2003 DNS.

From a newsgroup post: "I have a single domain consisting of three computers. Two of these computers are DCs. I was getting this error on my first DC. It turned out that I only had one server in native mode. After I changed the second DC from mixed to native, the problem disappeared".

See ME842208 , ME892426, and the link to "EventID 1265 from source Active Directory" for additional information on this event.
- Status: " The RPC server is unavailable" - It turns out that this problem was caused by our ISP, who put a filter on TCP ports 135 and 445 between our two main sites without telling us. Replication was functioning but AD must use RPC for reporting. As soon as the filter was taken off the router we were back in business.


I had this problem because my domain was single-labeled. When I followed the instructions in ME300684, the problem was fixed.
I have a single domain (domain.com), 1 DC with DNS (server1.domain.com). I got this message after I promoted a W2K server to DC (server2). To resolve the problem I went to DNS on server1. I could see server2 with the correct IP address, but under Forward Lookup Zones, domain.com, _msdcs, server2 was not listed as “server2.domain.com”. I added the "domain.com" to server2's fully qualified name and this fixed the problem.
I had this problem when DHCP service was not running on a DC, thus the other DCs couldn’t find it in DNS. It appears that DHCP is used to register IPs in DNS, even if DHCP is not used to get an IP address in the first place. Simply starting the DHCP service and "ipconfig /registerdns" solved the problem.
This event first appeared on a pair of Windows 2000 domain controllers for a child domain after the Windows Update service was run and hotfix Q32955 was applied. After using Sites and Services and Domains and Trusts to verify replication and trusts, I uninstalled the hotfix and the event and associated problems went away.
After restoring the first server in a multiple server network, replication failed with access denied errors. Also the KCC was not recreating the automatically generated intra-site links generating 1265 events. For some reason during the restore the server's userAccountControl attribute was not set correctly and was set as if the server was a workstation. changing this back to the server setting fixed the KCC problem and replication. See KB Article ME329860.
I started receiving this error after a failed DC demotion. I ran the ntdsutil.exe according to ME216498 which allowed me to manually remove the NTDS Settings object. After which I was able to delete the DC from AD Sites and Services MMC snap-in.
I have seen this when a down level domain controller on the domain has had forwarders configured. Then requests for "upstream servers" are passed to the forwarders instead of the Root level domain. Remove the forwarder and the replication should work.
The fix for this problem was to synch the time on the domain controllers. The Kerberos checks had become invalid because the time threshold was exceeded, therefore, AD replication halted. Default was 5 minutes, but the server times were off by 9 minutes. To keep this from happening again, I synched all domain controllers to one using the net time /setsntp:<server name> command.
I solved this problem simply by restarting the DNS service.


I have my (Unix-based) DNS setup according to Microsoft KB ME255913. I setup a new Windows 2000 DC but I forgot to add the computer to my Unix DNS box so the computer name was not resolved. I fixed this error by adding an entry into my Unix DNS for this new DC.
I started receiving this error after adding a DC to a site (DC was in the same AD domain). I fixed it by manually adding the DSA Address that was reported missing (ex: f6535433-9ae5-41f8-984e-59f2b39138ea._msdcs.<DOMAIN.com>.) to the stated location in a DNS server in the site that was replicating properly. Active Directory then could properly resolve the DCs name, and all replication links were automatically generated and worked fine.
To easily resolve this, on the server that was promoted you need to configure the DNS settings to append these DNS suffixes. Add all the suffixes you want that server to be able to talk to. After that is completed do an ipconfig /registerdns to update the DNS records.  

If you have secondary zones make sure they are pulling the records form the master. If it is not delete the zone and recreate it.

By doing both of these DNS was updated with the correct enteries and the KCC kick off successfully.
Our problem was caused by a DNS replication issue. A new DC's DNS record had not been replicated to another site. When the local DC's, from a subdomain, tried a DNS lookup they couldn't find the new DC and hence a replication link could not be established. Once the DNS replication issue was resolved the link could be established.
I added a DSA record in the _msdcs records on the server indicated by the source server in the error message. The message only give info about the source server which is where the error actually lies. Just take the DSA address of the server which gave the message (copy if from the local _msdcs record on this server) and add a new alias in the _msdcs records of the source server given in the error. A new link will be created by the KCC and replication will continue.

Windows Event Log Analysis Splunk App

Build a great reporting interface using Splunk, one of the leaders in the Security Information and Event Management (SIEM) field, linking the collected Windows events to www.eventid.net.

Read more...

 

Cisco ASA Log Analyzer Splunk App

Obtain enhanced visibility into Cisco ASA firewall logs using the free Firegen for Cisco ASA Splunk App. Take advantage of dashboards built to optimize the threat analysis process.

Read more...