AD CA basic - study notes

1. There are 3 snapins for certificate-related management
1. on client, there is Certificates snappin, this manages the actual certificates
2. on server, you have CA snapin and Certificate Templates snapin
2. Just because you have a certificate template, doesn't mean CA is going to use it
3. In order to issue a certain type of certificate, you have to let CA know that you want to issue that type of cert:
1. In CA snapin, right click server name, New Certificate Template To Issue
2. To check the current template that your CA can issue, click on "certificate templates"
4. To manage your templates (in use/not in use), in CA snapin, expand CA server name, right click "Certificate Templates", select manage
5. After #3, you are in "Certificate Templates" snapin
1. Templates listed in here can be in use or not in use, depending on if you have perform #3 above
2. You can directly publish a built-in template, but more typically, you should clone a template, make change on clone, then publish it (not a clone any more since we have made changes)
6. For client to request:
1. on a client machine, open Certificate snapin
   Optionally you can use IIS Admin Console or certreq command line
2. Generate a request, send it to CA admin
3. CA admin approves it
4. Client enrolls the cert
7. You can automate #6 by enabling auto enrollment in group policy
8. Enterprise CA vs. Standalone CA
1. standalone CA doesn't have certificate templates
2. standalone doesn't support auto-enrollment
3. 
   

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)