KMS Clients are not auto discovering the new KMS server (that is servering for two domains)

If these are already activated machines, it is default behavior to attempt to renew the activation against the server that already issued the activation.  Since activations aren't transferrable, this is perfectly normal.  If a machine fails to renew, it will attempt to activate using the KMS methodology including the DNS records you've set up (unless the behavior was forced/overridden via registry during earlier activation) and will find the new KMS server just fine.

Unfortunately many KMS deployments were done and shortcuts were taken, so I do see where someone was impatient and didn't want to troubleshoot so they did manual configurations.  Which obviously overrides any automated process. Which means I cannot speak any specifics about the success in your environment.  I can only speak to default behaviors.

DNS record for KMS host is obtainable with

nslookup -type=srv _vlmcs._tcp

Select allOpen in new window

I came out for a similar issue with the following, please let me know if it solves your issue

# disable caching DNS 
 slmgr.vbs /ckhc  
 # clean name set up with  /skms switch and reactivate DNS autodiscovery 
 slmgr.vbs /ckms 
 # re-enable caching DNS
 slmgr.vbs /skhc 
 # activate!!
 slmgr.vbs /ato
 # verify client has taken correct name for kms  
 slmgr.vbs /dlv  

Select allOpen in new window

in case the above does not work a fixed ip or fqdn can be set up with

slmgr.vbs /skms:1.2.3.4

Select allOpen in new window

references:
https://blogs.technet.microsoft.com/odsupport/2011/11/14/how-to-discover-office-and-windows-kms-hosts-via-dns-and-remove-unauthorized-instances/

Thank you both.  
@Michelangelo
I appreciate the script and I tried each one of those commands prior to even posting.  If I do not set the KMS server on the clients machine the auto discovery will revert back to the original server.


@Both
I am going to wait this how for a bit and see if machines start trying to activate on the new KMS.  

If you do not mind I am going to leave this open for a week of so.
I will follow up with my findings and maybe someone might have a definitive answer to this.

I think I need to statically set this on the clients to redirect them.  There are no more DNS settings for the old KMS Host.  There are DNS settings for new host, but the clients still want to talk to the old host unless I force them to speak to the new one.

This can happen when someone used registry entries (forced or otherwise) to "manually' point to a KMS server.  I find these in the field every so often, and it usually gets attributed to the last IT guy who "couldn't get it to work" any other way (and invariably is found to be a configuration issue.)

As I recall, the VAMT tool lets you do this, but I can't say for certain anymore.  If its only a few machines, you can do so manually.  If you have many machines, you may have to script it or go to GPO.

slmgr has a flag that basically does the same thing. If the server name is provided, it is setting the registry entry manually on the back end, which seems to be how many of these machines get in this state.

I am using slmgr to do the setting.

I am pretty sure any freshly imaged machines do automatically find the KMS via the dns. It is only existing machines that still call back to the older KMS.

Well, the slmgr documentation is here:

https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/dn502540(v=ws.11)

A few things to note:

The default behavior is the client caches the server it last contacted, but it *will* contact a new server if the old server fails.

This option enables KMS host caching (default), which blocks the use of Domain Name System (DNS) priority and weight after the initial discovery of a working KMS host. If the system can no longer contact the working KMS host, discovery will be attempted again.
This operation must be run from an elevated command prompt.

If you *ever* use the /skms flag, you will no longer be able to rely on DNS.  I suspect this is what has happened with your older clients.

his option specifies the name and, optionally, the port of the KMS host computer to contact. Setting this value disables auto-detection of the KMS host.
If the KMS host uses Internet Protocol version 6 (IPv6) only, the address must be specified in the format [hostname]:port. IPv6 addresses contain colons (:), which will be parsed incorrectly by the Slmgr.vbs script.
This operation must be run from an elevated command prompt.

In other words *DON'T* use skms.  Just. Don't.

Instead, use the ckms flag on the clients that aren't working right.  That *clears* the hardcoded server name, and they'll revert to default DNS behavior.  And will allow you to migrate KMS in the future without hitting this issue again in the future.

This option removes the specified KMS host name, address, and port information from the registry and restores KMS auto-discovery behavior.
This operation must be run from an elevated command prompt.

Note that this is also *Exactly* in line with my very first comment:

f these are already activated machines, it is default behavior to attempt to renew the activation against the server that already issued the activation.  Since activations aren't transferrable, this is perfectly normal.  If a machine fails to renew, it will attempt to activate using the KMS methodology including the DNS records you've set up (unless the behavior was forced/overridden via registry during earlier activation) and will find the new KMS server just fine.

So even though the DNS is not pointing to the old host anymore, but the host is still on accepting requests old clients will still attempt be successful with registering.  If I shutdown the old KMS Host and there is a proper DNS to the new Host the existing clients will attempt to make a call out and being that there is no response the client will then look at DNS to try and find a Host?

Correct. You can test this behavior by shutting down the old host and then using slmgr to attempt a reactivation (ato as I recall) and see it hit the new server. As long as skms was not used to manually specify a server.

Also note that if the new server has not hit minimum client counts, it'll increase its request count but will not activate the client. That is also normal (as it is in any KMS environment,  it just a migration one.)

I may have one or two machines, but a majority of them leveraged DNS originally.
The OS activation has hit the proper count of 25 WS and 5 Servers, but my Office 2010 only hit 3.  
I will turn off the older host and see what happens.


Thanks Cliff (Always a good source with details ;) )

Cliff do you know the Service that I can stop so the KMS Host stops responding, but I do not have to shutdown the server?

Not off the top of my head, and am not in a placenwhere I could dig in. I would guess a "volume license" service or similarly named service.

Cliff thanks for the suggestion of shutting down the old KMS host.  I was a bit fearful as well assumed that the DNS change would have trumped the re-activation to the Old server, but I guess not.  I shutdown the old server and I saw the license count increase to 9 for 0ffice and will monitor for the next few days,

Thanks for the for your time.  

-Mike-