Attempt to remove glue record on delegated zone crashes DNS console

- Windows 2008 R2
- 2 domains, parent-child
- 2 DNS zones respectively. Child zone delegated from parent zone
- Connect to parent DNS server, wrong IP listed for a name server in delegated zone properties window
- When try to remove or edit it, after confirmation, the MMC freezes

There are a few other people had same issue, seems to be a bug as far as I see it.

Resolution:
- ADSIedit, connect to parent DNS server
- Drill down to the delegated zone node
- In right hand pane, find the name server in question, remove the wrong IP from "dnsRecord(?)" attribute (you have to change the view to be "decimal" to see which entry is the wrong IP.

Update Nov 20, 2012:
Never mind the above, I found a hotfix http://support.microsoft.com/kb/2581690 that is exactly for this bug. This KB was published in 2011, I wonder why I didn't find it earlier - I consider myself an expert finding KBs :-). Not to mention why the Microsoft engineer I worked with didn't find this either.

Largest Delta? What is it?

[
Short version: typically you don't have to pay attention to this stat. As long as number of "fails" is zero, AD replication is healthy.
Note: When you have replication fails and subsequently remedy the problem, the number of "fails" in "replsummary" report is not going to change to zeros right away. The report of this command is a snapshot of history, so it takes a bit time for all fails to disappear.
]

Repadmin /replsummary result is simple, but yet somewhat confusing. A few notes:

• If you don't specify /bysrc or /bydest, it will list status for both directions. You want to pay attention to Destination DSA as AD replication is pull-based.
• Most critical column is "fails". If there is no fails, obviously you don't have much to worry about
• Most confusing column is "largest delta". It's common misunderstanding (on the Net at least) that value in this column should be less then 1hr. However, depending on how large your AD environment is, and how frequent changes happen in a particular Naming Context, value in this column could be very large (days)
• Microsoft's official interpretation for "largest delta": longest replication gap amongst all replication links for a particular DC", which is not really helpful. I personally had hard time to understand this interpretation itself.
• This value is for the particular DC, among all its replication partners, the longest time that it hasn't replicated anything against whatever NC. This value has to be read together with /showrepl command against that DC.

Read on for example:

How to troubleshoot account lockout issue

[Note] Event ID applicable to Windows 2003 DC only, but it shouldn't be too difficult to find related W2k8 event IDs.
[Edit Feb 14/2012] Full list of audit events in windows 2008 can be downloaded here, also KB947226
Please read the differences between "Account Logon/logoff" event and "Logon/Logoff" event first.

- First, using lockoutstatus to find out initial authenticating DC (more than often PDC is not the initial authenticating DC. It has same event IDs mentioned below merely because other DCs check with PDC for latest password.) and time of logon attempt

- Then go to authenticating DC, check security log. Pin-point the log entry using time identified by lockoutstatus

- We are looking for: event ID 675 (4771 in w2k8?), the client IP is the offending machine that sent bad pwds

- Failure code in event ID 675(This is corresponding kerberos error code, full list here)

• 0x18: original wrong password
• 0x12: this will be logged after the fact that account has already been locked

- Logon type in event ID 675 ( full list here)

• 2 being interactive
• 3 network
• 5 service
• 10 Remote interactive