Partial KMS Activation blocking?
-
2011年4月4日 下午 12:39In 2 to 3 months, a group on our domain will have their own EA with Microsoft. I want to see if it is possible to block their access to automatic KMS activation on our KMS server without losing the DNS "_VLMCS" entry that allows automatic activation of our existing 800 computers. I want to force them to use their own MAK activation codes and not register on our KMS server. All their computer and user AD objects are under a specific OU. Is there a way to block KMS activation for these users or computers either through policy or DNS?
所有回覆
-
2011年4月4日 下午 01:39
There is a whitepaper that describes the tasks to accomplish this (http://technet.microsoft.com/en-us/library/cc723923.aspx), but there might be a couple of easier workarounds:
1. If these users are on their own network or in a specific ip range you can use a firewall rule on the KMS server to deny access to KMS service port (default 1688).
2. If the group's computers are deployed using the MAK key they will not look for a KMS server. This will of course only apply to computers deployed correctly.
- 已標示為解答 Nick Wan 2011年4月7日 上午 08:03
-
2011年4月8日 下午 05:06
Unfortunately options 1 and 2 won't work. Some of our users are on the same subnet as them. They have the original media for Windows and Office, I can't force them to install using Office transforms and such.
I'll look through the whitepaper and see if I can get something to work.
Unfortunately as an added complication... our KMS server is the same server as our WSUS server... I don't want to block their access to wsus.
I appreciate the help!
-
2011年4月14日 下午 02:51
Unfortunately the whitepaper won't work either. That requires Windows Firewall which is disabled on our network. We have an entry point firewall.
I'll figure something out.
-
2011年4月15日 上午 08:23
Another method you might want to look into is to run cscript ospp.vbs /sethst:dummy.host and /setprt:123 on all their computers. That way if they attempt to activate with KMS, they will not go to DNS and they'll try to activate with a dummy host. Activation will fail.
More info on ospp.vbs:
http://technet.microsoft.com/en-us/library/ee624350.aspx#section1
If you can't run the script remotely on all the computers under that specific OU, then one option is using Group Policy to specify the registry key for setting the KMS host and port. Unfortunately there is no explicity policy setting to do this, so you'll have to set the registry key yourself.
Ted Way [MSFT], Program Manager, Microsoft Office: Enterprise Licensing, Group Policy, and 64-bit Office -
2012年4月24日 下午 03:21
That doesn't work either. All I get is a windows activation dialog saying nothing but "An error has occurred".
Nice try tho.
- 已編輯 Gary E Thompson 2012年4月24日 下午 04:04
-
2012年4月25日 上午 06:04
That doesn't work either. All I get is a windows activation dialog saying nothing but "An error has occurred".
do you mean the /sethst and /setprt attempt failed?
or the attempt succeeded and the pc was configured for dummy KMS, but then MAK activation failed?it sounds like it will be tricky to differentiate these machines which will use VL media but need MAK, given you have KMS with DNS in place.
is there some way you can convince them MAK adds value to them so they will want to do it rather than KMS?
or, KMS activate them and leave it be?
(i'm not clear on why KMS activation for these machines is an issue? if they are licensed, then it doesn't matter whose pkey they use)Don
-
2012年4月25日 上午 11:48
It sounded like a very good idea, but when I execute the command on a PC, I get "An error has occurred". I think the VBS script is attempting to locate the dummy server and failing. Something about the RPC service not enabled. As a test, I gave it the hostname of a valid server (that wasn't the KMS server) and it gave me the same error. The command works fine if I give it the actual KMS server settings. It must be looking for the KMS service on the dummy server. If it can't contact it, it fails and does nothing.
It doesn't look like the /sethst is just a blind setting, the script actually tries to validate the setting... which kinda defeats the purpose.
The problem is we have a VL for Office, but not apps like Visio or Project. They insisted on being able to support themselves but they don't bother to check things like licenses. They have the media for Apps like Visio and install it whenever they want... and since they're on our domain, our KMS server is activating them automatically.... which I'm trying to stop... but we have hundreds of valid licenses ourselves and KMS is a big help... so I'm kinda stuck.
Looks like we'll have to stick to old fashioned training and convincing them not to do it... probably go over their heads if they persist.
-
2012年4月26日 上午 11:01
Hmm,
I haven't tried this, but maybe you could try setting a dummy via a registry key/value?
http://technet.microsoft.com/en-us/library/ff793431.aspxanother option might be that you un-publish your KMS from your DNS, disable auto-publish, and then you specify your KMS on all your deployments. those guys can't auto-discover the KMS.
extra work for you at deployment time and machine refresh, but at least you don't need to re-visit your existing deployments.
Don
- 已編輯 Don - tesgroupMicrosoft Community Contributor 2012年4月26日 上午 11:04
-
2012年4月26日 下午 12:17
The registry key option is definately worth looking at, and it can easily be pushed through SCCM or GP.
I was considering doing all KMS authenticating manually, and we might end up going that route if it gets out of hand.
I'm still considering the options. I appreciate the help!
.png)
