Any KMS ninjas lurking about?

[Thee Chicago Wolf [MVP]]

Having issues getting KMS activations on my client PCs to increase the
KMS count to 25. Anyone out there successfully rollout KMS activation
successfully?

- Thee Chicago Wolf [MVP]

 

[Robert Sudbury]

Assuming you have 25 clients, and the client OS installed is using the
default KMS key that comes with the OS when you first installed it (not a
manually entered one, OEM or retail key ...)

Assuming your KMS was installed using your unique KMS key, and it properly
generated its own DNS entry.

google: slmgr windows 7 cmid
The KMS current count does not increase when you add new Windows Vista or
Windows 7-based client computers to the network
http://support.microsoft.com/kb/929829

Cut to the chase; to avoid re-sysprepping each machine in order to
generalize and generate a unique Client Machine ID or CMID on each so that
the KMS will recognize each as separate from other machines, instead from an
elevated cmd prompt, type:

slmgr.vbs -rearm

then:

slmgr.vbs -ato

When the KMS recognizes its 25th unique machine, it will pop. The first 24
clients will update their status locally at their next restart.

Or you could install/register 5 unique server OSes installed with the
default KMS key.

You will NOT see the CMID of an unactivated OS that is using the
default-installed KMS key when you use "slmgr.vbs -dlv" until after it has
been activated by your KMS.

Once your KMS is spitting out activations properly, you will notice that the
re-arm count on your KMS-activated OSes has been set to 1, even if it was 4
before you ran the commands above.

Having issues getting KMS activations on my client PCs to increase the
KMS count to 25. Anyone out there successfully rollout KMS activation
successfully?

- Thee Chicago Wolf [MVP]

__________ Information from ESET NOD32 Antivirus, version of virus
signature database 6172 (20110601) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

--
[Robert]


__________ Information from ESET NOD32 Antivirus, version of virus signature database 6172 (20110601) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

 

[Thee Chicago Wolf (MVP)]

Assuming you have 25 clients, and the client OS installed is using the

default KMS key that comes with the OS when you first installed it (not a
manually entered one, OEM or retail key ...)

Assuming your KMS was installed using your unique KMS key, and it properly
generated its own DNS entry.

google: slmgr windows 7 cmid
The KMS current count does not increase when you add new Windows Vista or
Windows 7-based client computers to the network
http://support.microsoft.com/kb/929829

Cut to the chase; to avoid re-sysprepping each machine in order to
generalize and generate a unique Client Machine ID or CMID on each so that
the KMS will recognize each as separate from other machines, instead from an
elevated cmd prompt, type:

slmgr.vbs -rearm

then:

slmgr.vbs -ato

When the KMS recognizes its 25th unique machine, it will pop. The first 24
clients will update their status locally at their next restart.

Or you could install/register 5 unique server OSes installed with the
default KMS key.

You will NOT see the CMID of an unactivated OS that is using the
default-installed KMS key when you use "slmgr.vbs -dlv" until after it has
been activated by your KMS.

Once your KMS is spitting out activations properly, you will notice that the
re-arm count on your KMS-activated OSes has been set to 1, even if it was 4
before you ran the commands above.

Cheers for the info. Will try out some of the suggestions.

 

[Peter foldes]

Thee Chicago Wolf

Read the following link. There was a few changes made to activating a KMS Key. You
can also call the concierge for more info and help

http://technet.microsoft.com/en-us/library/ff793419.aspx

and

http://technet.microsoft.com/en-us/library/ff793405.aspx

--
Peter
Please Reply to Newsgroup for the benefit of others
Requests for assistance by email can not and will not be acknowledged.
This posting is provided "AS IS" with no warranties, and confers no rights.
http://www.microsoft.com/protect

 

[Seth]

Having issues getting KMS activations on my client PCs to increase the
KMS count to 25. Anyone out there successfully rollout KMS activation
successfully?

To add to what Wolf said, make VERY sure no one is entering the KMS key into
the clients. The activation engine, when given that code, will advertise
itself as a KMS server on your network and you will need to do some clean-up
in DNS.

execute the command: nslookup -type=srv _vlmcs._tcp

to see a list of all the servers that have advertised to your DNS that they
are KMS hosts. If you see any client PCs there those will have the wrong key
entered into their activation engines. Here is a chart of the client keys
should you need to fix an existing client.

