Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Question
Friday, February 12, 2016 3:42 PM
I disabled DNS publishing on the old 2008 R2 KMS server (that I'll be retiring), deleted it in DNS, made sure new 2012 R2 KMS server is in DNS. Existing Win7 clients seem to be failing to register to the new KMS server.
Firewalls are off on both servers and all clients. Ping of hostname of KMS server from client works fine.
Yesterday I had:
"Both Total and Failed requests received" were increasing and both equal on the new server.
So yesterday, I then took 3 clients and did the slmgr commands on them to point them exactly to the new KMS server (with last step being set them back to auto), and then (and only then) did the server show they were licensed (under "Requests with License Status Licensed").
So yesterday I had:
- Total requests received:18
- Failed requests received: 15 (since 3 had succeeded from my manual intervention above)
Today I have:
- Total requests received:27
- Failed requests received: 24
So it appears machines are hitting this new KMS server but failing to license? KMS in Event Viewer seems to be quite useless. Al it ever says is An acitvation request has been processed" 12290 Are details recorded anywhere on the client?
Since yesterday when I disabled DNS publishing on old server, it had inserted itself back into DNS, but I repeated the /cdns and then restarted the Software protection service, which I hadn't done yesterday. Anyhow I don't think that was an issue since the increasing (failed) count on the new server proves clients were hitting that server.
The other thing is, my Win7 clients are virtual machines cloned from a master image. Although I'm pretty sure that I never ran a slmgr command on the master (before creating virtual machines) to set it to a specific KMS server, but is there any way to check this, and make sure it's set to automatic? Because if it isn't (that is default, right?) we'd have to somehow undo this on 100+ virtual machines. Hopefully it's not this that's the issue though.
Any ideas????
All replies (27)
Tuesday, February 23, 2016 5:34 PM ✅Answered | 2 votes
The Microsoft tech (from China) emailed me that his hours are 9 PM to 6 AM. (completely opposite from US working hours). To his credit, he worked with me "off hours" to assist me.
I Was told to:
"browse to: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SoftwareProtectionPlatform and check if there is a registry named “KeyManagementServiceName”, and see if the Data is the old KMS host server. If yes, please delete it and reboot the client."
I did this, then saw that the reg entry did NOT come back. And a slmgr /dlv at the client showed it activated to the new kms server. Was told I'd need to delete the entry on all 100+ VMs.
When I asked why Microsoft would stick that reg entry in if it wasn't necessary, and was told it isn't by default. I am quite sure though, that I didn't go in there manually inserting that into my master image.
Friday, February 12, 2016 7:20 PM | 1 vote
You can write a simple PowerShell script to issue this command on a list of workstations. That will return what the client knows about KMS. I can't figure out from my system which values would be of interest to you because my system is working as it should, but performing it on one that is correct and one that isn't should give you an idea about what to look for.
Get-WMIObject SoftwareLicensingService
. : | : . : | : . tim
Friday, February 12, 2016 9:19 PM
Thanks Tim, but now I'm thinking that isn't a factor. I just checked a plain-jane windows machine I built yesterday, (where I'm positive I never ran any slmgr commands) and it's showing still NOT activated. And I just created another one today, which also isn't activating. It's only been running 15 mins, but I guess it should've activated by now.
Friday, February 12, 2016 10:28 PM | 1 vote
"* I just checked a plain-jane windows machine I built yesterday,*"
Was this built with volume media? Only volume media will automatically look for KMS. Others have to be set to look.
(Get-WMIObject SoftwareLicensingService).DiscoveredKeyManagementServiceMachineName
will return the name of the discovered server, if it is being discovered. That's I said to look at the output from a working/non-working machine. You might be able to find something that will allow you to track things down.
. : | : . : | : . tim
Saturday, February 13, 2016 5:52 AM | 1 vote
you'll need to examine the event logs on the KMShost and also on the KMSclient, to correlate the events, and to understand the request & response.
This article will help you understand the structure of the data in the events
https://technet.microsoft.com/en-us/library/ee939272.aspx
I find it easier for some analysis to export the KMShost event logs to CSV and then clean it up with notepad++ and then import it into Excel.
Don [doesn't work for MSFT, and they're probably glad about that ;]
Tuesday, February 16, 2016 3:04 PM
Definitely volume media. And again, existing machines were activating fine to the old KMS server.
That command DOES reply with the name of the new KMS server (at least that) from my newly created client machine. This new machine is NOT activating.
From an existing client machine (that is and has been activated to old kms server) , your specific command comes back with nothing (just back to the prompt) If however, I do just the simpler "Get-WMIObject SoftwareLicensingService", it comes back with much information, except that the DiscoveredKeyManagementServiceMachineName, KeyManagementServiceMachineName, & IsKeyManagementServiceMachine fields are blank, and DiscoveredKeyManagementServiceMachinePort is 0.
Tuesday, February 16, 2016 4:28 PM
Well, I followed that doc.
From slmgr.vbs, new 2012R2 kms server show:
- Description: "VOLUME_KMS_2012-R2_win10 channel"
- Product Key Channel: Volume:CSVLK
- Partial product key:(last 4 chars of what on my VLSC shows for kms key of "Windows Srv 2012R2 DataCtr/Std KMS for Windows 10"
- Use License URL: https://activation-v2.sls.microsoft.com/SLActivateProduct/SLActivateProduct.asmx?configextension=Retail (Is the fact it says "Retail" here an issue? My old (2008 R2) kms server shows "http://go.microsoft.com/fwlink/?LinkID=88345" here, but then again its "Description" field is different, it's missing the "_win10" part, and the partial key is for "Windows Srv 2012R2 DataCtr/Std KMS" per VLSC site...**but I DO want to be able to activate Win10 clients as well as Win7 ones from the new server. Both keys on VLSC say"KMS" next to them.
** - License status: Licensed
In event logs, server shows: Many activation requests (12290), with client name (but no domain name after it) and also shows unique machine IDs for each client.
From slmgr.vbs, Client shows:
- Description: "Windows(R) 7,VOLUME_KMSCLIENT channel"
- Partial product key HVTHH
- License status: initial grace period.
In event logs, client shows:
- 12288 entry properly shows my new km servername by full FQDN and port 1688.
- 12289 entry shows activation flag=0 (failed), current count on the KMS host=5 (not sure where it's getting that, the server only shows 3 activated)
- The entire Key Management Service Client information area shown in the article is missing.
The exception is the 3 machines where we directly specified this kms server with the slmgr command. These show flag=1 (successful). The client also has an 8196 event even up until today, which I'm unclear about, I'm researching that now. There's no voluminous logs to filter. The same events repeat over and over on both client and server. Telnet to 1688 on that server connects (get blank screen) when done from both server and client.
Tuesday, February 16, 2016 8:15 PM | 1 vote
on your KMShost, it looks like you have installed the correct pkey, and have also activated that successfully (based on the "Description" and "License Status" you've mentioned)
what is the value against "current count" for this license on your KMShost? (it has to be 25 or higher, or this KMShost will not issue activations to workstation edition clients eg WinVista/7/8/8.1/10)
a KMSclient will (aggressively) continuously retry activation to the KMShost, if the current status of the KMSclient is in "Grace" or "Notification". (which is why you're seeing so many 12290/12290)
KMSclients, as part of their request, will send up the KMShost_current_count the client "needs". The KMShost responds with the current_count that it has. The KMSclient then compares the response and if the minimum_threshold for that client product is met, the client will transition to activated status.
For windows workstation clients, the threshold is 25.
For windows server clients, the threshold is 5.
For Office clients, the threshold is 5. (the Office current_count is counted separately from the Windows count) (but the Windows workstation and Windows server counts are combined into a single "Windows" current_count).
So if you're seeing "5" in the events, that's probably coming from a server or office product.
Don [doesn't work for MSFT, and they're probably glad about that ;]
Tuesday, February 16, 2016 8:46 PM
**Thanks Don. Full output from /dlv on server is below. ** Current count is 5 as seen below. I knew about the "25" value, but had thought the 25 was how many hits (requests) the server got. I had rebooted at least 25 clients previously with no **change, but then again, that was before I had discovered how to kill off the old one's DNS publishing for good. So if current count must be 25 or greater, maybe I just need to reboot 20 more clients? And now they should find just THIS server since they won't be able to find the old one via DNS vlmcs entry now? Maybe we're getting somewhere now.
**
Microsoft (R) Windows Script Host Version 5.8
Copyright (C) Microsoft Corporation. All rights reserved.
Software licensing service version: 6.3.9600.17809
Name: Windows(R), ServerStandard edition
Description: Windows(R) Operating System, VOLUME_KMS_2012-R2_WIN10 channel
Activation ID: (I blanked this out)
Application ID: (I blanked this out)
Extended PID: (I blanked this out)
Product Key Channel: Volume:CSVLK
Installation ID: (I blanked this out)
Use License URL: https://activation-v2.sls.microsoft.com/SLActivateProduct/SLActivateProduct.asmx?configextension=Retail
Validation URL: https://validation-v2.sls.microsoft.com/SLWGA/slwga.asmx
Partial Product Key: (I blanked this out)
License Status: Licensed
Remaining Windows rearm count: 999
Remaining SKU rearm count: 1001
Trusted time: 2/16/2016 1:37:39 PM
Key Management Service is enabled on this machine
Current count: 5
Listening on Port: 1688
DNS publishing enabled
KMS priority: Normal
Key Management Service cumulative requests received from clients
Total requests received: 126
Failed requests received: 42
Requests with License Status Unlicensed: 0
Requests with License Status Licensed: 3
Requests with License Status Initial grace period: 81
Requests with License Status License expired or Hardware out of tolerance: 0
Requests with License Status Non-genuine grace period: 0
Requests with License Status Notification: 0
Tuesday, February 16, 2016 9:09 PM
Well, I rebooted 12 Win7 clients, it's been about an hour, and numbers haven't changed except one additional on "Failed requests received". Current count is still 5
Wednesday, February 17, 2016 7:34 AM | 1 vote
Well, I rebooted 12 Win7 clients, it's been about an hour, and numbers haven't changed except one additional on "Failed requests received". Current count is still 5
There's something very wrong about that. reboot 12 clients, you should have seen at least 12 requests come in to the host.
Check if any of those clients (via logs on client and host) actually attempted contact with the host and check the response generated/received).
A client reboot should be all that's needed, you shouldn't need to use "slmgr.vbs /ato" at the client (but it's worth a try to see if it reveals what's [not] happening)
Don [doesn't work for MSFT, and they're probably glad about that ;]
Wednesday, February 17, 2016 3:08 PM
Today I show (bolded numbers increased):
Key Management Service is enabled on this machine
Current count: 5
Listening on Port: 1688
DNS publishing enabled
KMS priority: Normal
Key Management Service cumulative requests received from clients
Total requests received: 144
Failed requests received: 42
Requests with License Status Unlicensed: 0
Requests with License Status Licensed: 3
Requests with License Status Initial grace period: 99
Requests with License Status License expired or Hardware out of tolerance: 0
Requests with License Status Non-genuine grace period: 0
Requests with License Status Notification: 0
The VMs I restarted yesterday were already activated (and still show they are - to the old KMS server that is NOT in DNS anymore) So what does running /ato from an activated machine do? It popped up "Product activated successfully" and on the server, "Total requests received" increased by one, to 145. Event log shows 12289 with activation Flag=1 (successful), count=50 (which happens to match count shown on my old server) So, not sure what's going on here...is it trying the new server and failing? And then going to the old one and activating? Or failing to the new, then realizing it's already activated to the old one and not bothering even to activate to the old one?
On a brand new machine (I created last week that never activated), on it's screen today, after clicking the bubble caption warning its not activated, it says "The Key Management Server does not have enough computers registered at this time". When I type slmgr /ato on it, I get the software licensing service reported that the computer could not be activated. The count reported by your Key Management Service (KMS) is insufficient." And on the new kms server, "Total requests received" increased by one, to 146.
I'm sure if I do what I did to get the 3 machines activating, I will get more activating. But doing this to 22 more client machines is time consuming, and shouldn't be necessary. Those steps were:
Run slmgr **/**dlv and note down it’s activation ID.
Run slmgr **/**skms KMSservernameFQDN:1688 [Activation ID]
Run slmgr /ato Should get message that you’re activated.
Run slmgr /ckms [Activation ID] This restores the auto-detection of the KMS host.
I've also now installed VAMT on my own workstation, and scanned for machines in AD. I set in preferences to only use KMS, and specified my new kms server. I went to an already acitvated (to old server) machine and got the same message as above (the software licensing service reported that the computer could not be activated. The count reported by your Key Management Service (KMS) is insufficient.)
I could create 22 brand new virtual win7 machines, but if I created two already and it's not helping, will 22 help or not? Also, in researching the error, I found a site called woshub.com that has an article with a script to increase your kms server current count. But I don't know if this is safe to do.
Wednesday, February 17, 2016 5:23 PM
I just created 8 new virtual machines.
I notice now Current Count = 6 and Requests with License Status Licensed=4 I notice the first of the 8 machines I created DID activate. So I then logged into the 2nd one and it also shows activated. But count is still only one more than before(6)
If I disable software licensing service on the old server, which is also a domain controller, will its own Server OS fail to be activated? The only other thing I've read (about decommissioning old kms servers) is to uninstall kms keys on your old server. I thought that was a bit drastic so was hoping not to do that, in case I had to fall back if many users (or even our servers) started reporting getting "your windows is unlicensed" messages. (management freaks out about that stuff)
Besides the old kms server on this domain, I also had set one up on a different domain. (ABC) Note that I had never done the regedit (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SoftwareProtectionPlatform\DnsDomainPublishList) on this kms server on ABC domain to allow it to publish to other domains. (However, I did said regedit vice-versa on the new kms server on DEF domain) Nevertheless, I just now edited its VLMCS entry to point to the new kms server on the other (DEF) domain. And ran slmgr /cdns on it and restarted Software Protection service. I have a one-way external trust between the domains. I just noticed that even up til today machines have been activating to this server, so since I did the /cdns and restarted software protection service, this should stop. (I'll be watching event log to make sure!)
Question though: Does the key on my new server also activate 2008 R2?
Wednesday, February 17, 2016 8:29 PM | 1 vote
Question though: Does the key on my new server also activate 2008 R2?
Yes. This pkey will issue activations for *all* Windows VL products currently in existence.
Description: Windows(R) Operating System, VOLUME_KMS_2012-R2_WIN10 channel
Don [doesn't work for MSFT, and they're probably glad about that ;]
Wednesday, February 17, 2016 8:44 PM | 1 vote
Today I show (bolded numbers increased):
Key Management Service is enabled on this machine
Current count: 5
Listening on Port: 1688
DNS publishing enabled
KMS priority: NormalKey Management Service cumulative requests received from clients
Total requests received: 144
Failed requests received: 42
Requests with License Status Unlicensed: 0
Requests with License Status Licensed: 3
Requests with License Status Initial grace period: 99
Requests with License Status License expired or Hardware out of tolerance: 0
Requests with License Status Non-genuine grace period: 0
Requests with License Status Notification: 0The VMs I restarted yesterday were already activated (and still show they are - to the old KMS server that is NOT in DNS anymore) So what does running /ato from an activated machine do? It popped up "Product activated successfully" and on the server, "Total requests received" increased by one, to 145. Event log shows 12289 with activation Flag=1 (successful), count=50 (which happens to match count shown on my old server) So, not sure what's going on here...is it trying the new server and failing? And then going to the old one and activating? Or failing to the new, then realizing it's already activated to the old one and not bothering even to activate to the old one?
On a brand new machine (I created last week that never activated), on it's screen today, after clicking the bubble caption warning its not activated, it says "The Key Management Server does not have enough computers registered at this time". When I type slmgr /ato on it, I get the software licensing service reported that the computer could not be activated. The count reported by your Key Management Service (KMS) is insufficient." And on the new kms server, "Total requests received" increased by one, to 146.
I'm sure if I do what I did to get the 3 machines activating, I will get more activating. But doing this to 22 more client machines is time consuming, and shouldn't be necessary. Those steps were:
Run slmgr **/**dlv and note down it’s activation ID.
Run slmgr **/**skms KMSservernameFQDN:1688 [Activation ID]
Run slmgr /ato Should get message that you’re activated.
Run slmgr /ckms [Activation ID] This restores the auto-detection of the KMS host.
I've also now installed VAMT on my own workstation, and scanned for machines in AD. I set in preferences to only use KMS, and specified my new kms server. I went to an already acitvated (to old server) machine and got the same message as above (the software licensing service reported that the computer could not be activated. The count reported by your Key Management Service (KMS) is insufficient.)
I could create 22 brand new virtual win7 machines, but if I created two already and it's not helping, will 22 help or not? Also, in researching the error, I found a site called woshub.com that has an article with a script to increase your kms server current count. But I don't know if this is safe to do.
There seems to be some weird timewarp/blackhole stuff going on. When your client issue an activation request/renewal (which occurs at sppsvc startup and periodically every 7 days and as a result of using slmgr.vbs /ato), the client will;
- perform auto-discover via DNS, if it has no KMShostname cached locally in registry
- if in an unlicensed state, will report that state to the KMShost and attempt activation
- if in a licensed state, will report that state to the KMShost and attempt to renew/extend
Your cumulative request counters seem to be ticking over normally, but the client seems to be getting a "50" response from somewhere - which can't be the new KMShost because that isn't sitting on "50".
Have you rebooted the old KMShost? Maybe yours *does* need a full reboot? (annoying but needs to be done, I think)
(this is one reason why I never install extra goop on DC's. The extra goop gives trouble and then you end up needing to nuke the OS and then rebuild a DC, with all that entails)
Yes, I know we don't always have the luxury of not-shared-DC's, so don't always have that choice.
On the old KMShost, there should be absolutely no need to "remove" the pkey with the /upk command. It's not recommended, it can lead you down a different but no less nasty rabbit hole.
The old KMShost should no longer display any KMShost details if you slmgr.vbs /dlv on that old guy. If it *does* show any KMShost current_count/requests count details - you've not fully demoted it, and it will continue to service client requests to the best of its ability.
Generally, KMS is dumb as a bag of hammers - its quite a simple critter, in truth.
Don [doesn't work for MSFT, and they're probably glad about that ;]
Wednesday, February 17, 2016 8:59 PM
So besides deleting its VLMCS entry in DNS and disabling kms DNS publishing, & restarting software protection service, which I did, what else is necessary to "demote" the old KMS servers? (besides rebooting, which I would need to plan downtime for) Did I miss something obvious ?
Can I change server kms port # to something else, where client may not then find it?
Of course I could uninstall Volume Activation role via Server Manager, but will that cause the same potential issues you mention as removing the pkey via /upk command?
Wednesday, February 17, 2016 9:45 PM
Don, so unfortunately I did just reboot one of the old KMS servers and slmgr /dlv on it still comes up with all statistics. (current count, etc etc.)
In frustration, I turned on the firewalls and disabled inbound rule for kms port 1688.
Per this Microsoft-authored article they say to change the kms host key to a client key, then activate it. They're not saying to do a /upk, only /ipk's. So is this the missing thing that I need to do? :
Thursday, February 18, 2016 5:30 AM | 1 vote
Don, so unfortunately I did just reboot one of the old KMS servers and slmgr /dlv on it still comes up with all statistics. (current count, etc etc.)
In frustration, I turned on the firewalls and disabled inbound rule for kms port 1688.
Per this Microsoft-authored article they say to change the kms host key to a client key, then activate it. They're not saying to do a /upk, only /ipk's. So is this the missing thing that I need to do? :
Yep, just /ipk with the appropriate KMSclient pkey and then /ato (he should go looking for your new KMShost guy)
Don [doesn't work for MSFT, and they're probably glad about that ;]
Thursday, February 18, 2016 3:13 PM
Disabled firewalls again. Tried just the -ipk with this key: D2N9P-3P6X9-2R39C-7RTCD-MDVJX found here: https://technet.microsoft.com/en-us/library/jj612867%28d=printer%29.aspx ,
and then ran slmgr -ato, & got "Error 0xC004F074 The Software Protection Service reported that the computer could not be activated. No Key Management Service (KMS) could be contacted. Please see the Application Event Log for additional information".
Application event log (on the old server) shows the old kms server is still looking for itself as the kms server, even though I'd deleted its VLMCS entry in DNS (its also a dns server) and input the new kms server from the other domain. I can ping the new kms server fine. Did ipconfig /flushdns and same result. Telnet to the kms server/port connects (get blank screen)
So, I did end up doing the /upk and /cpk, then -ipk and -ato, as detailed in link below, but it still did not help.
These domains have a two-way, external, non-transitive trust. (I'd set this up to migrate users with ADMT between domains and that was all it needed) From what some say online though, kms shouldn't care about trusts. Just that its in DNS and on your KMS server you've done the DNSdomainpublishlist reg entry to specify both domains.
I even removed the Volume Activation role and retried -ato, but still looking for itself as KMS server per Event log.
Restarted once more, tried activation, no change.
I really need to know a way to neuter these #@*$#% old kms servers !
Thursday, February 18, 2016 8:14 PM | 1 vote
D2N9P-3P6X9-2R39C-7RTCD-MDVJX is the KMSclient pkey for WS2012R2 Standard. I thought your old KMShost was WS2008R2 ?
If the old KMShost is running WS2008R2, you must use the matching client pkey of these:
Windows Server 2008 R2 Standard |
YC6KT-GKW9T-YTKYR-T4X34-R7VHC |
Windows Server 2008 R2 Enterprise |
489J6-VHDMP-X63PK-3K798-CPX3Y |
Windows Server 2008 R2 Datacenter |
74YFP-3QFB3-KQT8W-PMXWJ-7M648 |
Windows Server 2008 R2 for Itanium-based Systems |
GT63C-RJFQ3-4GMB6-BRFB9-CB83V |
KMS isn't AD-aware nor AD-dependent in any way, so domain membership, trusts, etc aren't pertinent.
KMS defaults to relying/assuming DNS publishing and discovery will be used, but you can cater for that manually if you don't use DDNS for publishing or if you don't use DNS RR lookups.
If the old KMShost still has a _vlmcs._tcp DNS SRV RR, on the old KMShost, you can disable DNS publishing with slmgr.vbs /cdns
That should stop that from re-publishing into DNS.
Then manually delete that offending DNS SRV RR.
That will stop clients from discovering the old KMShost.
That won't stop existing clients which have already discovered him, from renewing with him.
Then change the pkey on that old KMShost, change it to a client pkey.
slmgr.vbs /ato, on this guy, to discover & activate to your new KMShost
Then restart the sppsvc on that old KMShost.
Check it again with slmgr.vbs /dlv all
Check the DNS RR has not reappeared.
There *should not* be any need to block inbound TCP1688 on that old KMShost after this is done, because this guy will no longer be able to respond to client activation/renewal requests.
This will cause any existing clients to be refused renewal to this old guy, those clients will then clear their own local host cache, perform re-discovery via DNS, will be referred to the new KMShost, and attempt activation to the new KMShost.
Sorry if I'm repeating myself, but that's how it has always worked for all the implementations I've done, and for others who I've guided through this.
Don [doesn't work for MSFT, and they're probably glad about that ;]
Thursday, February 18, 2016 9:36 PM
Don, yes, one of my old kms servers IS 2008r2, and another that is in a diff domain that is 2012r2. I was probably looking at the former in an earlier post, but later mentioned the latter, and began focusing on that as I noticed it also was licensing clients still. This "other" domain (and the kms server running on it) I anticipate going away in the near future, so I definitely want that KMS server cut off now. Unfortunately, as I said, I even went as far as removing the Volume Activation role on this one, after already trying all steps you outline.
The problem is this old server has an event in its own application event log indicating it's still trying to contact itself as the kms server: "The client has sent an activation request to the key management service machine. Info: 0xC0020017, 0x00000000, myselfoldserver.def.com:1688, SOMELONGNUMBER, 2016/02/18 20:23, 0, 5, 0, SOMELONGNUMBER,5
I emailed Microsoft (we can open web incidents at least) so I'll see if their support is any good or not.
Friday, February 19, 2016 7:47 AM
good call. that was going to be my next suggestion. let us know how that works out
Don [doesn't work for MSFT, and they're probably glad about that ;]
Friday, February 19, 2016 6:03 PM
Not so good an experience so far. They emailed me back at 3 a.m.! this morning (seems to be China support as with moderators on here), and when I responded to the email, I got an auto-response saying their hours are Sun-Thursday. (What the? Microsoft is off on Fridays?) So now I won't hear back until Monday. I got the same stale documentation links thrown at me, and he seems to be jumping the the conclusion (just because they're VMs) that somehow the CMIDs are not unique, which I know is not the case, so I'm having to prove it to him with screenshots. This also makes no sense since even the old kms servers are activating the clients fine, and a new VM not cloned from a master cannot activate to the only kms server in DNS (my new one). My new server today shows both "Current Count" and "Requests with License Status Licensed" at 8 (was 6 yesterday) though, so a couple more machines DID successfully activate. It just will take a while to get to the 25 since the other 2 old servers continue to serve the clients.
Tuesday, February 23, 2016 8:12 PM | 1 vote
Could it have been the prior use of slmgr.vbs /skms ??
Could /ckhc be useful ??
[the below is from my Win10 pc, so some of the arguments might now be available on older platforms...]
Volume Licensing: Key Management Service (KMS) Client Options:
/skms <Name[:Port] | : port> [Activation ID]
Set the name and/or the port for the KMS computer this machine will use. IPv6 address must be specified in the format [hostname]:port
/ckms [Activation ID]
Clear name of KMS computer used (sets the port to the default)
/skms-domain <FQDN> [Activation ID]
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.
/ckms-domain [Activation ID]
Clear the specific DNS domain in which all KMS SRV records can be found. The specific KMS host will be used if set via /skms. Otherwise default KMS auto-discovery will be used.
/skhc
Enable KMS host caching
/ckhc
Disable KMS host caching
OK
Don [doesn't work for MSFT, and they're probably glad about that ;]
Wednesday, February 24, 2016 6:30 PM | 1 vote
Although I don't recall, I suppose its possible I may have done a SLMGR on my master months ago when I built it, if it wasn't getting activated.
I disk email him about /ckhc or maybe that followed up by /skhc, but he didn't want me to deviate from his steps.
Following his steps though, as a test, for just two VMs:
On both of them, the GPO I set up deleted the “KeyManagementServiceName” reg entry just fine. Also both still showed as Activated in computer properties.
On one VM, /dlv showed the new KMS server name just fine under “DNS Auto Discovery”. However, on the other VM, under “DNS Auto Discovery” it says “KMS name not available” I even restarted it and same thing.
A /dlv output from the new kms server shows DNS publishing IS (still) enabled. A check in DNS also shows it (still) exists there. I'll need to wait until tomorrow for his reply to see what he says about this inconsistency.
Thursday, February 25, 2016 3:55 AM | 1 vote
Apparently it just needed to sit for several hours or so. The failing machine is finally showing the new KMS server under “DNS Auto Discovery”. And the current count is up to 32 now on the new kms server. Looks like that reg entry being stuck in there was the issue!
Thursday, February 25, 2016 8:16 PM
Apparently it just needed to sit for several hours or so. The failing machine is finally showing the new KMS server under “DNS Auto Discovery”. And the current count is up to 32 now on the new kms server. Looks like that reg entry being stuck in there was the issue!
Ick :(
I'll check on a few machines in my fleet, to see if I have any of this going on - I don't need this kind of torture
Thanks for sharing this story with us, glad you got it sorted out!
Don [doesn't work for MSFT, and they're probably glad about that ;]