Freigeben über


KMS Host Client Count not Increasing Due to Duplicate CMID'S

Hello, my name is Scott McArthur. I am a Senior Support Escalation Engineer in the Windows group and today’s blog will cover an issue involving KMS activation and deployment of images. This issue seems to be more prevalent today due to the various tools used to clone images, create images based on a templates, Physical to Physical (P2V) tools, etc...

Generally the symptom you will see is that the count on your KMS host will not show the correct number of clients or it will not increase.

There are a number of reasons why this can occur. For example:

  • Not running sysprep /generalize on your image. Note that sysprep /generalize is required when creating an image. See KB162001 for more information
  • Running sysprep with unattend.xml that contains the <SkipRearm> setting set to 1. It is not recommended to create images with this setting but if you do use it you must set it to 0 or remove it before you reseal the image for the final time

To determine if you are encountering this you can use the Key Management Service Log do the following:

1. On your KMS host open Event Viewer
2. Right click the Key Management Service Log and choose “Save all events as”
3. Change the Save as type to Text(Tab Delimited)(*.txt)
4. Save the file as KMS.TXT
5. Close out of the Event Viewer completely
6. Open Excel
7. Click File, Open, and browse to KMS.TXT
8. You should see the Text Import Wizard. Choose the following options
Delimited
Start Import at Row: 8
Delimiters: Comma
9. When complete the data may look all messed up. Don’t worry we will correct that
10. Click the upper left of the spreadsheet to select the entire spreadsheet
11. Click Data, Sort, In the Sort By selection choose “Column D”
12. When complete you should see the data sorted in columns.

The Client Machine ID (CMID) is how we uniquely identify a KMS client. When sysprep is run one of its jobs is to generalize this GUID so when the image is deployed every machine has a unique CMID. Here is an example output

Column C-Computername

Column D-CMID

TEST-03.contoso.com

01eb9985-230c-49ad-a8c2-c24914da4739

TEST-04.contoso.com

01eb9985-230c-49ad-a8c2-c24914da4739

TEST-02.contoso.com

01eb9985-230c-49ad-a8c2-c24914da4739

TEST-01.contoso.com

01eb9985-230c-49ad-a8c2-c24914da4739

From this output you can see that multiple computernames have the same CMID. Each computer should have a unique CMID. This means that sysprep /generalize was not used to prepare these computers for deployment. So to KMS those 4 machines appear as one. That what be why the count would not be increasing or not reflect the true number of machines deployed.

While it is possible to run slmgr.vbs /rearm to reset the machines CMID that does not leave the machine in a supported state. Images deployed without using Sysprep to prepare the image are not supported by Microsoft. Sysprep executes ~30 sysprep providers. These providers are written to correct issues with various components when you duplicate the installation. By not running sysprep it is unknown what types of issues you could encounter and many components will be in a broken state. The supported solution is to rebuild the image using the Sysprep /generalize switch and redeploy the systems.

Thanks for your time. Stay tuned to our blog for more Activation and Deployment Topics.

Scott McArthur
Senior Support Escalation Engineer
Microsoft Enterprise Platforms Support

Comments

  • Anonymous
    January 01, 2003
    I also had issues with the counter which was not increasing.
    This had to due with which was on 1.

    After changing that it went fine. Thanks a lote for your help!
  • Anonymous
    November 10, 2010
    Hi Scott,The only problem with the scenario you described is the fact that the /generalize switch causes the installed windows 7 machine to hang on reboot.Sure, the problem only occurs if I run generalize after having installed all the software and applications we require in the workstations base image. If I run generalize on a clean installation of W7 the generalize runs nicely and the machine reboots without problems.There are some post in the net referring to this problem, usually identifying the problem with the presence of registry keys over a certain size, but none giving an answer other than not installing the offending software in the first place...Since we already started deploying non generalized syspreped images, I can see that we will have the very problem that you mention. Now if you were to be so kind as to pull a solution out of your sleeve for the post software install generalizing problem , then it would all work nicely.Thanks for the postRegardsAlex Castilho
  • Anonymous
    November 12, 2010
    Excellent post.  This explains why my activations weren't increasing correctly and once they got to 5 I was suprised that an hour later they dropped back to 4!CheersGerg
  • Anonymous
    November 17, 2010
    Hi,After fresh installation with VL Disc of Windows 7, I customized and prepared unattend.xml with WAIK. I did not include SkipRearm command in sysprep. Ones everything as I wish I used the following command;sysprep.exe /oobe /generalize /unattend:unattend.xmlAfter restart collected following results:1-CMIDs did not changed, they all remained same!2-SIDs succesfully changed3-Default profile successfully customizedSo why generalize switch did not change CMIDs?Kind regards
  • Anonymous
    December 28, 2010
    Excellent post. That fixed my problem. I didn't notice that the  <SkipRearm>1</SkipRearm> was enabled by default!
  • Anonymous
    July 20, 2011
    This does not apply to Windows XP SP3 machines.  SYSPREP for Windows XP does not have a genralize option and every Office 2010 installation still gets the same CMID.I do not install Office 2010 on the source machine at all.  It is installed clean via ZENworks when it connects to our network.  However, we still get duplicate CMID on all workstations and our license count does not go up at all.I know you can run the OSPPREARM command to "REARM" Office but once it has registered with teh KMS server, it will retain the CMID it had originally even after it is changed.
  • Anonymous
    March 27, 2012
    Amazing blog...Really very helpful.
  • Anonymous
    April 10, 2012
    Hi Scott,Thanks for the update. Can you please provide more information on Citrix provisioning.We have an environment where in virtual machines are getting provisioned using Citrix.We made it sure that the golden image is "sysprepd /generalize" however still there is an issue with the KMS count.The count is still not increasing.Please refer to the following links to know what kinf of setup do we have.support.citrix.com/.../CTX127123support.citrix.com/.../CTX124106support.citrix.com/.../CTX129105
  • Anonymous
    May 16, 2013
    I like how a white paper was written my an 'MS legend' to prove duplicate SIDs doesn't matter.blogs.technet.com/.../3291024.aspxWhich was the whole reason why I stopped using the NewSID utility.But now CMID does? Isn't that the SID? I'm confused.
  • Anonymous
    October 27, 2013
    Daniel Conley 16 May 2013 12:07 PMI like how a white paper was written my an 'MS legend' to prove duplicate SIDs doesn't matter.blogs.technet.com/.../3291024.aspxWhich was the whole reason why I stopped using the NewSID utility.But now CMID does? Isn't that the SID? I'm confused.Daniel, if you read the whole white paper, the last paragraph talks about other ID's that microsoft uses that if they are duplicated, you will experience problems...like WSUS, and in this case, KMS. And the guy who wrote that article is a legend of MS.
  • Anonymous
    February 21, 2014
    Google with mom focused vmh go home ito
  • Anonymous
    March 01, 2015
    even now, this still saved me. thanks so much
  • Anonymous
    August 16, 2015
    What will happen while recreating virtual desktops of collection?
    In this all the old virtual machines are deleted and created new virtual machines using new image(Sysprep generalized). Will the kms client count increase in this situation?
  • Anonymous
    May 17, 2017
    Excellent post. fixed my problem. thanks