• ABBYY FineReader 9.0 - Решаем проблему высвобождения конкурентных лицензий

    Есть у нас в обороте старенькая версия ABBYY FineReader 9.0 с небольшим количеством конкурентных лицензий и сервером лицензирования. Сервер лицензирования выдаёт клиентским компьютерам лицензии при запуске ПО на этих компьютерах, а при исчерпании пула лицензий клиент получает сообщение о невозможности запуска приложения. Распределение лицензий происходит по простому принципу "кто первый встал, того и тапки", и как-то всегда хватало приобретённого количества лицензий на всех. Однако в последнее время специалисты тех.поддержки стали фиксировать жалобы пользователей на участившиеся ситуации с нехваткой лицензий.

    Читать далее...

  • Windows Server 2012 R2 – Обновляем KMS сервер для активации Office 2016

    imageУ нас уже есть действующий KMS сервер, развёртывание которого мы рассматривали ранее в заметке Windows Server 2012 R2 - Разворачиваем KMS для Windows и Office. Недавно стала доступна RTM версия пакета Microsoft Office 2016, и поэтому настало время для расширения нашего KMS сервера возможностью активации новой версии Office.

    Читать далее...

  • Windows Server 2012 R2 – Обновляем KMS сервер для активации Windows 10

    imageРанее мы рассматривали пример того, как на базе Windows Server 2012 R2 организовать KMS-сервер активации Windows 7/8/8.1, Windows Server 2008 R2/2012/2012 R2 и Office 2010/2013. В этой заметке мы дополним наш действующий KMS-сервер возможностью активации новой клиентской ОС – Windows 10.

    Читать далее...

  • Нацеливаем сервера RDSH на RD Licensing с помощью Group Policy Preferences

    imageВ обычной ситуации, для того чтобы централизованно нацелить все сервера с ролью Remote Desktop Session Host (RDSH) на использование какого-то конкретного сервера лицензирования RD Licensing, используются стандартные параметры объектов групповых политик (GPO) из состава Административных шаблонов, конкретнее за это отвечают параметры:

    Computer Configuration > Policies > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Licensing

    - Use the specified Remote Desktop license servers
    - Set the Remote Desktop licensing mode

    Читать далее...

  • Windows Server 2012 R2 - Разворачиваем KMS для Windows и Office

    imageНачиная внедрять в инфраструктуру новые системы Windows 8.1 и Windows Server 2012 R2, одна из первых вещей, о которых стоит задуматься – это активация новых систем, и поэтому первый сервер, который мы разворачиваем на Windows Server 2012 R2, будет у нас выступать в качестве сервера Key Management Service (KMS). В нашем случае, текущим сервером KMS является сервер на базе Windows Server 2012. Этот сервер настроен на активацию систем до уровня Windows 8/Windows Server 2012, а также обеспечивает активацию Office 2010/2013. Перед нами стоит задача перенести функционал KMS на новый сервере на базе Windows Server 2012 R2.

    Читать далее...

  • Управляем клиентами KMS с помощью GPP

    imageПри автоматической публикации серверов Key Management Service (KMS) в DNS в территориально распределённых инфраструктурах может возникнуть ситуация, когда клиенты обращаются к KMS-серверам на удалённых площадках, в то время как есть более близкий сервер. Поэтому может возникнуть необходимость направить определённые группы клиентов на конкретные KMS-сервера и сделать это можно с помощью ключей реестра…

    Читать далее...

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

    imageНедавно, перебираясь на новый сервер лицензирования служб терминалов 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 и позволяет в читаемом виде получить информацию, хранящуюся в выше указанных ключах реестра.

    image

    По каждой хранящейся в реестре лицензии 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) позволяет получить более подробную информацию о выданных клиентских лицензиях с точки зрения самого сервера лицензирования.

    image

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

    LSREPORT /W /F C:TempLSReport.txt LICSERVER01

    image

    Итак, если на протяжении цикла жизни клиентского компьютера менялось его имя, то может получиться так, что в выше указанных ключах реестра будет храниться устаревшая информация и передаваться в таком же виде на сервер лицензирования, что в конечном итоге может привести к путанице и неразберихе. В качестве решения этой проблемы, да ещё и с учетом перехода на новый сервер лицензирования, может оказаться полезным выполнение очистки устаревшей информации из реестра на всех пользовательских компьютерах. Под очисткой подразумевается удаление соответствующих ключей реестра с добавлением прав на запись в родительский ключ, для того чтобы в дальнейшем у пользователей не возникло проблем с регенерацией этой информации в контексте их прав. Для решения этой задачи после ряда экспериментов получился следующий 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

  • Microsoft Office 2010 KMS Host на Windows Server 2012

    image_thumb_5_74F1491DПри попытке установки службы Key Management Service (KMS) для Microsoft Office 2010 на Windows Server 2012 можно получить сообщение о том, что данная операционная система не поддерживается – Unsupported operating system

    image

    Ничего удивительного в этом нет, ибо даже на странице загрузки Microsoft Office 2010 KMS Host License Pack честно сказано:

    Windows Server 2012 and Windows 8 are not supported at this time

    Весьма удручает то обстоятельство, что даже после официального выхода RTM Windows Server 2012 не появилось никакой новой информации по этому вопросу, что само по себе останавливает процесс полного перевода KMS-серверов на новую ОС.

    Здесь описано неподдерживаемое Microsoft решение, которое позволит запустить службу KMS Office 2010 на уже работающем KMS-хосте на базе Windows Server 2012.

    После неудачного запуска исполняемого файла KeyManagementServiceHost.exe даже несмотря на несовместимость ОС в каталог ProgramFiles (x86)MSECacheOfficeKMS распаковываются все файлы необходимые для KMS Office 2010:

    image

    Проверка версии ОС выполняется в файле kms_host.vbs. Откроем этот файл в тектовом редакторе и в 34 строке заменим переменную folder = "unknown" на folder = "win7r2". Это будет означать что в результате проверки версии ОС, скрипт в любом случае будет считать что выполняется на Windows Server 2008 R2. 

    image

    После этого запустим скрипт на выполнение командой:

    cscript kms_host.vbs

    …и убедимся в том что скрипт успешно выполнит развёртывание служебных файлов KMS Office 2010 и предложит ввести ключ для активации:image

    Вводим ключ продукта и убеждаемся что он успешно “проглочен” службой и активирован через Интернет.

    image

    Проверить статус текущей KMS лицензии Office 2010 можно командой

    Slmgr.vbs /dlv bfe7a195-4f8f-4f0b-a622-cf13c7d16864

    image

    После этого служба KMS Office 2010 будет работать на Windows Server 2012 точно также как и на Windows Server 2008 R2, хотя ещё раз хочу подчеркнуть, что такое решение не является официально поддерживаемым Microsoft.

  • Устанавливаем Microsoft Office 2010 KMS Host

    imageВ этой заметке мы установим службу Key Management Service (KMS) для Microsoft Office 2010 на сервер где уже выполняется служба KMS раздающая ключи для Windows 7 и Windows Server 2008 R2. Предполагается что у нас уже имеется KMS-ключ для Office 2010, полученный с веб-узла Microsoft Volume Licensing Service Center (VLSC). На данный момент он фигурирует там под названием "Office 2010 Suites and Apps KMS".

    Читать далее...

  • Пакетное изменение редакции Office Visio 2010

    imageИнсталляционной пакет Microsoft Office Visio 2010 содержит в себе все редакции – Premium, Professional и Standard, и та редакция которая будет установлена, определяется в зависимости от используемого ключа продукта. Забавно то, что по умолчанию Visio 2010 устанавливается с ключом продукта редакции Premium. Можно столкнуться с ситуацией когда в организации объём оплаченных текущих лицензий Visio разрешает лишь использование редакции Standard, а на клиентских компьютерах ранее была развёрнута конфигурация по-умолчанию – редакция Premium. Если вы начнёте изучать вопрос смены редакции уже установленных экземпляров Visio 2010, то можете обнаружить несколько вариантов решения вопроса, например с помощью Volume Activation Management Tool (VAMT) 2.0 или скрипта Ospp.vbs, как это описано в статье  MSDN Blogs - Visio Insights - Volume Activation for Visio 2010 Explained. Однако в интернете можно найти свидетельства (и эксперименты это подтверждают) того, что при применении подобных методов смены редакции в системном реестре полноценно не меняется информация о редакции установленного продукта. Например в оснастке Add/Remove Programs информация о редакции Visio будет неактуальной и отчёты того же SCCM будут отображать соответственно старую редакцию.

    Читать далее...