1

I've gotten saddled with setting up MS's Key Management Services for our systems. (I missed the meeting...)

The KMS server part seems to have installed on the KMS server box ok and appears to have activated, but none of the clients are able to activate against it, and can't actually even find it. So the first thing I'm looking at is DNS.

Up front, here's the symptom on a fresh client winds2 (not configured as an AD or DNS yet). Details and exposition below.

C:\>slmgr.vbs /dlv

C:\>nslookup -type=all _vlmcs._tcp
Server:  winds1.ems.local
Address:  172.17.21.20

DNS request timed out.
    timeout was 2 seconds.
DNS request timed out.
    timeout was 2 seconds.
*** Request to winds1.ems.local timed-out

Here's the relevant system configuration

wsus3 -> KMS server 172.31.92.151/24 (a vmwware-convert of existing real live 2008R2 box acting as wsus server)
winds1 -> DNS server 172.17.21.20/24 (a vmware-convert of existing real live 2003 box)
winds2 -> win2008R2 172.17.21.21/24   -not- a DNS or AD box (yet).  expecting to activate against wsus3

on winds2, [one of] the KMS client

C:>tcping.exe wsus3 1688

DNS: Could not find host wsus3, aborting.

C:>tcping.exe 172.31.92.151 1688

Probing 172.31.92.151:1688/tcp - Port is open - time=22.089ms Probing 172.31.92.151:1688/tcp - Port is open - time=14.074ms Probing 172.31.92.151:1688/tcp - Port is open - time=14.173ms Probing 172.31.92.151:1688/tcp - Port is open - time=14.033ms

Ping statistics for 172.31.92.151:1688 4 probes sent. 4 successful, 0 failed. Approximate trip times in milli-seconds: Minimum = 14.033ms, Maximum = 22.089ms, Average = 16.092ms

C:>tcping.exe 172.17.21.20 53

Probing 172.17.21.20:53/tcp - Port is open - time=16.426ms Probing 172.17.21.20:53/tcp - Port is open - time=14.244ms Probing 172.17.21.20:53/tcp - Port is open - time=14.352ms Probing 172.17.21.20:53/tcp - Port is open - time=14.407ms

Ping statistics for 172.17.21.20:53 4 probes sent. 4 successful, 0 failed. Approximate trip times in milli-seconds: Minimum = 14.244ms, Maximum = 16.426ms, Average = 14.857ms

C:>nslookup wsus3 Server: winds1.ems.local Address: 172.17.21.20

*** winds1.ems.local can't find wsus3: Server failed

C:>nslookup winds1 Server: winds1.ems.local Address: 172.17.21.20

*** winds1.ems.local can't find winds1: Server failed

C:>nslookup winds2 Server: winds1.ems.local Address: 172.17.21.20

*** winds1.ems.local can't find winds2: Server failed

C:>nslookup winds2. Server: winds1.ems.local Address: 172.17.21.20

*** winds1.ems.local can't find winds2.: Server failed

So there is something wrong with dns; it's not resolving names (much less SRV records) but right up top it indicates that client winds2 can tcp connect to the ip address and DNS port on DNS server winds1

However, within DNS server winds1, there is no problem:

C:>nslookup -type=all _vlmcs._tcp Server: winds1.ems.local Address: 172.17.21.20

_vlmcs._tcp.EMS.LOCAL SRV service location: priority = 0 weight = 0 port = 1688 svr hostname = wsus3.ems.local wsus3.ems.local internet address = 172.31.92.151

C:>ping wsus3

Pinging wsus3.EMS.LOCAL [172.31.92.151] with 32 bytes of data:

Reply from 172.31.92.151: bytes=32 time<1ms TTL=127 Reply from 172.31.92.151: bytes=32 time<1ms TTL=127 Reply from 172.31.92.151: bytes=32 time<1ms TTL=127 Reply from 172.31.92.151: bytes=32 time<1ms TTL=127

Ping statistics for 172.31.92.151: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 0ms, Maximum = 0ms, Average = 0ms

C:>tcping.exe wsus3 1688

