ConfigMgrFu

Windows Activation – The KMS

A Key Management Server system is any system in your environment that you installed using a KMS key. That’s right, any system, Vista included. I have been to customers large and small who had five, ten, and more KMSs running their environment. Yikes. As I stated in part one (Windows Activation: The Basics), don’t use a KMS key unless you know what you’re doing.

KMSs respond to requests by Windows Vista and 2008 systems for activation (Windows 7 in the near future also). Unlike previous versions of Windows, all Vista and 2008 systems must be activated. Volume licensed systems have the option to be activated by an in-house KMS. These volume licensed systems locate a KMS using DNS and SRV records as described in part one of this post.

Each KMS maintains an internal counter of how many clients it has activated. The value of this counter is returned to each client when it tries to activate against a KMS. Vista clients will only activate if this value is 25 or over. Server 2008 systems will only activate if this value is five or over. The KMS does not increment the counter over 50. KMSs do not coordinate with each other, they are stand-alone systems. Thus, it is important that you design your KMS activation scheme carefully. Having multiple KMSes in an environment could prevent systems from being properly activated.

Each client that attempts activation is assigned a unique value that is tracked by both the client and the KMS. Activated clients, by default, attempt to contact the KMS every seven days; if an activated client cannot contact the KMS within 180 days, it will deactivate. Similarly, the KMS server will remove the record of an activated system if it has not heard from that system within 180 days; this may drop the number of activated systems below the five or 25 threshold causing other systems to deactivate when they next contact the KMS because the minimum activation number has not been met.

When a system contacts a KMS for activation, it also passes its product key to the KMS. The KMS validates the product key before it generates a client ID and successfully adds the client to its list of systems. The product key passed must be a valid KMS client key. Don’t confuse KMS client keys with KMS keys. KMS client keys are the generic keys that I referred to in the first part of this post. These keys will not activate against the Redmond servers and are automatically installed on volume license products. KMS client keys are freely distributable and available from Microsoft in the Volume Activation 2.0 Deployment Guide: there is only one client KMS per product for use by everyone; i.e., each organization does not get their own KMS client keys. Thus, if you’ve installed any other key on a system that you want to activate against a KMS, you must first remove the other key and install a KMS client key.

There are also four different levels of KMS server keys: client, A, B, and C. Each level dictates which editions of Windows that the KMS can activate. There is no limitation on which edition can host a KMS regardless of which key group the key is from. You should install the KMS key for the highest level of product that you are licensed for. The key groups are detailed in the following table:

KMS is a very low overhead service that is hosted by the Software Licensing service. The general recommendation is to use a core services system such as a domain controller to also be your KMS system. Because systems do not immediately deactivate if they cannot contact a KMS, high-availability and redundancy are almost non-existant concerns. In the event of a failure of the KMS system, simply set up a new one.

That’s it; it really is that simple. There are always more details, but that covers most of it.

Windows Activation: The Basics

Windows Activation, to some, has become confusing and a source of constant trouble. Why? Because they didn’t read the documentation. Gone are the days of simply inserting a CD or DVD and installing a Microsoft product. The single biggest source of confusion is the existence of two types of activation keys: KMS and MAK.

KMS stands for Key Management Service and is used to install a system hosting the KMS. A system hosting KMS activates other systems in your environment that have not yet been activated. These un-activated systems find the KMS system by looking for an SRV DNS record named _VLMCS._TCP.

KMS keys can be used on either Vista or Server 2008 systems. Once you activate a system with a KMS key, it becomes a KMS server. You do not have to install any additional roles or features to accomplish this, it is all built-in. The system will, by default, automatically register the proper DNS record automatically. The bottom line here is that if the system is not supposed to be a KMS, do not use a KMS key to activate it.

Once, the KMS is itself activated using a KMS key, it will in turn activate other systems without any further communication with Microsoft. Systems that activate against a KMS do not need to have a product key explicitly installed; a generic key is used during Windows installation. This key is stored in a file called pid.txt in the source folder on the installation media and can only be used to activate a system against a KMS. You can also get these keys for Windows editions eligible to be activated by a KMS from the Volume Activation 2.0 Deployment Guide if necessary. Note that only Vista Business and Vista Enterprise can activate against a KMS in addition to all versions and editions of Server 2008.

KMS systems do not relay their database or specific activation details to Redmond. This is not a way for Microsoft to spy on you and your organization. KMS is designed to prevent piracy of corporate keys which was very rampant with Windows XP and Server 2003. KMS is also designed  to make it very easy to activate Windows in a corporate environment: you never actually have to distribute any keys anymore once you have a KMS up and running. If you are worried about rogue installations of Windows, simply disable the automatic publishing of the DNS record. You will have to point each system manually at the KMS system for activation, but this is far simpler than having to give out and maintain keys.