http://technet.microsoft.com/en-us/library/ff793406.aspx

These keys are safe to save as they are not specific to a customer but
rather "special" keys (that are embedded in the Windows installation disk
for the specified flavor of Windows) that tell the activation engine they
are to go to a KMS host rather than to Microsoft for activation.

All PCs will report an activation error until the KMS server has reached 25
activation attempts (from unique machines, not doing the /ATO command over
and over on the same client).

 

[Seth]

To add to what Wolf said, make VERY sure no one is entering the KMS key
into the clients. The activation engine, when given that code, will
advertise itself as a KMS server on your network and you will need to do
some clean-up in DNS.

Should have said in addition to what Robert said to Wolf...

 

[Thee Chicago Wolf [MVP]]

Thee Chicago Wolf

Read the following link. There was a few changes made to activating a KMS Key. You
can also call the concierge for more info and help

http://technet.microsoft.com/en-us/library/ff793419.aspx

and

http://technet.microsoft.com/en-us/library/ff793405.aspx

Pete,

Thanks for the info. I think I need to be mindful of the slmgr /ato
option as Seth is indicating it might be that which is tripping me up.
Cheers.

- Thee Chicago Wolf [MVP]

 

[Thee Chicago Wolf [MVP]]

To add to what Wolf said, make VERY sure no one is entering the KMS key into
the clients. The activation engine, when given that code, will advertise
itself as a KMS server on your network and you will need to do some clean-up
in DNS.

execute the command: nslookup -type=srv _vlmcs._tcp

to see a list of all the servers that have advertised to your DNS that they
are KMS hosts. If you see any client PCs there those will have the wrong key
entered into their activation engines. Here is a chart of the client keys
should you need to fix an existing client.

http://technet.microsoft.com/en-us/library/ff793406.aspx

These keys are safe to save as they are not specific to a customer but
rather "special" keys (that are embedded in the Windows installation disk
for the specified flavor of Windows) that tell the activation engine they
are to go to a KMS host rather than to Microsoft for activation.

All PCs will report an activation error until the KMS server has reached 25
activation attempts (from unique machines, not doing the /ATO command over
and over on the same client).

It could be that the /ato option is what is tripping me up. I'd set up
a simple script (below) kill the MAK key and replace it with the KMS
Client key on technet. I also initially added /rearm but it seemed to
be tripping it up as well.

slmgr.vbs -skms <my kms server>
pause
slmgr.vbs -ipk 33PXH-7Y6KF-2VJC9-XBBR8-HVTHH
pause
slmgr.vbs -ato

I also thought that because I wasn't sysprep /generalize my machines
that it could be the cause but that didn't make any difference either.
I was seeing requests for activation and reply to requests for
activation on the KMS server in the event viewer so I know that
fundamentally it is working as it is supposed to be.

This would all be SO much easier if there was a KMS client agent or a
property in TCP/IP setting where one could just set it and it would
just work. Microsoft's method is for the birds. You listening Redmond?
^_^

I will have to dig through the info and suggestions that people have
given me to see if there's something I am missing.

- Thee Chicago Wolf [MVP]

 

[Seth]

It could be that the /ato option is what is tripping me up. I'd set up
a simple script (below) kill the MAK key and replace it with the KMS
Client key on technet. I also initially added /rearm but it seemed to
be tripping it up as well.

slmgr.vbs -skms <my kms server>
pause
slmgr.vbs -ipk 33PXH-7Y6KF-2VJC9-XBBR8-HVTHH
pause
slmgr.vbs -ato

On fresh builds none of the lines above should be needed as...

A) DNS should resolve the KMS server (and you don't want this set if not
needed in case in the future you replace your KMS server with a new one with
a different name.

B) That is the key that is already embedded in the Enterprise disk so no
need to set it

C) it will do this automatically but I will admit, I force this on my builds
too.

Also, if you put cscript.exe at the beginning of each of the lines above
(and either run the script from within the System32 folder or preface the
slmgr.vbs with the full path) you can lose the "pause" statements as each
line will run in the console (no graphical popup) in order waiting for each
prior step to finish before moving on.

I also thought that because I wasn't sysprep /generalize my machines
that it could be the cause but that didn't make any difference either.
I was seeing requests for activation and reply to requests for
activation on the KMS server in the event viewer so I know that
fundamentally it is working as it is supposed to be.