Probing 172.31.92.151:1688/tcp - Port is open - time=2.895ms Probing 172.31.92.151:1688/tcp - Port is open - time=2.124ms Probing 172.31.92.151:1688/tcp - Port is open - time=2.008ms Probing 172.31.92.151:1688/tcp - Port is open - time=2.122ms

Ping statistics for 172.31.92.151:1688 4 probes sent. 4 successful, 0 failed. Approximate trip times in milli-seconds: Minimum = 2.008ms, Maximum = 2.895ms, Average = 2.287ms

C:>

Any thoughts?

I manually set up the DNS SRV per

http://technet.microsoft.com/en-us/library/ff793405.aspx

And am using these documents (so far) for setting up KMS:

http://social.technet.microsoft.com/Forums/en-US/341e8906-0fe6-477e-8ce2-8e515f0f227a/key-management-service-kms-is-unavailable?forum=w7itproinstall

http://technet.microsoft.com/en-us/library/ee939272.aspx

http://technet.microsoft.com/en-us/library/ff793439.aspx

user52874
  • 829
  • 2
  • 12
  • 26
  • Is `winds2` joined to the domain? If not then my guess is that it's sending a single label query to the DNS server because it's lacking a primary or connection specific DNS suffix. If that's the case then that may explain the problem. I get a different result in my test but nonetheless that's what I would look at first. – joeqwerty Mar 13 '14 at 02:19
  • no, it is not. So I should try joining it to the domain and see if that resolves it? Shouldn't DNS respond whether the winds2 is joined to an AD domain or not, that is, isn't DNS vendor/system agnostic? In any case, I'll give it a try. – user52874 Mar 13 '14 at 17:18
  • Your DNS server hosts a DNS zone for the AD domain (ems.local). Your client is sending a query to the DNS server for _vlmcs._tcp (a single label name since the client has no DNS suffix). The server can only reply to queries for _vlmcs._tcp.ems.local but not for _vlmcs._tcp because it has no zone for the single label name. DNS servers answer for queries to zones they host. Without the DNS suffix the DNS server has no idea what zone _vlmcs._tcp is in. It only knows about records in the ems.local zone. – joeqwerty Mar 13 '14 at 17:58
  • You could deploy a GlobalNames zone to handle single label queries but I think thast's probably not appropriate here. So the answer is to join the client to the domain. The DNS suffix will then be appended to all single label queries and the server will correspondingly answer correctly. – joeqwerty Mar 13 '14 at 17:59
  • OK. I get it now. I'll give that a try and get back with the results – user52874 Mar 14 '14 at 01:55
  • OK. that solved that problem. the client is still not activating though. I'll make that a separate question and declare this question answered. Thanks! – user52874 Mar 14 '14 at 18:05
  • Well, I will as soon as I figure out how. The comment with "So the answer is to join the client to the domain" will be the accepted answer. – user52874 Mar 14 '14 at 18:08
  • Posted it as an answer. – joeqwerty Mar 14 '14 at 18:09

2 Answers2

1

If your use CHNAME to link SRV record with A record you will see the same error. Only SRV record must use realy FQDN with A record

C:\>nslookup -type=all _vlmcs._tcp
Server:  winds1.ems.local
Address:  172.17.21.20

DNS request timed out.
    timeout was 2 seconds.
DNS request timed out.
    timeout was 2 seconds.
*** Request to winds1.ems.local timed-out
Valentin G.
  • 11
  • 1
0

Your DNS server hosts a DNS zone for the AD domain ems.local. Your client is sending a query to the DNS server for _vlmcs._tcp (a single label name since the client has no DNS suffix). The server can only reply to queries for _vlmcs._tcp.ems.local but not for _vlmcs._tcp because it has no zone for the single label name. DNS servers answer for queries to zones they host. Without the DNS suffix the DNS server has no idea what zone _vlmcs._tcp is in. It only knows about records in the ems.local zone.

In order for the server to resolve the query for _vlmcs._tcp from the ems.local zone the client needs to be configured with the ems.local DNS suffix. You can achieve this by joining the client to the domain or by configuring the DNS suffix in the Advaned TCP/IPv4 properties of the NIC.

joeqwerty
  • 109,901
  • 6
  • 81
  • 172