KMS server discovery

Question

KMS server discovery

xXcodgerXx opened this issue 3 years ago · 9 comments

I added a DNS record for py-kms in pihole using the method shown here. Linkie

A fresh install of Win 10 Pro on the client machine using the VL key provided by MS it is not activated automatically.
Running nslookup -type=srv _vlmcs._tcp from the client machine shows the py-kms server.
I enter the key again manually using slmgr /ipk VLKEY just to make sure it is correct.
Running slmgr /ato gives the following error (see attached screencaps)
If I specify the kms server using slmgr /skms mykms.server then run slmgr /ato it activates successfully.

Am I doing something wrong?

Thank you for your time.

BTW I am using the latest py-kms

Answer 1 · 2021-12-23T15:51:55.000Z

Hi,
as first: I have never used Microsofts DNS SRV records. There is a good chance that they only work e.g. in AD scenarios...
Could you try to modify the SRV record as follows and then retest?

Add the IPv4 instead of the hostname (of the py-kms server)
Add the FQDN (maybe you are e.g. using a Fritz!Box, which automatically sets the domain name of the network to fritz.box)

As a final step (to determine if the problem is on py-kms or your network), try to use Wireshark and see if Windows is really sending out packets to the py-kms host and if the py-kms host is even receiving it (and replying).

Please post your results (and anonymize them!) for further investigation.

Thanks!

Answer 2 · 2021-12-23T16:36:58.000Z

I believe what might be happening here is that you've created a record in your DNS server with the correct prefix, however you've provided no domain suffix. In the NSLOOKUP which returns successfully you do not provide a suffix and nor do you on the /skms example.

I suspect that your DHCP server is providing a DNS suffix Windows is appending and subsequently the vlmcs lookup is never hitting the record you created in PiHole.

Can you enable detailed request logging in PiHole and provide DNS server logs of the vlmcs request make by /ato?

Answer 3 · 2021-12-23T17:42:13.000Z

Hi, as first: I have never used Microsofts DNS SRV records. There is a good chance that they only work e.g. in AD scenarios... Could you try to modify the SRV record as follows and then retest?

Add the IPv4 instead of the hostname (of the py-kms server)

Add the FQDN (maybe you are e.g. using a Fritz!Box, which automatically sets the domain name of the network to fritz.box)

As a final step (to determine if the problem is on py-kms or your network), try to use Wireshark and see if Windows is really sending out packets to the py-kms host and if the py-kms host is even receiving it (and replying).

Please post your results (and anonymize them!) for further investigation.

Thanks!
Thanks

I was able to do a couple of quick changes and tests. Things are hectic here. :)

I changed the hostname to the IPv4 address, no change in the results. I also tried wireshark and didn't seen any traffic going to the IPv4 address of the kms server regardless of using the IPv4 address or hostname in the KMS DNS entry.

I also added a bogus DNS suffix to the client and the error message was different when trying to auto-activate. It indicated the KMS server could not be found.

Just for the heck of it, I did slmgr /skms mykms.server then slmgr /ato and it activated successfully but I still did not see any traffic going to the IPv4 address of the KMS server. Maybe it is encrypted or something?

The client is running inside a VMWare Workstation VM with a bridged network connection. Perhaps this makes a difference.

Answer 4 · 2021-12-29T14:56:18.000Z

I still did not see any traffic going to the IPv4 address of the KMS server. Maybe it is encrypted or something?

I believe you should still see something, can you filter in Wireshark by tcp port 1688 and then reactivate?

Answer 5 · 2022-01-01T01:55:59.000Z

btw its not /skms it is /skms-domain for autodiscovery via dns in slmgr
Also set the weight to 1 in your SRV entry never to 0

private const L_optSetKmsLookupDomain                 = "skms-domain"
private const L_optSetKmsLookupDomainUsage            = "Set the specific DNS domain in which all KMS SRV records can be found. This setting has no effect if the specific single KMS host is set via /skms option."

slmgr.vbs /ckms kms.poo
slmgr.vbs /skms-domain kms.poo

this hould fix your problem.

Answer 6 · 2022-01-01T05:30:48.000Z

@Matthew-Beckett @simonmicro

restored the VM prior to specifying the kms server on the client. I then ran slmgr /ato nothing was sent anywhere with a destination port of 1688.
added slmgr /skms mykms.server then slmgr /ato - saw the packets sent to the KMS server in wireshark and it activated.

So it is NOT sending packets or requests to the KMS server until it is specified on the client with slmgr /skms mykms.server

I'm starting to agree - using the DNS entry for KMS auto-discovery probably requires being part of a Windows domain.

I'm thinking if you try to activate it before specifying the KMS server manually, even though there is a DNS entry, the client tries to request something from a domain first and then is directed to the KMS server?

@Oratorian

I am trying to get it to activate out of the box without having to run any 'slmgr' command. I used slmgr /skms mykms.server to specify the KMS server to confirm it would activate.

Answer 7 · 2022-01-01T16:13:30.000Z

For this to work you indeed need to be in a AD.

But you can create a custom image with the skms-domain flag set as a group policy

Answer 8 · 2022-01-06T17:02:37.000Z

Soooo.... Should we close this or do we need to add something to the documentation?

Answer 9 · 2022-01-09T23:15:56.000Z

Soooo.... Should we close this or do we need to add something to the documentation?

Either way, this issue is deployment-dependent and related to Windows discovery of KMS servers and certainly out of the scope of this project to assist.