Update adds support for Windows 8 and Windows Server 2012 to Windows Server 2008, Windows 7, and Windows Server 2008 R2 KMS hosts

Reading Time: 2 minutes

WGAI’ve written before on Active Directory-based Activation. This new activation method allows domain-joined Windows 8 clients and Windows Server 2012-based member servers to be activated and deactivated automatically based on their domain membership.

I’m very fond of this feature. However, for many enterprise organizations, Active Directory-based Activation is beyond their reach for numerous reasons.


Why not use Active Directory-based Activation

Organizations may not be able to use Active Directory-based Activation, because:

  • They do not want to manage two activation environments
    Only Windows 8, Windows Server 2012 and Office 2013 can be activated through Active Directory-based Activation. When an organization is planning to support both the latest and greatest and earlier versions, KMS will be needed for these older versions and administrators might not opt to manage two solutions.
  • They use an alternative Directory Service
    When an organization doesn’t use Active Directory, it doesn’t mean they can’t have centralized activation. It just means they can’t use Active Directory-based Activation.
  • They want to restructure their Active Directory environment
    When an organization is planning to restructure their Active Directory environment with the Active Directory Migration Tool (ADMT), the organization may be better off holding off their Active Directory-based Activation implementation until after the restructuring.
  • Activation is not part of the Active Directory team’s responsibilities
    When an organization has strictly separated responsibilities between teams, activation will not be part of the responsibilities of the Active Directory team. Depending on the situation, Active Directory admins will not respond favorably to these added responsibilities and the person(s) responsible for activation will need to stick with their current activation solution.


Stick with Key Management Services (KMS)

In most of these cases, Key Management Services (KMS) will remain the default Windows Activation method.

In order for these organizations, however, to activate Windows 8 and Windows Server 2012, their existing Key Management Services (KMS) infrastructure may need to be updated. They can either be upgraded to Windows 8 or Windows Server 2012 KMS Hosts, or updated with the update from Microsoft KnowledgeBase article 2757817.

This update applies to:

  • Windows Vista with Service Pack 2
  • Windows Server 2008 with Service Pack 2
  • Windows 7 with Service Pack 1
  • Windows Server 2008 R2 with Service Pack 1

A KMS host key that is associated with Windows client operating systems cannot be installed on Windows server operating systems, and vice-versa. This is true for all Windows operating systems except for Windows Server 2003.

Windows Server 2003-based KMS Hosts are no longer supported to activate Windows 8 and/or Windows Server 2012-based hosts.

Related KnowledgeBase article

Update adds support for Windows 8 and Windows Server 2012 to Windows Server 2008, Windows 7, and Windows Server 2008 R2 KMS hosts

Related Posts

Windows 8 Migration Checklist
Whitepaper: What’s New in Active Directory Domain Services in Windows Server 2012
New features in AD DS in Windows Server 2012, Part 16: Active Directory-based Activation

2 Responses to Update adds support for Windows 8 and Windows Server 2012 to Windows Server 2008, Windows 7, and Windows Server 2008 R2 KMS hosts


    I have a problem. Simple domain users also have access to make any client machine, a member of domain. In my view this option should be just for server administrator or domain admins or those who are assigned this permission.

    How can I stop this, so normal domain users cannot make any client a domain member.


    You're right. Authenticated users are able to join ten machine accounts to the domain. This is by design and described in Microsoft KnowledgeBase article 243327.

    If you want to prevent users from joining machine accounts to the domain, you can restrict this using Group Policy as described in the Microsoft TechNet Forums by my fellow Directory Services MVP Marcin Policht:

    Launch GPMC, locate Default domain controllers GPO, use the Edit option to open it in GP Editor, and remove Authenticated Users (or any other group that the user is a member of) from the list of security principals with Add workstations to domain user right (Computer Configuration / Windows Settings / Security Settings / Local Policies / User Rights Assignment)

    In addition, make sure that the user account that performs the join does not have "Create Computer Objects" and "Delete Computer Objects" permissions to the container/OU where the computer account is being created. If that's the case, remove permissions from the container/OU.

leave your comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.