August 9, 2010, 11:05 am
Yes, the KMS client activation is supported in multi-domain environment in which the KMS host belongs to one domain and needs to cater to the clients in others.
For this to work, you need to create a ‘multi-string value’ registry key under “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SoftwareProtectionPlatform” called “DNSDomainPublishList” on your KMS Server.

When done, restart the “Software Protection” sppsvc service on your KMS host and watch for the Event ID 12294 log under application logs. You should one event for each domain you have asked KMS to publish itself in.

Additionally, under each domain you can use NSLookup to verify the _vlmcs SRV record.
nslookup -type=srv _vlmcs._tcp
KMS communication happens over TCP Port 1688, if the domains you have added are in other region and you would like to verify if clients can talk to your KMS host, then from a client on the other side use PortQry to ascertain that port is not being blocked
portqry –n FQDN_of_your_host –e 1688 –p both
If the environment does not support Dynamic DNS, then SRV Resource Records can be manually created to publish the KMS host.
The KMS SRV RR is created under TCP node of your DNS Domain.

On how to setup and configure KMS Server/host a Server Core, see my other post.
Other details can be found under Technet Library : http://technet.microsoft.com/en-us/library/ff793419.aspx
December 23, 2009, 4:49 pm
Server Core seems to be the perfect candidate for installing KMS. Key Management Service mediates your Volume Licensing with Microsoft Activation Services and acts as the man-in-the-middle for the activation for all your KMS clients that comprise of Vista, Windows 7, Windows Server 2008 and R2. With Windows 7 and Windows Server 2008 R2, what you have in KMS is Volume Activation 2.0. In contrast with KMS, what you have is MAK that stands for multiple activation key. MAK is targeted for clients that stay off the network whereas KMS is designed for your internal clients. Following I have a simple overview design of how it works.

My Windows Server 2008 R2 Server Core has a very small footprint, it is a single processor/20gb hd/512mb ram machine. The first thing you need is the KMS Host key from your Microsoft Volume Licensing site or from your TAM.
The command to register the machine as the KMS host is slmgr /ipk <your key>

Once it is registered, you need to activate the host itself. Run slmgr -ato
You can check the status and brief description of the KMS host by running slmgr –dli

The verbose information is provided via slmgr –dlv

Once KMS is setup, it will register its SRV record in DNS. You can verify from your workstation if it has done so via,
nslookup -type=srv _vlmcs._tcp
From then on clients will automatically be reverted to your KMS host for activation but as hinted in the drawing above, starting with Windows 7 and 08 R2, the minimum threshold (activation attempts/requests) that are needed to fully activate the KMS host is 25 Vista/Windows 7 clients or 5 Server 2008 (R2). This number can comprise of virtual and physical loads, previously this was limited to physical systems only. The slmgr -dlv will show you the total requests received.
Note that the KMS is desgined to let you better manage your internal activation for compliance reason. Micrsoft does not go receive any internal information from between the KMS host and KMS client. KMS has you abide your EA Volume Licenseing, check the VL Product Groups shown in the diagram that are pertinent for your environment. I find the group B to be most commonly required.
Important note : Installing/configuring the KMS does not open up the pertinent firewall port (default port 1688). From running “slmgr -dli” you will notice that it says that the KMS is listening on port 1688 but the rule is not enabled so you may do so like this.
netsh advfirewall>FIREWALL add rule name=”KMS” dir=in action=allow protocol=tcp
localport=1688
Ok.
For more information see this link.