Нужна ли активация windows server 2012
Обновлено: 02.07.2024
С выходом Windows Server 2012 Microsoft серьезно пересмотрела правила лицензирования, с учетом последних тенденций в отрасли. В частности, уделено самое пристальное внимание виртуальным средам, а также существенно изменена продуктовая линейка. Надо сказать, что это пошло только на пользу, схема стала намного проще и понятнее, сохранив при этом общие принципы лицензирования. Самое время познакомиться с предметом более подробно.
Изменения встречаю нас уже в прайс листе, по сравнению с Windows Server 2008, который имел целых шесть редакций (не считая версии для Itanium) и два специальных выпуска для малого бизнеса, Windows Server имеет всего две основных редакции и два выпуска для малого бизнеса.
Начнем с последних. Редакции Foundation и Essentials предназначены для самого малого бизнеса и лицензируются на сервер с числом пользователей 15 и 25 соответственно, кроме того Foundation доступен только в OEM канале. Обе редакции не имеют прав на виртуализацию и не предполагают никакого расширения, при выходе за лимиты вам придется заново лицензировать как сервера, так и пользователей.
Основными редакциями являются Standard и Datacenter. Еще одна хорошая новость - функционально обе редакции полностью одинаковы и отличаются только лицензионными условиями. Также изменился объект лицензирования, если предыдущие выпуски лицензировались на сервер, то Windows Server 2012 лицензируется по количеству процессоров. Одна лицензия покрывает два процессорных сокета в пределах одного физического сервера, одиночный сокет также рассматривается за два.
В чем же разница? Разница в правах на виртуализацию. Одна лицензия Standard дает право запуска двух виртуализированных экземпляров на хосте, Datacenter позволяет запускать неограниченное количество виртуальных машин. При этом Standard, как и редакции Server 2008, позволяет, в случае запуска двух виртуализированных экземпляров, использовать физический экземпляр ОС только для обслуживания виртуальных машин, Datacenter таких ограничений не имеет.
С точки зрения лицензирования пользователей ничего не изменилось, каждый пользователь или устройство, явно или опосредованно использующий службы и приложения размещенные на сервере должен иметь лицензию клиентского доступа на пользователя или на устройство (CAL).
Остановимся более подробно на лицензировании серверов и правах на виртуализацию. Рассмотрим следующую схему:
Теперь посмотрим на правую часть схемы. Там у нас также четырехпроцессорный сервер, но под управлением VMWare ESXi. В этом случае нам также следует сначала лицензировать процессорные сокеты, а потом уже докупать лицензии для виртуализированных экземпляров. Проще говоря, не важно под управлением какой ОС работает хост, правила лицензирования от это не меняются.
Также существенно изменились правила использования предыдущих версий (downgrade). Если раньше OEM версии позволяли понижать выпуск только для предыдущего, то теперь это ограничение снято, вы можете использовать любую предыдущую версию. Редакция Datacenter позволяет использовать любые редакции предыдущих выпусков, Standard только Standard и Enterprise.
Единственной проблемой будет достать легальные дистрибутивы. Право использования предыдущих версий не разрешает использовать первый попавшийся дистрибутив, например, скачанный с торрента, вы должны получить его законным путем: с оборудованием по каналу OEM, медианосители для корпоративного лицензирования, подписки MSDN и ТechNet и т.д.
Кроме того, следует помнить, что понижение версии - это только понижение дистрибутива, но не понижение лицензионных прав. Простой пример: лицензия Windows Server 2008 Enterprise позволяет использовать в виртуальной среде до 4 экземпляров ОС, в случае понижения версии для лицензии Windows Server 2012 Standard мы можем запустить только две виртуальных машины с Windows Server 2008 Enterprise. Также не забываем, что несмотря на то, что предыдущие версии лицензировались "на сервер", понижая лицензии Server 2012 вы также обязаны лицензировать процессорные сокеты.
Напоследок рассмотрим некоторые моменты лицензирования клиентов, несмотря на то, что данные правила не изменились, обновить знания применительно к современным технологиям лишним не будет.
Начнем с мобильных устройств. Существует ошибочное мнение, что они не требуют лицензирования, но это не так. Ниже представлена типичная схема: в сети развернуты различные службы и вместе с ними Exchange-сервер, к которому кроме рабочих станций имеют доступ мобильные устройства сотрудников.
Так как Exchange работает не в вакууме, а на платформе Windows Server, то каждое подключение к нему должно быть покрыто не только клиентской лицензией Exchange, но и Windows Server CAL. Это правило распространяется и на мобильные устройства, вне зависимости от их платформы.
Еще один момент связан с опосредованными подключениями. Рассмотрим следующую схему: в локальной сети на платформе Windows Server развернут сервер СУБД и работающий с ним сервер с корпоративным ПО, в нашем случае это 1С, также для доступа удаленных клиентов организован доступ к 1С через веб-клиент, для этого установлен веб-сервер на платформе Linux.
Начнем с локальных клиентов, очевидно, что для них потребуются лицензии 1C и Windows Server CAL, а также SQL CAL. Постойте, скажет читатель, как же так, ведь клиент не работает с сервером СУБД, все обращения к базе данных производит только сервер 1С. Здесь самое время вспомнить, что межсерверные соединения не лицензируются, в то время как любое клиентское обращение к ресурсам сервера, даже опосредованное, подлежит лицензированию.
Исходя из этих же принципов мы обязаны снабдить удаленных клиентов тем же самым набором лицензий, несмотря на то, что непосредственно с серверами на Windows они не взаимодействуют, а обращаются только к Linux машине.
В этой статье мы рассмотрим особенности лицензирования операционной системы Windows Server 2019, 2016 и 2012 R2 с точки зрения новой модели лицензирования Microsoft. Также мы рассмотрим правила и порядок лицензирования при использовании Windows Server в качестве гостевой ОС в виртуальных машинах, в том числе в кластерах с поддержкой возможности миграции виртуальных машин между гипервизорами (технологии VMWare VMotion, Hyper-V Live Migration и т.п.).
Начиная с Windows Server 2012 Microsoft стала кардинально менять и, самое главное, упрощать модель лицензирования своей серверной платформы с учетом современных реалий широкого использования виртуализации.
Редакции WindowsServer
В большинстве случаев при обсуждении модели лицензирования целесообразно рассматривать Standard и Datacenter редакции Windows Server.
В Windows Server 2012 R2 функционал редакций Standard и Datacenter практически идентичен за исключением лицензионных прав на запуск виртуальных машин. Это означает, что необходимую редакцию нужно выбирать, основываясь только на количестве виртуальных машин на физическом хосте (сервере), а не от наличия/отсутствия необходимого функционала.
- В Windows Server 2012 R2 Standard – лицензия позволяет запустить не более двух виртуальных машин;
- В Windows Server 2012 R2 Datacenter – на одном физическом хосте с этой лицензией можно запустить неограниченное количество виртуальных машин (напомним, что такие виртуальные машины можно активировать по упрощенной схеме с помощью функции автоматической активации виртуальных машин — AVMA).
По сути, при выборе редакции Windows Server 2012 R2 нужно в первую очередь основываться на том нужна, или не нужна вам виртуализация.
Лицензия Windows Server 2016/2019 Standard позволяет вам запустить до двух ВМ с Windows Server на одном физическом хосте.
В Windows Server 2016 и 2019 в редакции Datacenter поддерживаются ряд полезных технологий, которые полезны при широком использовании возможностей виртуализации и интеграции в облако Azure. Например, в редакции WS 2016 Datacenter поддерживаются:
Примечание. Мы не рассматриваем редакции Essentials и Foundation, т.к. из-за ориентации на малые предприятия, в этих ОС заложен ряд специфических ограничений и отсутствуют права на виртуализацию. Также отметим, что редакция Web Server была упразднена окончательно.Лицензирование процессоров в Windows Server 2012 R2
В Windows Server 2012 R2 – одна лицензия позволяла запускать ОС на одном одно- или двух-процессорном сервере. Т.е одна лицензия покрывает до двух процессоров (сокетов), расположенных в одном физическом сервере (ядра процессорами не являются!). Нельзя разделить одну лицензию на два однопроцессорных сервера (в этом случае придется приобрести две лицензии Windows Server). Например, если в одном физическом сервере установлено более двух процессоров, нужно купить по 1 лицензии на каждую пару процессов. Так, например, для 4-х процессорного сервера, понадобится 2 лицензии Windows Server 2012 R2.
Лицензирование ядер в Windows Server 2016 и 2019
В Windows Server 2016 и Windows Server 2019 Microsoft перешла от модели лицензирования физических процессоров на модель лицензирования ядер (Core-based). Это связано с тенденцией производителей CPU и серверов наращивать не количество процессоров, а количество ядер на одном процессоре и нежеланием Microsoft лишаться прибыли при массовом использовании многоядерных серверов. Особенности лицензирования современных версий Windows Server 2016 и 2019 (подробно рассматривается в этой статье):
- 1 лицензия Windows Server 2016 позволяет лицензировать 2 физических ядра сервера (т.е. Microsoft продает двух ядерные лицензии);
- Стоимость одной 2-x ядерной лицензии в 8 раз снижена по сравнению с одной процессорной лицензией для Windows Server 2012 R Но на физический сервер нужно приобрести минимум 8 таких лицензий (на 16 ядер) – это минимальный пакет на 1 сервер. Таким образом стоимость лицензирования одного физического 2-х процессорного сервера с количеством ядер на CPU до 8 не изменилась;
Лицензирование виртуальных машин в WindowsServer
Если вы планируете использовать свой физический сервер в качестве гипервизора, на котором запущены ВМ с Windows Server, вам нужно выбирать редакцию в зависимости от количества ВМ, которые будут запущены на вашем сервере.
Если вы запускаете на гипервизоре ВМ с ОС не от Microsoft, они не учитываются при лицензировании.Например, у вас имеется двух процессорный сервер с 16 ядрами. Если приобрели 8 лицензий Windows Server 2019 Standard и лицензировали вся физический ядра сервера. Это значит, вы имеете право запускать до 2 ВМ с Windows Server на лицензированном физическом хосте. Лицензия Datacenter позволяет запустить на лицензированном хосте неограниченное количество виртуальных ОС.
Что делать, если на сервере с лицензией Standard вам понадобится запустить более двух виртуальных машин? Вам придется приобрести нужное количество лицензий исходя из следующего соображения: одна лицензия Standard позволяет запустить 2 виртуальные машины.
Например, вы хотите лицензировать двухпроцессорный (по 8 ядер на каждом) сервер с четырьмя виртуальными машинами. В модели лицензирования ядер в Windows Server 2016 Standard вам нужно приобрести 16 двухъядерных лицензий Window Server Standard ( 2 комплекта лицензий, закрывающих физические ядра) или 8 двухъядерных лицензий Datacenter (как сменить редакцию Windows Server на более высокую без переустановки).
Отметим, что порядок покрытия лицензиями такой: сначала покрываются физические ядра, а лишь затем экземпляры виртуальных машин.
На основании текущих прайсов Microsoft на Windows Server можно сделать вывод, что покупка редакции Datacenter экономически выгодна, если на одном физическом хосте вы планируете запустить более 14 виртуальных машин. Если количество ВМ меньшее, выгоднее приобрести несколько лицензий Standard, закрывающих ваши потребности по ядрам и виртуальным машинам.
Если вы используете виртуализацию на своем физическом сервере с Windows Server 2016, вы можете использовать хостовую ОС только для обслуживания и управления роли Hyper-V и виртуальных машин. Т.е. вы не сможете установить на физический сервер Windows Server 2016, запустить на нем две ВМ и получить три полноценных сервера под свои задачи. В терминологии Microsoft физической инстанс ОС называется POSE (physical operating system environment), а виртуальные – VOSE (virtual operating system
environment).
Лицензирование Windows Server с учетом возможности миграции виртуальных машин между физическими серверами
Далее рассмотрим особенности лицензирования в том случае, если виртуальная машина с Windows Server ОС может перемещаться между физическими серверами в ферме виртуализации (с помощью VMWare VMotion, Hyper-V Live Migration и т.п.).
Примечание. В соответствии с лицензионной политикой Microsoft виртуальные машины могут быть запущены не только на платформе гипервизора Hyper-V, но и на любой другой на ваш выбор, например VMWare, XEN и пр. Т.е. если вы лицензировали физический сервер, купили 8 двухъядерных лицензий WS Standard и установили на него VMWare ESXi/ Hypervisor, вы можете запустить на нем 2 виртуальные машины с Windows Server 2019 Standard.Для большинства серверных продуктов Microsoft покупка Software Assurance (SA) предоставляет право переносить лицензию между физическими хостами. Но Windows Server является исключением из этого правила. Согласно условиям лицензионного соглашения, лицензию между хостами можно переносить не чаще чем 1 раз в 90 дней.
Как же лицензировать ферму их нескольких физических хостов с гипервизорами, в которой ВМ могут перемещаться между серверами? В такой схеме вам придется на каждый физический сервер приобрести количество лицензии, покрывающее максимальное количество виртуальных машин, которые могут быть запущены на нем в любой момент времени (с учетом ситуации, когда все виртуальные машины фермы «соберутся» на одном хосте). Т.е. лицензии на виртуальные машины привязаны к физическому хосту и не переезжают между хостами вместе с ВМ.
В случае с редакцией Datacenter на каждый физический хост будет достаточно по одному комплекту лицензии, закрывающей все ядра (в минимальной конфигурации 8 двухъядерных лицензий Datacenter), т.к. такая лицензия позволяет запустить неограниченное количество ВМ.
Таким образом вы должны выбирать наиболее выгодный тип лицензии следует в зависимости от планируемого количества ВМ в ферме.
Примеры расчета лицензий Windows Server для виртуализации
Ниже приведены несколько примеров расчета лицензий Windows Server на физические сервера при использовании виртуализации.
Пример 1. Имеется Hyper-V кластер из 5 серверов. На каждом 2 процессора по 20 ядер. На каждом будут работать 10 виртуальных машин.
Т.к. 5 серверов объединены в HA кластер Hyper-V, значит потенциально на каждом хосте при миграции оказаться могут 50 виртуальных машин. Соответственно, выгоднее приобрести лицензии Datacenter.
Количество лицензий на 1 сервер:
- Общее кол-во ядер – 40
- Количество 2 ядерных лицензий (WinSvrDCCore 2019 SNGL OLP 2Lic NL CoreLic) – 20
Общее кол-во 2 ядерных лицензий WinSvrDCCore на 5 серверов – 100.
Пример 2. В филиале установлен 1 сервер с 2 сокетами по 4 ядра, на котором запущено 4 виртуальных машины. Сколько лицензий Windows Server нужно приобрести?
На сервере имеется 8 ядер. Согласно условиям лицензирования – вам нужно покрыть минимум 16 ядер. Значит вам нужно купить 8 лицензий Windows Server 2016 (WinSvrSTDCore 2 Core). Это позволит запустить 2 ВМ. Чтобы запустить еще 2 ВМ нужно купить еще один комплект лицензий для ядер.
Таким образом для лицензирования нужно 16 2-х ядерных лицензий Windows Server (WinSvrSTDCore 2019 SNGL OLP 2Lic NL CoreLic) или 2 16-ядерные лицензии (WinSvrSTDCore 2019 SNGL OLP 16Lic NL CoreLic).
Чтобы использовать KMS, в локальной сети должен быть доступен узел KMS. Компьютеры, активируемые с помощью узла KMS, должны иметь определенный ключ продукта. Этот ключ иногда называют ключом клиента KMS, но формально он называется универсальным корпоративным ключом многократной установки Microsoft (GVLK). Компьютеры, на которых выполняются выпуски Windows Server и клиент Windows с корпоративным лицензированием, умолчанию являются клиентами KMS, для которых не требуется дополнительная настройка, так как соответствующий ключ GVLK уже существует.
Но в некоторых сценариях требуется добавить GVLK на компьютер, который вы хотите активировать на узле KMS, например:
- при переключении компьютера из режима использования ключа многократной активации (MAK);
- при преобразовании розничной лицензии Windows в клиент KMS;
- если компьютер ранее был узлом KMS.
Чтобы использовать перечисленные здесь ключи (GVLK), в локальной среде должен быть узел KMS. Если у вас еще нет узла KMS, см. сведения в статье Создание узла KMS.
Если вы хотите активировать Windows без доступного узла KMS и без активации тома (например, вы пытаетесь активировать розничную версию клиента Windows), эти ключи не будут работать. Вам нужно использовать другой метод активации Windows, например использование ключа MAK или приобретение розничной лицензии. Узнайте, как найти ключ своего продукта Windows, и что такое лицензионные версии Windows.
Установка ключа продукта
Если вы переключаете компьютер из режима использования узла KMS, ключа MAK или розничной версии Windows в режим клиента KMS, установите соответствующий ключ продукта (GVLK) из списка ниже. Чтобы установить ключ продукта клиента, откройте командную строку администратора на клиенте и выполните следующую команду, а затем нажмите клавишу Enter :
Например, чтобы установить ключ продукта для выпуска Windows Server 2022 Datacenter, выполните следующую команду и нажмите клавишу Enter :
Универсальные ключи многократной установки (GVLK)
В таблицах ниже вы найдете ключи GVLK для каждой версии и выпуска Windows. LTSC означает Long-Term Servicing Channel, а LTSB — Long-Term Servicing Branch.
Windows Server (версии LTSC)
Windows Server 2022
| Версия операционной системы | Ключ продукта клиента KMS |
|---|---|
| Windows Server 2022 Datacenter | WX4NM-KYWYW-QJJR4-XV3QB-6VM33 |
| Windows Server 2022 Standard | VDYBN-27WPP-V4HQT-9VMD4-VMK7H |
Windows Server 2019
| Версия операционной системы | Ключ продукта клиента KMS |
|---|---|
| Windows Server 2019 Datacenter | WMDGN-G9PQG-XVVXX-R3X43-63DFG |
| Windows Server 2019 Standard | N69G4-B89J2-4G8F4-WWYCC-J464C |
| Windows Server 2019 Essentials | WVDHN-86M7X-466P6-VHXV7-YY726 |
Windows Server 2016
| Версия операционной системы | Ключ продукта клиента KMS |
|---|---|
| Windows Server 2016 Datacenter | CB7KF-BWN84-R7R2Y-793K2-8XDDG |
| Windows Server 2016 Standard | WC2BQ-8NRM3-FDDYY-2BFGV-KHKQY |
| Windows Server 2016 Essentials | JCKRF-N37P4-C2D82-9YXRT-4M63B |
Windows Server (версии Semi-Annual Channel)
Windows Server, версии 20H2, 2004, 1909, 1903 и 1809
| Версия операционной системы | Ключ продукта клиента KMS |
|---|---|
| Windows Server Datacenter | 6NMRW-2C8FM-D24W7-TQWMY-CWH2D |
| Windows Server Standard | N2KJX-J94YW-TQVFB-DG9YT-724CC |
Windows 10 (версии Semi-Annual Channel)
См. в разделе Справочные материалы по жизненному циклу Windows сведения о поддерживаемых версиях и конечных датах обслуживания.
Статья будет состоять из двух частей, вторую выложу при одобрении идеи первой.
Долго ли, много ли пришлось мне мучиться с постоянной слетевшей активацией Windows и Office история умалчивает. А так как лень – двигатель прогресса, попала в мой орешек мысль все это дело завязать на полную автоматизацию(с авторазвертыванием, авто-активацией и последующим мониторингом результата\процесса). Сразу опишу, что нам для этого будет необходимо, дабы Вам дальше было (не)интересно читать: локальный KMS-сервер, GPO, Bat-ники, Zabbix(без него не торт будет). Собсна усе.
Для начала ознакомимся с этим понятием. KMS сервер - это тип активации который обычно используется в сети для корпоративных клиентов, а благодаря утекшим дистрибутивам (Volume) теперь доступен всем нам. Плюсы активации KMS в том что, вам не нужен доступ в Интернет или телефон для активации систем, требуется только подключиться к серверу KMS, который мы можем поднять на основе эмулятора "KMSAuto" последней версии (отдельная благодарность автору). Инфраструктура KMS не сложна и расширяема, один сервер KMS может обслуживать тысячи компьютеров, а то и не ограниченное количество.
Для поднятия собственного KMS-сервера развернем виртуалку на Windows Server(2008, 2012) и заведем в его в нашу доменную структуру.
1. Переходим на вкладку Система. Здесь мы можем установить или удалить сервис (пока не устанавливаем, сначала надо всё настроить), выбрать ручной или автоматический и другие методы установки сервиса, включить введение лога, создать задачу в планировщике или установить GVLK ключ продукта, а также сбросить настройки по умолчанию. В режиме WinDivert программа устанавливает сервис вместе со специальным драйвером. В режиме Hook, устанавливается сервис и происходит подмена некоторых системных файлов. В режиме TAP, сервис устанавливается с дополнительной виртуальной сетевой картой. В режиме Auto, программа установит сервис с одним из перечисленных вариантов или в ручном режиме, всё зависит от того какая у вас система. В режиме NoAuto, сервис просто установится без каких либо дополнительных внесений и изменений в систему. Выбираем в режиме "NoAuto", с ним будет проще работать на Windows 7. Здесь же можно включить логи, для того чтобы иметь информацию об активации. Там содержится информация следующего типа: время запуска KMS-сервиса (UTC и время по вашему часовому поясу); имя компьютера клиентского ПК; название продукта; идентификатор продукта; идентификатор лицензии; идентификатор KMS сервера; статус лицензии; IP-адрес клиентского ПК (включается опционально). Кому конечно требуется активировать всего один домашний компьютер, эта функция не потребуется.
2. Далее переходим на вкладку Настройки, для более тонкой настройки эмулятора на вашем будущем KMS-сервере. Здесь находятся настройки привязки IP-адреса, заставка, звуки, сохранения настроек программы непосредственно в папке с программой, настройка порта и IP адреса сервиса, PID KMS-сервера, интервал активации и обновления и другие функции. В поле "Настройки", убираем галочку Удалить IP KMS-Service, иначе в дальнейшем автоматическая переактивация работать не будет, так как этот параметр удаляет IP-адрес KMS-сервера с ваших клиентских ПК включая ПК на котором вы подняли KMS-сервер. Остальные параметры в поле "Настройки", можете настроить на свое усмотрение.
В поле "Настройки KMS-Service", вы можете установить порт и IP адрес для вашего KMS-сервера. По умолчанию порт стоит 1688, его я так и оставил (вы можете поставить любой какой вам захочется). В панеле "Host", оставляем Auto-host(ежели вы хотите пускать свой KMS-сервер в интернет, выбираете адрес своего моста)
Далее устанавливаем PID-ы для Windows, Office 2010, 13 и 16. Выбираем те что в списке, так как они от реальных KMS-серверов. Параметр "-AI" это интервал автоматической активации, точнее когда при неудачной попытке ПК активировать продукт Windows или Office, повторная попытка активироваться будет выполнена через указанное вами время. Здесь я ставлю 100 минут, мне так удобнее, вы же можете также установить свое значение, только не советую ставить 43200 минут, иначе системе придется дожидаться своей повторной попытки активироваться очень долго! Параметр "-RI" это интервал автоматического обновления активации, на более понятном языке - это время переактивации продукта, накрутка счетчика до 180 дней (по истечении ваш продукт станет не лицензионным). Здесь я поставил 10080 минут = 7 дней, так как по умолчания на реальных KMS-серверах обычно стоит такой интервал, да и мне удобнее. Также не советую ставить слишком большой интервал.
Как проверить? Да просто!
На Вашей неактивирванной тачке в CMD от имени админа прописываем:
cscript "%windir%\system32\slmgr.vbs" /ipk %KEY%
cscript "%windir%\system32\slmgr.vbs" /skms servername.domain
cscript "%windir%\system32\slmgr.vbs" /ato
На этом, пожалуй, закончим. Далее – Активация Office, мониторинг активации Win & Off с помощью Zabbix, авто-активация продуктов на основе полученных данных)
Если у Вас уже это получилось или понравилась сама идея, жду Вашего одобрения на продолжение статьи.
Статья имеет ознакомительный характер и никого не призывает использовать столь подлый способ.
Читайте также: