Note that the KMS key isn’t a MAK. Don’t
give this key out indiscriminately; it’s good
for only six activations, intended for six KMS
instances or rebuilds, for your entire company.
Each of these instances can be reactivated
as many as nine times. After you
install the KMS key, you must activate it with
Microsoft. This action authorizes, by proxy,
all the activations the KMS host will perform.
The most common way to activate the KMS
host is by directly contacting Microsoft via the
Internet. This method is called online activation,
and is executed simply by entering
SLMGR.VBS -ato
If your KMS host doesn’t have Internet
access, you can call Microsoft and follow a
mostly automated activation process. To find
the Microsoft number to call, enter
SLUI.EXE 4
and follow the on-screen instructions.
KMS Location and
Discovery
After your KMS host is up and running, your
clients must be able to find it. You can forcibly
point the clients to the host (called a direct
connection), or you can let clients find the
host themselves (called auto-discovery). To
set up direct connection on a KMS client,
simply run
SLMGR.VBS -skms [:]
on the client. KMS_FQDN is the Fully Qualified
Domain Name (FQDN) of the KMS host
(or you can enter its IP address). You can also
specify what port the client should connect
to, if it’s other than the default of 1688.
Auto-discovery is a more complicated
matter. For auto-discovery, KMS uses the DNS
SRV record to publish its service into a DNS
zone. Following the _service._protocol format
of the SRV record, a record for KMS would
look like _vlmcs._tcp.mycompany.com.
When it performs auto-discovery, the
KMS client queries DNS for a list of servers
that have published the _VLMCS record for
the zone it’s a member of. DNS returns the
list of KMS hosts in random order, and the
client picks one and attempts to establish
a session with it. If this attempt works, the
client caches the server and attempts to use
it for the next renewal attempt. If the session
setup fails, the client picks another server at
random. The KMS locator process works a
little like the domain controller (DC) locator
process (which also looks for an SRV record),
but it’s simpler. For example, the client can’t
look up KMS hosts by site because doing so
isn’t necessary for the simpler requirements
of the KMS service. Nor does KMS use weight
and priority, which are options available in
the SRV record to sort the result list.
A KMS host configured for auto-discovery
doesn’t automatically publish SRV records
to DNS in any zone other than the one
in which it resides. This means you must
manually publish SRV records into all other
DNS zones—for example, the other child
domains in a domain tree. To do so, you
must enter each zone KMS should publish
to in the HKEY_LOCAL_MACHINE \SOFT
WARE\Microsoft\Windows NT\Current
Version\SL\DnsDomainPublishList subkey’s
REG_MULTI_SZ value. Use a separate line to
enter each zone in which you want KMS to
publish itself. Remember that the KMS host
itself must have rights in the target zone to
create these records, and that the zone must
be able to resolve the host name in the SRV
record. If you have many domains—especially
domains that don’t trust the domain
your KMS host resides in—this configuration
can become one more manual list that must
be kept in sync with your active domain list.
KMS auto-discovery is integrated with DNS, not Active Directory (AD); it works just
as well with non-Windows DNS as it does
with AD-integrated DNS. Any DNS server
that supports SRV records (per RFC 2782)
and dynamic updates (per RFC 2136) will
support KMS client auto-discovery and KMS
SRV record publishing. BIND 8.x and 9.x support
both SRV records and DDNS.
KMS Odds and Ends
A KMS host itself doesn’t provide much
information about its operation. Instead,
a Microsoft Operations Manager (MOM)
management pack for KMS is available at
the Microsoft downloads Web site (www.microsoft.com/downloads). The management
pack generates alerts for the major conditions
that can cause KMS-related activation
problems, such as initialization failures and
DNS SRV record publishing failures. It also
provides a wide range of reports on client
activations through KMS.
Once activated, a KMS host will activate
an unlimited number of clients. However,
the host won’t begin activating clients until
it receives a certain number of activation
requests from physical (i.e., not virtual)
machines. This is called the activation threshold.
Vista’s threshold is 25 systems, whereas
Server 2008’s threshold is 5 systems.
Suppose you have an environment with
500 volume-licensed Vista systems and one
KMS host on a shared production network.
As these systems begin appearing on the
network, they will attempt to activate with
the host they’ve found, either through autodiscovery
or direct connection. The host will
record each attempt, but not activate the
clients until 25 separate clients have contacted
it. The original 25 clients, when not
activated by the KMS host, will simply retry
until the KMS host has reached its activation
threshold, at which point they’ll be activated
normally. These thresholds are exclusive for
each type; if KMS has reached its 25-client
Vista threshold but not its 5-client Server
2008 threshold, it won’t activate Server 2008
servers until that threshold is reached.
A KMS host doesn’t track all its licensed
clients; it records only the last 50 activations
to make sure the service is working correctly.
It also doesn’t pay attention to other KMS
hosts in the network or share activation information
between them. No upper limit exists
for how many activations a KMS host can
perform after it reaches its activation threshold; volume licenses aren’t a limited resource
on its network. As many as six KMS hosts can
be activated with one VLK, and each KMS
host can be reactivated as many as nine times
(e.g., if a KMS host must be rebuilt).
Using KMS rather than a MAK solution to
activate clients has several advantages. First,
KMS clients don’t need Internet or telephone
access to activate their systems; they just need
to be able to communicate with a KMS host.
Second, there’s nothing to back up or restore
on a KMS host. You simply rebuild, reinstall
the VLK, activate, and it’s ready to go. Third,
the KMS infrastructure is very lightweight
and scalable; one KMS host with a hot spare
in case of failure can service many tens of
thousands of clients. Ultimately, the deciding
factor for how many KMS hosts you use isn’t a
matter of scalability; it’s your network configuration
and your political landscape. If a substantial
number of your clients can’t contact a
KMS host because of network segmentation,
you’ll have to land another host. And because
KMS is a critical part of your infrastructure,
strongly independent business groups might
want control over their own KMS host.
Continue on Page 3
Register
GennBo October 04, 2008 (Article Rating: