IT Certification and Training Blog

2.2 Activation

2.2.1 Volume Activation

Each installation of Windows 7 must be activated. It is a legal requirement for ensuring that an instance of the operating system is legitimate. There is a 30-day initial grace period, during which you can make up your mind. If you are using Windows 7 for evaluation, testing, or software development and you need to frequently reinstall it and start afresh, you can extend the grace period up to three times by running the following command:

slmgr –rearm

But once you are out of grace, you are legally required to either scrap the installation or activate it.

How does the activation work? If you purchase your computer with Windows 7 already preinstalled, the original equipment manufacturer (OEM) will most likely have taken care of it for you and you won’t need to do anything else. If you install Windows 7 yourself, then activation is your responsibility. If it is a consumer edition on your home computer, you need to enter a retail product key and then initiate an activation either over the Internet or by telephone. If you are an IT pro and your company has a volume licensing (VL) agreement with Microsoft, you will use one of two volume activation (VA) methods.

Under your VL agreement, you can purchase a multiple activation key (MAK) with the requisite number of activations. Essentially, MAK activation works in the same manner as retail activation, except for the fact that you can use the same key for as many activations as you have paid for.

The second VA method is called Key Management Service (KMS). All VL editions of Windows 7 have a built-in publicly known KMS client key. To use KMS activation, you need to purchase a special KMS key and use it to activate a computer that will become a KMS host. When a KMS client computer is started for the first time, it will try to locate the KMS host by using DNS and will submit an activation request. And here comes a tricky part. You need to have at least 25 Windows 7 KMS clients before the KMS host will activate any of them, and the activation is good for only 180 days. Furthermore, in merely seven days, an already activated KMS client becomes restless and attempts to reactivate itself. If it succeeds, the 180-day count starts over and the client stays happy for another seven days. If a reactivation attempt fails, the client will keep trying every couple hours until it succeeds. And each time the KMS client connects to the KMS host, there better be enough other KMS clients around or the activation attempt can fail. The KMS host remembers each KMS client that submitted an activation request within the last 30 days. If your network is not very large and if clients are constantly on the move, it’s OK to occasionally have fewer than 25 KMS clients around, for relatively short periods of time. But you should strongly encourage everyone to come online at least once per month, and no one should be allowed to stay off the network for more than 180 days in a row.

If you work for a large company and there are thousands of KMS clients on your network, don’t think that you are necessarily in the clear. You might be up against a different challenge. Chances are one KMS host might not suffice and you might need to implement a few more. This is not uncommon, especially considering that the same KMS key is good for up to six KMS hosts. Each KMS host attempts to register an SRV record with DNS so that KMS clients can automatically discover the KMS hosts. By default, in an Active Directory Domain Services (AD DS) environment, an AD DS–integrated DNS zone supports only secure dynamic updates. The default permissions allow any domain computer to register itself and then to update its registration but do not allow computers to update one another’s records.

Suppose you need to implement two KMS hosts, and suppose their names are KMS1 and KMS2. When you configure KMS1, it will automatically register an SRV record named

 _vlmcs._tcp.DomainName

This record will include the name of KMS1 and the TCP port on which KMS1 will listen for client requests. The default permissions for this record will prevent any other KMS hosts from registering their own SRV records, which all have the same name but contain different information. Generally, attempts to register any additional SRV records with the same name are considered as updates to the first record. Therefore, without the default permissions being changed, any KMS hosts subsequently implemented in the same domain cannot create their SRV records for KMS in the domain. To enable KMS clients to automatically discover KMS2, you should assign KMS2 the Allow – Full control permission for the SRV record created by KMS1. Then KMS2 will be able to register a second, its own SRV record.

And one more tip. In some situations, you might be tempted not to leave anything to chance and to manually create all the necessary SRV records yourself. If you do so, then keep in mind that you will own those records and, unless you change their default permissions, only you will be able to update those records in the event if you ever need to configure any of the KMS hosts to use a different TCP port, if you replace any KMS hosts, or if you add new ones.