No announcement yet.

KMS on Server Core 2008 R2

  • Filter
  • Time
  • Show
Clear All
new posts

  • KMS on Server Core 2008 R2

    Hi guys,

    I just had to play a bit with KMS on Server Core and it seems to be working well, so I wrote a small guide on my blog ( ).

    I figured I would post it here in case anyone searches about it

    Here is the full text for search purposes, sorry for the formatting I just copy pasted.

    As many companies have skipped Vista and may be starting to migrate to Windows 7, the need for servers running KMS (Key Management Services) is going to be felt for many of them.

    KMS allows you to do the authorization/activation of Windows in-house, and allows you to get stats about what is going on. However, running this on a full blown Windows installation could be too expensive, overkill.

    This article explains the steps to get KMS working in your domain, using a Windows 2008 R2 server in Server Core mode, virtualized. Yes, it is possible to run a KMS in a VM, unlike a few years ago when the EULA explicitly stated you were not allowed to.
    Another good reason to go with Windows 2008 R2 is that it supports being a KMS for Windows 7 as well as 2008 servers. If you had a Windows 7 KMS, not only could you not run it in core mode but it would only be able to authorize workstations. And Windows 2008 first release is simply not supported.

    Create a Virtual Machine

    This VM can be in a Hyper-V environment or a VMware environment.
    As we will be running Core, the requirements are lower. I suggest starting with:
    1 vCPU
    512MB of RAM
    10GB of Hard drive (single drive)
    Low resource shares relative to your other VMs
    Install Windows Server

    Select your Windows 2008 R2 ISO from your data stores. Obviously, this article is not about that, I assume people interested in KMS know how to install Windows.
    Select the core mode.

    Windows is up – now what?

    Log into the server’s console through VMware or hyper-v (well this guide mostly works for physical servers too – I just find it’s a waste of metal !). You will be greeted by the minimal UI of Core.

    Configure the networking

    Run the sconfig command. Chose option 8.
    Select your NIC (normally number 0 if you only have one).
    Configure it with a static IP , and make sure you configure the DNS settings properly for your domain.
    KMS relies on DNS a lot so having a static IP will save you trouble in the future. Alternately depending on your setup, how you manage VLANs and IPs etc, have a reservation for it. ipconfig /all will show you the MAC address of the card, as on the standard Windows install.
    Once you’re done configuring the network, go back to the main menu of sconfig.
    Configure your Windows Update Settings

    Set it to obtain updates from Microsoft for now. Later on you will surely manage this by GPO so it does not really matter. Back to the main menu, chose option 6 to download the updates that are required right now. (As core has no Internet explorer or Windows update UI that’s the way of getting them manually).
    Configure date and time (option 9)

    Configure the hostname (option 2)

    I recommend rebooting after you changed it and before you join the domain – if the computer account is pre-staged in AD it will use the old name instead of the pre-staged one if you don’t.
    Join the domain (option 1)

    You can also use the typical netdom commands if you want to join it and force a specific OU.
    Add a local administrator

    Once the server reboots, on the domain, log in with your local admin account. Run sconfig, and use option 3 (or use net localgroup – faster!) and add a domain account to your local admins, so you can login with an AD account and manage the server. While you are there, you may want to change the local admin password (the ctrl-alt-del screen does have that option).
    Remote management

    Once the server is fully patched up, and your local admin account is secured and you can now login using a domain account, consider enabling remote management. Option 4 in sconfig allows you to enable remote powershell, remote MMC, WinRM, etc. An interesting thing you can do once this is open is open the event log remotely easily, which may be useful. Be aware that KMS is very low maintenance and that keeping everything locked down may prove more secure, but be sure your operational teams will have a way to get into the server, either through the virtualized console, powershell, or RDP (enabled in the sconfig main menu – with two options, one to allow only secure RDP clients like Vista and Win 7 or one to allow any clients, useful if you still use XP workstation).
    Enable KMS

    Enabling KMS is very simple. The only thing you will need is your “KMS Key”, which can be found on the Microsoft licensing website.
    Run this command:
    slmgr.vbs /ipk KmsKey
    You should then see a small window pop up and confirm the product has been activated.
    Now, we should activate our server, while we’re at it.
    slmgr.vbs /ato
    There we go. KMS is enabled, the server is activated. What else needs to be done?

    Well first of all, clients rely on DNS to locate the KMS. So if you do not have dynamic updates enabled, start by disabling the automated registration by running:
    slmgr.vbs /cdns
    The command to enable automatic updates (default but try it if you run into issues or change your mind) is :
    slmgr.vbs /sdns
    After running these, make sure to restart sppsvc by using net stop and net start or by using the services MMC, if you enabled remote MMC.
    If using manual DNS, create an entry with the following settings:
    Port number
    Host offering the service
    Fully qualified domain name (FQDN) of the KMS host

    Verify the DNS entry

    Manual or automated, let’s check if it worked.
    nslookup -type=srv _vlmcs._tcp.<your DNS domain>
    If this command returns the SRV record pointing to your KMS server on port 1688, it means clients will now find the KMS.
    Open the firewall

    As you noticed while creating or verifying the SRV record, the KMS, by default, is listening on port 1688. This can be changed with the slmgr.vbs command. However, no matter what port you do, you will need to open it up in the firewall. You can use netsh…
    netsh firewall set portopening tcp 1688 KMS enable
    However, the beauty of Server core is that you should never have to connect to it. For this, I highly recommend that you apply your standard Windows 2008 security baseline GPOs, and create a KMS Specific one. In this GPO, you should ensure that the KMS service is set to automated, and that this TCP port is opened.
    You can then apply further hardening to the machine, and configure Windows updates by GPO as well. As server core is not a service that is very visible to the users, this server could easily be patched and rebooted at almost any time, but you can patch it like any server that you use. Less patches will be required, as Server core does not include a lot of software that comes with the full install.

    Read the slmgr.vbs documentation for more information. slmgr.vbs /dli will show you some information, and there will be an Event Log created just for KMS where you can get useful information about activations. If you have any issues, remember to check the DNS record from the workstation you’re trying to activate, as well as test connectivity to port 1688.
    The error you receive on a workstation may seem cryptic but most of them have a good explanation, so Google them ! Remember you need at least 25 workstation licenses or 5 server licenses to use KMS, and have fun !
    VCP on vSphere (4), MCITP:EA/DBA, MCTS:Blahblah