Understanding Microsoft Volume Licensing

Throughout my career I've battled with Microsoft licensing as have many of you.  I've heard lot's of complaints about it from almost everyone I've ever worked with.  It's extremely confusing, extremely complex, and it's one of those evils that we have to live with, sort of like toe fungus.  It just never goes away. I've worked with volume licensing and KMS (Key Management Server) for years.  I've never fully understood how it worked, it just sort of did. It's taken me years to truly understand this thing and now that I have I want to document it for anyone else struggling to understand it.  This is for my own reference if for no one else.
I always wondered about that warning (see image below) that you got when adding what I always thought was a valid VL key to a server was.  Now I finally get it, and all the servers I've built over the years with a CVLK key that were never intended to be licensing servers.  Thankfully almost all of those were development servers that would be deleted by now.

I've included links to Microsoft docs that refer to where I got the information.  Its a bit spotty in that it references a lot of different versions of Windows but it all works the same. 

Here is the kindergarten version of how it all works:

http://technet.microsoft.com/en-us/library/jj612867.aspx

Computers that are running volume licensing editions of Windows 8.1, Windows Server 2012 R2, Windows 8, Windows Server 2012, Windows 7, Windows Server 2008 R2, Windows Vista, and Windows Server 2008 are, by default, KMS clients with no additional configuration needed.

If you are converting a computer from a KMS host, MAK, or retail edition of Windows to a KMS client, install the applicable setup key (GVLK) from the tables at http://technet.microsoft.com/library/jj612867.aspx.  All GVLK keys are blocked on the Internet based Microsoft clearinghouse and therefore cannot be used to activate any systems except in a KMS environment.

To use the keys listed there (which are GVLKs), you must have a KMS host running in your deployment first.

By default, Windows and Office volume license editions install a Generic Volume License Key (GVLK). The GVLK enables Windows and Office to automatically discover and activate against your KMS host or Active Directory infrastructure.

What this tells me is that when installing Windows via Volume Licensed DVD media the installation should by default (automatically) include the GVLK license that is used within a Volume Licensed environment.  In theory you should not need to push these out to client machines, it should occur automatically.  The GVLK key must be explicitly pushed to the client if it is being converted from MAK or Retail to VL.

By default you shouldn’t need to do anything assuming you have a properly licensed and function KMS server in your environment.  New clients should automatically register and activate as long as they can detect the DNS record of a KMS server.  At the same time pushing the GVLK out to volume clients causes no issues since that's they key they "should" have anyway.

Proof here:

http://technet.microsoft.com/en-us/library/dn502535.aspx

By default, the Windows 7 and Windows Server 2008 R2 and later operating systems use KMS for activation. In volume installations, the setup key is installed by default, which makes the system a KMS client. If you are converting a computer from a KMS host, MAK, or retail edition of Windows to a KMS client, install the applicable setup key (GVLK) from Appendix A: KMS Client Setup Keys by using slmgr /ipk <setup key>.

Volume Licensing Overview:

https://www.microsoft.com/Licensing/servicecenter/Help/FAQDetails.aspx?id=157

http://www.microsoft.com/licensing/activation/existing-customers/product-activation.aspx

Volume Activation is a product activation technology used to activate Windows Vista, Windows Server 2008, Windows Server 2008 R2, Windows 7, Office 2010, Windows 8.1, Windows Server 2012 R2, Windows Server 2012 R2 for Embedded Systems, and Office 2013. It enables Volume Licensing customers to automate the activation process in a way that is transparent to end users. Volume Activation applies to systems that are covered under a Volume Licensing program and is used strictly as a tool for activation; it is in no way tied to license invoicing or billing.

Volume Activation provides two different models for completing volume activations: Key Management Service (KMS) and Multiple Activation Key (MAK). KMS allows organizations to activate systems within their own network. MAK activates systems on a one-time basis, using Microsoft’s hosted activation services. Customers can use either or both activation methods in their environment. The type of key entered in the product determines the activation method. There is a third model for completing volume activation called Active Directory-Based activation.

Volume License Keys (VLK), including MAK and KMS, are issued to you under a specific license agreement and enable your organization to use the software that you have licensed.

VLKs can be used only with Volume Licensing products; they cannot be used with retail software or software that is preinstalled on a new computer (original equipment manufacturer, or OEM, products).

If your organization has fewer than 50 PCs, the best option is to use Multiple Activation Keys (MAK) with Volume Activation Management Tool (VAMT).

http://technet.microsoft.com/en-us/library/ff793432.aspx

KMS activation requires TCP/IP connectivity. By default, KMS hosts and clients use DNS to publish and find the KMS service.

KMS activations are valid for 180 days. This is called the activation validity interval. To remain activated, KMS clients must renew their activation by connecting to the KMS host at least once every 180 days. By default, KMS client computers attempt to renew their activation every seven days

The KMS service uses service (SRV) resource records (RR) in DNS to store and communicate the locations of KMS hosts. KMS hosts use DNS dynamic update protocol, if available, to publish the KMS SRV RRs.

By default, KMS clients query DNS for KMS service information. The first time a KMS client queries DNS for KMS service information, it randomly chooses a KMS host from the list of SRV RRs that DNS returns.

By default, client computers connect to the KMS host for activation by using anonymous RPCs through TCP port 1688

KMS hosts on the network need to install a KMS key, and then be activated with Microsoft. Installation of a KMS key enables the Key Management Service on the KMS host. After installing the KMS key, complete the activation of the KMS host by telephone or online. Beyond this initial activation, a KMS host does not communicate any information to Microsoft.

KMS keys are only installed on KMS hosts, never on individual KMS clients. Windows 7 and Windows Server 2008 R2 have safeguards to help prevent inadvertently installing KMS keys on KMS client computers. Any time users try to install a KMS key, they see the warning shown in Figure 1.

Each KMS key can be installed on up to six KMS hosts, which can be physical computers or virtual machines. After activating a KMS host, the same host can be reactivated up to nine more times with the same key.

KMS hosts that are running Windows Server 2003, Windows Vista, or Windows Server 2008 can be configured to support KMS clients that are running Windows 7 and Windows Server 2008 R2. For Windows Vista and Windows Server 2008, it is necessary to update the KMS host with a package with files that support the expanded KMS client.  Once the package is installed on the KMS host, a KMS key that is designed to support Windows 7 and Windows Server 2008 R2 can be installed and activated as described earlier in this guide.

By default, computers that are running Volume License editions of Windows Vista, Windows 7, Windows Server 2008, and Windows Server 2008 R2 are KMS clients, and no additional configuration is needed. KMS clients can locate a KMS host automatically by querying DNS for SRV RRs that publish the KMS service.

A MAK is used for one-time activation with Microsoft’s hosted activation services. Each MAK has a predetermined number of allowed activations; this number is based on Volume Licensing agreements and does not match the organization’s exact license count. Each activation using a MAK with Microsoft’s hosted activation service counts toward the activation limit.

Included in the Windows Automated Installation Kit (Windows AIK), VAMT is a stand-alone application that collects activation requests from several computers, and then sends them to Microsoft in bulk. VAMT allows IT pros to specify a group of computers to activate using AD DS, workgroup names, IP addresses, or computer names. After receiving the activation confirmation codes, VAMT distributes them to the computers that requested activation. Because VAMT also stores these confirmation codes locally, it can reactivate a previously activated computer after it is reimaged without contacting Microsoft. Additionally, VAMT can be used to easily transition computers between MAK and KMS activation methods.

http://technet.microsoft.com/en-us/library/dd772269.aspx

Software License Manager, sometimes referred to as SL Manager (Slmgr.vbs), is a script used to configure and retrieve Volume Activation information. The script can be run locally on the target computer or remotely from another computer, but it should be run from an elevated command prompt. If a standard user runs Slmgr.vbs, some license data may be missing or incorrect, and many operations are prohibited.
Slmgr.vbs can use Wscript.exe or Cscript.exe, and administrators can specify which script engine to use. If no script engine is specified, Slmgr.vbs runs using the default script engine, wscript.exe.

slmgr.vbs /dli    Retrieves the current KMS activation count from the KMS host. 

If no arguments are included the script will display 5 pages of available options. 

Hopefully that explanation is pretty clear.  If not let me know and I can try to edit it some more.

Variations on a theme

That last script I posted wasn't exactly what I needed.  I had to rewrite it to leave existing permissions in-tact.  The one below accomplishes the same goal without deleting all existing ACLs.  There are a few assumptions in place.  First that the local admins group will be given full control to anything we touch.  Second, the TrustedInstaller account will be given full control, even if it only had read access before.  This just makes life easier.  I also fixed the logging so that everything is logged, just in case.  The application of the new ACLs is done individually instead of via a function so that things can be better customized.

There is a reference section at the bottom that lists some permissions options available.  It's not needed by the script.

I tested this script against my PC and a few test PCs.  There don't appear to be any ill effects.  Again, use at your own risk and watch for line wrapping.

#============================================================================

#         File Name : EditRemotePermissions.ps1

#   Original Author : Kenneth C. Mazie (kcmjr AT kcmjr.com)

#                   :

#       Description : Used to adjust insecure file permissions on remote

#                   : systems.

#                   :

#             Notes : Normal operation is with no command line options.

#                   :

#          Warnings :

#                   : 

#             Legal : Public Domain. Modify and redistribute freely. No

#                   : rights reserved.

#                   : SCRIPT PROVIDED "AS IS" WITHOUT WARRANTIES OR

#                   : GUARANTEES OF ANY KIND. USE AT YOUR OWN RISK. NO

#                   : TECHNICAL SUPPORT PROVIDED.

#                   :

#           Credits : Code snippets and/or ideas came from many sources

#                   : including but not limited to the following:

#                   :

#    Last Update by : Kenneth C. Mazie

#   Version History : v1.0 - 02-19-14 - Original

#    Change History : v2.0 - 02-25-14 -   

#                   :

#===========================================================================

Clear-Host

$Debug = $True

$ErrorActionPreference = "SilentlyContinue"

$BadUsers = @("Everyone","Domain Users","Authenticated Users","Users")

$TargetList = Get-Content c:\Scripts\TargetList.txt

$PathList = Get-Content c:\scripts\PathList.txt

#$TargetList = "testbox"

#$PathList = "c:\test\new text document.txt"

If (!(Test-Path "C:\Scripts\Logs")){New-Item -Path "c:\Scripts\Logs" -ItemType directory}

Function WriteLog

{

   Param ([string]$LogString)

   Add-content $LogFile -value $LogString

   If ($Debug){Write-Host $LogString}

}

function Run-RemoteCMD {

    param(

    [Parameter(Mandatory=$true,valuefrompipeline=$true)]

    [string]$computer,

    [string]$command

    )

    begin {

        [string]$cmd = "CMD.EXE /C " +$command

          }

    process {

        $newproc = Invoke-WmiMethod -class Win32_process -name Create -ArgumentList ($cmd) -ComputerName $computer #-WhatIf

        sleep -Seconds 1

        if ($newproc.ReturnValue -eq 0 ){

            WriteLog "Command $($command) invoked Sucessfully on $($computer)"

            } #--[ if command is sucessfully invoked it doesn't mean that it did what its supposed to do it means that the command only sucessfully ran on the cmd.exe of the server ]--

        }

    }

ForEach ($Target in $TargetList){                                               #--[ Cycle through target PCs ]--

  $LogFile = "c:\scripts\logs\$Target {0:MM-dd-yyyy_HHmm}.log" -f (Get-Date)

  If (Test-Connection -ComputerName $Target){

    ForEach ($File in $PathList){

      WriteLog "--[ Target File: ]----------------------------------`n$File"

      [string]$Drive = ($File.split(":"))[0]

      [string]$File = ($File.split(":"))[1]

      $Drive = $Drive + "$"

      $CurrentTarget = "\\$Target\$Drive$File"

      If (Test-Path -Path $CurrentTarget){

        $ACL = Get-ACL $CurrentTarget                                           #--[ Record current ACL ]--

        #$ACL | format-List

        $Owner = Out-String -InputObject $ACL.Owner

        $str = (@($ACL.Accesstostring) -split '[\r\n]')

        $count =  0

        WriteLog "`n--[ Pre-existing Owner: ]---------------------------`n$Owner`n--[ Pre-existing Permissions:]----------------------"

        while ($count -lt $str.count ){

          WriteLog $str[$count]

          ++ $count

        }

        WriteLog "`n--[ Taking ownership of target file: ]--------------"

        Run-RemoteCMD $Target "takeown /f $CurrentTarget /a "                   #--[ Call remote file takeover function ]--

        $str = ,$File + $str

        $out = $File

        $count =  0

        while ($count -lt $str.count ){

          $out = $out + $str[$count] + "+"

          $ACL.SetAccessRuleProtection($True, $False)

          if ($str[$count] | Select-string "TrustedInstaller"){

            $ACE = New-Object System.Security.AccessControl.FileSystemAccessRule @('NT SERVICE\TrustedInstaller', "FullControl",  'none','none','Allow')

            $ACL.AddAccessRule($ACE)

          }

        

          if ($str[$count] | Select-string "SYSTEM"){

            $ACE = New-Object System.Security.AccessControl.FileSystemAccessRule @('NT AUTHORITY\SYSTEM', "FullControl", 'none','none','Allow')

            $ACL.AddAccessRule($ACE)

          }

                

          if ($str[$count] | Select-string "Everyone"){

            $User = New-Object System.Security.Principal.NTAccount("Everyone")

            $ACE = New-Object System.Security.AccessControl.FileSystemAccessRule @('Everyone', 'FullControl, Write, Modify', 'none','none','Allow')

            $ACL.RemoveAccessRule($ACE)

            $ACE = New-Object System.Security.AccessControl.FileSystemAccessRule @('Everyone', "ReadAndExecute, Synchronize",  'none','none','Allow')

            $ACL.AddAccessRule($ACE)

          }

  

          if ($str[$count] | Select-string "BUILTIN\\Users"){

            $ACE = New-Object System.Security.AccessControl.FileSystemAccessRule @('Users', 'FullControl, Write, Modify', 'none','none','Allow')

            $ACL.RemoveAccessRule($ACE)  

            $ACE = New-Object System.Security.AccessControl.FileSystemAccessRule @("Users", "ReadAndExecute, Synchronize", 'none','none','Allow')

            $ACL.AddAccessRule($ACE)

          }

  

          if ($str[$count] | Select-string "Domain Users"){

            $ACE = New-Object System.Security.AccessControl.FileSystemAccessRule("Domain Users",  'FullControl, Write, Modify', 'none','none','Allow')

            $ACL.RemoveAccessRule($ACE)

            $ACE = New-Object System.Security.AccessControl.FileSystemAccessRule("Domain Users", "ReadAndExecute, Synchronize",  'none','none','Allow')

            $ACL.AddAccessRule($ACE)

          }

      

          if ($str[$count] | Select-string "Authenticated Users"){

            $ACE = New-Object System.Security.AccessControl.FileSystemAccessRule @('Authenticated Users', 'FullControl, Write, Modify', 'none','none','Allow')

            $ACL.RemoveAccessRule($ACE)  

            $ACE = New-Object System.Security.AccessControl.FileSystemAccessRule("Authenticated Users","ReadAndExecute, Synchronize",  'none','none','Allow')

            $ACL.AddAccessRule($ACE)

          }

          ++ $count

        }  

        #--[ Assign Local Administrator the Full Control right ]--

        WriteLog "`n"

        $ACE = New-Object System.Security.AccessControl.FileSystemAccessRule("BUILTIN\Administrators", "FullControl", 'none','none','Allow')

        $ACL.AddAccessRule($ACE)

  

        #--[ Apply the new ACL ]--

        Set-Acl $CurrentTarget $ACL #-WhatIf

      

        # --[ Read ACL again to detect changed rights ]--

        $ACL = Get-ACL $CurrentTarget

        $Owner = Out-String -InputObject $ACL.Owner

        $str = (@($ACL.Accesstostring) -split '[\r\n]') 

        $count =  0

        WriteLog "--[ Final Owner: ]----------------------------------`n$Owner`n--[ Final Permissions: ]----------------------------"

        while ($count -lt $str.count ){

          WriteLog $str[$count]

          ++ $count

        }

  

        $ACL = ""

        $ACE = ""

      }Else{

        WriteLog " --- FILE NOT FOUND ---"

      }

      WriteLog "`n================================================================`n"

    }

  }Else{

    WriteLog "================================================================`nNoConnection to $Target`n================================================================`n"

  }

}

WriteLog "`n--[ COMPLETED... ]-----------------------------------`n"

<#

REFERENCE:

  $Access = [System.Security.AccessControl.AccessControlType]::Allow

  $Rights = [System.Security.AccessControl.FileSystemRights]::"ReadAndExecute, Synchronize"

  $Inheritance = [System.Security.AccessControl.FileSystemAccessRule]::ContainerInherit -bor [System.Security.AccessControl.FileSystemAccessRule]::ObjectInherit

  $Propagation = [System.Security.AccessControl.PropagationFlags]::None

rights:

    AppendData

    ChangePermissions

    CreateDirectories

    CreateFiles

    Delete

    DeleteSubdirectoriesAndFiles

    ExecuteFile

    FullControl

    ListDirectory

    Modify

    Read

    ReadAndExecute

    ReadAttributes

    ReadData

    ReadExtendedAttributes

    ReadPermissions

    Synchronize

    TakeOwnership

    Traverse

    Write

    WriteAttributes

    WriteData

    WriteExtendedAttributes

InheritanceFlag to any of the following:

    ContainerInherit (the ACE is inherited by child containers, like subfolders)

    ObjectInherit (the ACE is inherited by child objects, like files)

    None

PropagtionFlag to any of these options:

    InheritOnly (the ACE is propagated to all child objects)

    NoPropagateInherit (the ACE is not propagated to child objects)

    None

#>