sysprep clears activation settings so you shouldn't have any issues here.

This would all be SO much easier if there was a KMS client agent or a
property in TCP/IP setting where one could just set it and it would
just work. Microsoft's method is for the birds. You listening Redmond?
^_^

not sure what the complaint here is. What or how are you proposing this be
a TCP/IP setting? It's activation. Yes, it uses TCP/IP as the network
transport but that's about all that is related to networking. you could
also do it with no network connection at all by manually keying in numbers
that you get from a phone response system bypassing TCP/IP completely
(activation in general, not KMS).

I will have to dig through the info and suggestions that people have
given me to see if there's something I am missing.

Generally when KMS issues occur it is because someone thought it was and
acted is if KMS activation is more complicated than it is. Once your KMS
server is built and up and running KMS on the client side is as simple as
can be. Are you having server side problems? When you built your KMS server
did all go well with no issues?

 

[Robert Sudbury]

Since you aren't using sysprep /generalize, or slmgr.vbs -rearm, all your
clients will have identical CMID. You will see the requests go up on the
KMS, but until the KMS sees a unique CMID for each client, the
activation number won't move.

It could be that the /ato option is what is tripping me up. I'd set up
a simple script (below) kill the MAK key and replace it with the KMS
Client key on technet. I also initially added /rearm but it seemed to
be tripping it up as well.

slmgr.vbs -skms <my kms server>
pause
slmgr.vbs -ipk 33PXH-7Y6KF-2VJC9-XBBR8-HVTHH
pause
slmgr.vbs -ato

I also thought that because I wasn't sysprep /generalize my machines
that it could be the cause but that didn't make any difference either.
I was seeing requests for activation and reply to requests for
activation on the KMS server in the event viewer so I know that
fundamentally it is working as it is supposed to be.

This would all be SO much easier if there was a KMS client agent or a
property in TCP/IP setting where one could just set it and it would
just work. Microsoft's method is for the birds. You listening Redmond?
^_^

I will have to dig through the info and suggestions that people have
given me to see if there's something I am missing.

- Thee Chicago Wolf [MVP]

__________ Information from ESET NOD32 Antivirus, version of virus
signature database 6175 (20110602) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

--
[Robert]


__________ Information from ESET NOD32 Antivirus, version of virus signature
database 6175 (20110602) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com




__________ Information from ESET NOD32 Antivirus, version of virus signature database 6175 (20110602) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

 

[Thee Chicago Wolf (MVP)]

Yes, these machines are not in AD or domain so they've been imaged
from a sole image. I have tried -rearm and even sysprep /generalize. I
see the CMID's have changed but still no bump in count. Am I just
being impatient? I thought the count should bump up on request for key
from KMS almost instantly.

 

[Robert Sudbury]

Something else to look out for, which I banged my head into again today.

Check the client clock. Ensure the time and day/date/year are all accurate.
If the clock is off (like this latest batch of laptops I have coming in at
13 hours into the future) KMS will fail to activate them... Timesync will
also fail btw, it's too far off.

BTW, what sort of events are being generated in your server's KMS event log?

Yes, these machines are not in AD or domain so they've been imaged
from a sole image. I have tried -rearm and even sysprep /generalize. I
see the CMID's have changed but still no bump in count. Am I just
being impatient? I thought the count should bump up on request for key
from KMS almost instantly.




__________ Information from ESET NOD32 Antivirus, version of virus
signature database 6185 (20110606) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

--
[Robert]


__________ Information from ESET NOD32 Antivirus, version of virus signature database 6185 (20110606) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

 

[Thee Chicago Wolf [MVP]]

Something else to look out for, which I banged my head into again today.

Check the client clock. Ensure the time and day/date/year are all accurate.
If the clock is off (like this latest batch of laptops I have coming in at
13 hours into the future) KMS will fail to activate them... Timesync will
also fail btw, it's too far off.

BTW, what sort of events are being generated in your server's KMS event log?

Although I am not the Admin of the KMS server, in working with the
Admin we both saw request and reply to requests for KMS activation so
it seems the clients are talking to the server. I can get some
specific event IDs. I didn't remember seeing any yellow bangs or red
bangs though.

- Thee Chicago Wolf [MVP]