11/11/2022 0 Comments Restarting kms client windows 10Repeat steps 3-6 until activation succeeds.ģ: Success! I now have a working KMS server!Ĥ: Sure enough, I have the minimum count.Repeat activation attempts until you receive the correct failure message. Attempt to activate it (slmgr.vbs /ato) Note: it attempting to activate right after a restart, it may fail without the “count reported” error.Repeat the cycle with enough patience, and you end up with the KMS server enabled and handing out Activation tokens.ġ: Client is unable to Activate not enough clients of the same type.Ģ: Server only shows 14 unique clients must be >25 for desktop OS With a little experimentation (and the ability to roll back a VM to a previous state, thanks to snapshots!), you can see for yourself that the same VM will attempt to Activate with a different CMID after each sysprep (+rearm longer to complete) or rearm (slmgr.vbs /rearm + reboot). So, where does one learn about this magical CMID? In the Event Viewer for the KMS server:Įvery time a KMS client requests Activation, the KMS server caches the request and logs it in the Event Log. The CMID is set during initial install, when license keys are modified, during the ‘sysprep’ generalization process (when ‘rearm’ is enabled, as it is by default), or during manual rearming. This is not the same as the SID, the Activation ID, or any other identifier or UUID visible on the client with the ‘slmgr.vbs’ command. The KMS server keeps a record of the clients that request Activation it identifies them uniquely by the “Client Machine ID” or CMID. Unfortunately, there are several other scenarios where you will have challenges either enabling the KMS server to activate desktops, or keeping it activated later, due to a) the way you’re generating your VDI desktops, or b) the total of desktops you want running in your environment. When you already have KMS in the environment and have a sufficient number of physical systems to keep the KMS server activated, it’s pretty straightforward: KMS “just works” for VDI. By the same token, however, using MAK in virtual desktop infrastructure (VDI) is problematic because of the hard limit for activations that Microsoft imposes on MAKs. Although there are a lot of benefits to using KMS over MAK, one of the standout reasons for selecting MAK over KMS-at least for desktop OS-is the necessity of having at least 25 systems under activation. In a previous article, I wrote about the virtualization administrator’s interest in choosing between the two operating system activation methods Microsoft ® offers: Multiple Activation Keys (MAK) and Key Management Service (KMS).
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |