Enable LDAP over SSL Using Certificate Generated From A Different Machine

The procedure is pretty simple and well documented in KB 321051, so there is nothing special here. However the tricky part is you have to submit the request from the same DC in order to make LDAPS work because this way ensures you have the private key for the certificate.

In some cases, it could take quite a while to obtain a certificate so you want to submit the request way ahead of time - so long ahead of time that you may not have the hardware yet at the time you have to send the request.

A workaround is to submit the request from another machine - any other machine as long as you make the request right. Once you get the certifiate, install it on the requesting machine, then export it with private key, finally import onto your new DC.

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: