Windows Server и клиентские лицензии Per-Device RDS CAL

Недавно, перебираясь на новый сервер лицензирования служб терминалов Remote Desktop Licensing на базе Windows Server 2012 с Windows Server 2008 R2 вспомнил про проблему, описанную в посте форума TechNet трёхлетней давности Terminal Services Licensing Warnings. На старом сервере лицензирования RD Licensing к настоящему моменту был настоящий бардак в смысле отображения имён клиентских компьютеров, получивших лицензии. Виной тому является информация хранящаяся на клиентских компьютерах в ключах реестра:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSLicensing\HardwareID
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSLicensing\Store

Не хотелось повторять ситуацию с именами клиентов на новом сервере лицензирования, и поэтому было решено немного углубиться в этот вопрос. В процессе изучения вопроса узнал для себя пару полезных утилит, которые на сегодня имеют уже почтенный возраст и найти их можно в пакете Windows Server 2003 Resource Kit Tools

Утилита Terminal Server Client License Test tool (Tsctst.exe) запускается на клиентском компьютере с одним единственным ключом /A и позволяет в читаемом виде получить информацию, хранящуюся в выше указанных ключах реестра.

По каждой хранящейся в реестре лицензии TS/RDS CAL можно увидеть полную информацию о дате получения, сроке действия, сервере лицензирования и типе лицензии (License ID):

A02-5.00-EX - Windows 2000 TS CAL from the “Built-in” pool.
A02-5.00-S - Windows 2000 TS temporary or permanent CAL.
A02-5.02-S - Windows server 2003 TS temporary or permanent CAL.
A02-6.00-S - Windows server 2008 TS/2008 R2 RDS temporary or permanent CAL.

Другая утилита Terminal Services Licensing Reporter (Lsreport.exe) позволяет получить более подробную информацию о выданных клиентских лицензиях с точки зрения самого сервера лицензирования.

Пример команды для построения отчета о всех выданных лицензиях включая информацию о клиентском HardwareID 

LSREPORT /W /F C:\Temp\LSReport.txt LICSERVER01

Итак, если на протяжении цикла жизни клиентского компьютера менялось его имя, то может получиться так, что в выше указанных ключах реестра будет храниться устаревшая информация и передаваться в таком же виде на сервер лицензирования, что в конечном итоге может привести к путанице и неразберихе. В качестве решения этой проблемы, да ещё и с учетом перехода на новый сервер лицензирования, может оказаться полезным выполнение очистки устаревшей информации из реестра на всех пользовательских компьютерах. Под очисткой подразумевается удаление соответствующих ключей реестра с добавлением прав на запись в родительский ключ, для того чтобы в дальнейшем у пользователей не возникло проблем с регенерацией этой информации в контексте их прав. Для решения этой задачи после ряда экспериментов получился следующий PowerShell скрипт:

$REGKey = "HKLM:\SOFTWARE\Microsoft\MSLicensing"
$ACLRKey = Get-ACL $REGKey
[string]$SDDL = $ACLRKey.Sddl
IF 
(-NOT($SDDL -match "(A;CI;CCDCLCSWRPRC;;;)(IU|BU)")){
Write-Host "ACL need to be update..."
# S-1-5-4 (Interactive) / S-1-5-32-545 (Users)
$RUser = New-Object System.Security.Principal.SecurityIdentifier("S-1-5-32-545")
$RList = [Enum]::Parse([Security.AccessControl.RegistryRights], "SetValue, CreateSubKey, ReadKey");
$RType = [Enum]::Parse([Security.AccessControl.AccessControlType], "Allow");
$RFlagInh = [Enum]::Parse([Security.AccessControl.InheritanceFlags], "ContainerInherit");
$RFlagPro = [Enum]::Parse([Security.AccessControl.PropagationFlags], "None");
$Rule = New-Object System.Security.AccessControl.RegistryAccessRule($RUser,$RList,$RFlagInh,$RFlagPro,$RType)
$ACLRKey.AddAccessRule($Rule)
Set-ACL $REGKey $ACLRKey
}
Remove-Item -Path $REGKey\* -Recurse

Скрипт получает список разрешений на родительский ключ реестра HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSLicensing и если в списке отсутствуют разрешения для групп Interactive Users (IU) или BUILTIN Users (BU), то добавляются разрешения для группы интерактивных пользователей, дающие право создания под-ключей и установки значений, после чего происходит рекурсивное удаление всего содержимого указанного ключа реестра.

Скрипт выполняется на клиентских компьютерах в контексте системы (с полным набором прав). Доставку и запуск скрипта на клиентских компьютерах можно спланировать с помощью разных методов и средств, например GPO или SCCM.

После этого, при следующем подключении к терминальным серверам, клиенты заново сгенерируют идентификационную клиентскую информацию и отправят её на сервер лицензирования RDS с новым запросом на получение клиентской лицензии. Разумеется, желательно тщательно спланировать этот процесс, чтобы не получилось так, что в один момент на сервере лицензирования попросту не останется свободных клиентских лицензий, так как каждый клиент будет занимать по две лицензии. Именно поэтому самым удобным моментом для такого “наведения порядка” может стать перевод клиентов с одного сервера лицензирования на другой.

Дополнительные полезные источники информации:

• VirtualizationAdmin.com - Troubleshooting Terminal Server Licensing Issues (Part 1)
• VirtualizationAdmin.com - Troubleshooting Terminal Server Licensing Issues (Part 2)
  
• VirtualizationAdmin.com - Troubleshooting Terminal Server Licensing Issues (Part 3)
  
• VirtualizationAdmin.com - Troubleshooting Terminal Server Licensing Issues (Part 4)
  
• TechNet Library - Configuring a Computer for Troubleshooting Terminal Server Licensing
  
• KB315262 - How to transfer Terminal Services CAL from one client computer to another