KMS, host keys, client keys, etc.

1. One KMS can host multiple host keys - for example, it can host both Windows 2012 & Office host keys at the same time
2. Host keys are confidential info for companies who bought the license; while client keys are publicly available from Microsoft's website. Client key for a product is same for all companies who chose to use KMS activation.
3. Higher host keys is inclusive in that it covers older, lower products in the same product family. For example, once you install Windows Server 2012 Enterprise Edition, you won't need separate keys to cover standard edition or Windows 2008 servers. The same key covers all.
4. Procedure that can solve vast majority of activation issues in KMS environment
1. make sure DNS is working (can resolve KMS host name correctly), or just use IP address in below commands
2. check if client is using KMS activation
1. slmgr -dlv
2. it should show in output that this is a KMS client. If it's not a KMS type client: 
1. slmgr -upk
2. slmgr -ipk "product key of the OS version/edition". 
   You can google and find the product key
3. check if your client can resolve KMS SRV record
   ping _vlmcs._TCP.yourDomain.name
   if not resolving, you can manually add this record in DNS
   if resolving, your activation should work. Go to the verification step
4. If you don't want to use SRV record, you can also manually tell OS where to find KMS host
   slmgr -skms "A record of KMS host" or
   slmgr -skms "IP of KMS host"
5. verify and active 
   slmgr -ato

Replication error'ed out with "no more endpoints"

1.       When right click “replicate now”, and the error message is “error 1753: There are no more endpoints available from the endpoint mapper”, it’s complaining the source DC not able to find a RPC endpoint from target DC. To make it more confusing, these two DCs are replicating to all their other partners - they just don’t want to replication with each other (one direction)

2.       This KB helps: http://support.microsoft.com/kb/2089874 and with good explanation too

3.       In our case, it sounds like root DC(source) was brought to a wrong child DC (target) for replication as per above KB.

4.       However when I check all related A/CNAME records, they are all CORRECT. All WINS records are correct too. Clean DNS cache on both client side and DNS server side didn’t help either

5.       It turns out it’s child’s delegated zone in root zone has incorrect glue record (right click child zone, properties, name servers tab). Windows apparently is capable of detecting such misconfiguration but chose not to auto correct, which is weird. 

Lesson learned: when a DC's CNAME or A is resolved to a wrong IP while all its references in visible zones are correct, please check the Name Servers tab of stud node (of child zone) in parent DNS server. Also, when promote/demote child DCs, or change their IPs, please make sure changes are made in the Name Servers tab too ( I mistakenly assume that dcpromo program would do that automatically)

Pin point AD object deletion in event log

Ref: Technet blog here

This has been done before object being restored.

1. Find out DN of the deleted object (using ldifde or adrestore).
   Ldifde –x –d “CN=Deleted Objects,DC=domain,DC=com” –f Deletedobj.ldf
2. Know when the object was deleted, and on which DC
   Repadmin /Showobjmeta DCname “DN of the deleted object” > Delshowmeta.txt
   In the log, find attribute isDeleted, note the time
3. Go to the source DC, in security log, find the logs at specific time. Event log IDs are
   630(2k3)/4726(2k8) for user objects
   647(2k3)/4743(2k8) for computer objects