MAK stands for Multiple Activation Key and is used to activate individual systems when a KMS is not feasible or accessible. Systems where an MAK is used for activation contact Redmond to activate. Each MAK can only be used a set number of times before it will not allow any more systems to be activated with it. The number of times an MAK can be used is set by the licensing folks at Microsoft and can be extended with a phone call to them.

In general, in corporate environments, MAK keys should only be used by systems that are not directly attached to the corporate network regularly; e.g., remote user’s laptops.

If you are using a KMS key on every one of your systems, stop the insanity now. KMS keys, like MAK keys, can only be activated a set number of times. You will eventually max this number out and be left in the cold. Of course you will be able to call the licensing folks at Microsoft to try to extend this, but they will probably laugh at you and ask why you didn’t read the documentation.

The following diagram shows the activation paths for the various key types used.

Part 2 of this post will cover how a KMS works and its limitations and Part 3 will cover troubleshooting KMS.

Campaign Against SCCM

No, I am not anti-Configuration Manager, quite the opposite in fact. I am against the use of the acronym SCCM for Configuration Manager. If you do a web search on SCCM you will see that although Configuration Manager does come up, it does not come up first. This is mainly because SCCM is not a registered trademark of Microsoft’s and in no official documentation does Microsoft ever refer to Configuration Manager as SCCM – the official acronym is ConfigMgr.  Yes, you will see a lot of blogs from Microsofties and others alike throwing this acronym around willy-nilly, but their use of it is just that: willy-nilly.

Note that Operations Manager is not SCOM for similar reasons. Check out this post for all the official acronyms: http://blogs.technet.com/configmgr/archive/2008/06/01/sccm-is-not-the-official-acronym-for-configuration-manager.aspx.

If you have mistakenly used this acronym in the past, repent now, never use it again, and be redeemed. You have been warned!

Build and Capture and Software Updates

A problem that crops up on the forums every now and then in addition to causing me to pull out some hair is deploying updates during a Build and Capture Task Sequence (TS). There are actually two problems that manifest themselves during a Build and Capture that don’t normally occur and both are caused because the client system is not part of the domain during the TS. The first problem is that the client cannot find the MP to initiate policy download to figure out which deployments are applicable to it. The second problem is that the client isn’t part of any boundaries and so can’t find a DP to download the updates from – I think this second problem only happens if you are using AD sites for boundaries, but I haven’t done any testing to confirm this. The first problem results in timeout errors with the error code 0x800705b4. The second problem results in no content found errors with a seemingly unrelated 0x80040669 error code.

The solution to both of these problems is not to join the system to the domain during the TS, this would cause other issues.

For the first problem, simply add SMSMP=<ConfigMgr MP FQDN> and SMSLP=<ConfigMgr SLP FQDN> (this of course assumes that you have an SLP set up) to the client Installation properties in the Setup windows and ConfigMgr task.

For the second problem, change the Download Settings for the applicable deployment to Download software updates from distribution point and install for When a client is connected within a slow or unreliable network boundary.

Old Dog, New Tricks

Well, I’m not actually that old, but I did learn a new trick today. I’ve been fighting the drivers is an OSD XP deployment task sequence for an HP dc5800. The drivers just wouldn’t load. The TS copied them down to the system properly, the DriverPaths registry value was updated properly, but the drivers wouldn’t load. After the TS completed, I could go into device manager and point the unknown devices to the folders on the C drive (C:\Drivers) and the drivers would load without any issue, they just weren’t getting automatically installed during mini-setup.

Checking the setupapi.log didn’t reveal anything except that the OS tried to find drivers for the devices but just didn’t load the ones in C:\Drivers. I tried everything that I could think of including deleting all the drivers and re-adding them to ConfigMgr, rebuilding the image, using different drivers, creating new TSes, and still nothing. I’ve implemented OSD in production environments more than a handful of times and in test environments at least as many times but had not seen this at all before: this had me really scratching my head. The problem did not appear to be with ConfigMgr though as it was definitely copying the drivers to destination system; XP mini-setup just refused to reference them, or see them, or I have no idea.

A quick web search turned up this older post: SCCM 2007 OSD Drivers Show as New Hardware Found when you Login by Brian Tucker. It was worth a shot as I was at a complete loss. Basically, I added a new command-line task near the end of the TS that runs the following command: rundll32.exe Syssetup.dll,UpdatePnpDeviceDrivers. This command reruns the PNP device setup and, from what I’ve read, is also executed during XP mini-setup.

This did fix the issue, but I still don’t really know what’s causing it. I don’t know of anything different in the image or the process as a whole. I haven’t done XP using OSD on a dc5800 before so this is the only thing I can think of that is different; I’ve done Vista on a dc5800 without any issues though. I still think ConfigMgr rocks!