Устранение неполадок с клиентами активации на основе Active Directory (ADBA), которые не активируются

Примечание.

Эта статья была первоначально опубликована в блоге TechNet 26 марта 2018 года.

Недавно я помог клиенту развернуть Windows Server 2016 в своей среде. Мы также использовали эту возможность, чтобы перенести их методику активации с сервера KMS на активацию на основе Active Directory.

В качестве правильной процедуры внесения всех изменений мы начали миграцию в тестовой среде клиента. Мы начали развертывание, следуя инструкциям в активации на основе Active Directory и служба управления ключами. Контроллеры домена в тестовой среде работали под управлением Windows Server 2012 R2, поэтому нам не нужно было подготовки леса. Мы установили роль на контроллере домена Windows Server 2012 R2 и выбрали активацию на основе Active Directory в качестве метода активации томов. Мы установили ключ KMS и дали ему имя "Активация KMS AD (** LAB)." Мы последовали за записью блога по шагу.

Мы начали создавать четыре виртуальных машины, два сервера Windows 2016 Server Standard и два центра обработки данных Windows 2016 Server. На этом этапе все было здорово. Мы создали физический сервер под управлением Windows 2016 Server Standard, а компьютер активировался должным образом.

На самом деле установка и настройка были очень простыми, так что эта часть была простой и понятной. Однако все виртуальные машины, созданные на прошлой неделе, показали, что они не были активированы. Я вернулся к физическому компьютеру, и он был в порядке. Я отправился к клиенту, чтобы обсудить, что произошло. Первый вопрос был "Что изменилось в выходные дни?" И, как обычно, ответ был "ничего". На этот раз ничего действительно не было изменено, и мы должны были выяснить, что происходит.

Я пошел на один из серверов проблем, открыл командную строку и проверил выходные данные команды slmgr /ao-list . Переключатель /ao-list отображает все объекты активации в Active Directory.

Результаты показывают, что у нас есть два объекта активации: один для Windows Server 2012 R2 и только что созданная лицензия KMS AD Activation (** LAB), которая является лицензией Windows Server 2016. Это подтверждает правильное настройку Active Directory для активации клиентов Windows KMS.

Зная, что slmgr команда предназначена для активации лицензии, я продолжала использовать различные варианты. Я попробовал параметр, который будет отображать подробные /dlv сведения о лицензии. Это выглядело хорошо, я выполнял стандартную версию Windows Server 2016, есть идентификатор активации, идентификатор установки, URL-адрес проверки, даже частичный ключ продукта.

Кто-нибудь заметил, что я пропустил на этом этапе? Мы вернемся к нему после моих других действий по устранению неполадок, но достаточно сказать, что ответ находится на этом снимке экрана.

Мое мышление сейчас заключается в том, что по какой-то причине ключ сломается, поэтому я использую /upk переключатель, который удаляет текущий ключ. Хотя это было эффективным при удалении ключа, это, как правило, не лучший способ сделать это. Если сервер перезагружается перед получением нового ключа, он может оставить сервер в плохом состоянии? Я обнаружил, что использование /ipk переключателя (которое я делаю позже в моем устранении неполадок) перезаписывает существующий ключ и является безопасным маршрутом для принятия.

Я снова переключился, чтобы просмотреть подробные /dlv сведения о лицензии. К сожалению, это не дало мне никакой полезной информации, просто ключ продукта не найден ошибкой. Потому что нет ключа, так как я просто удалил его.

Я понял, что это был длинный снимок, но я пытался /ato переключиться, который должен активировать Windows на известных серверах KMS (или Active Directory, как это может быть). И опять ошибка "продукт не найден".

Следующая мысль была, что иногда остановка и запуск службы делает трюк, так что я пытался, что дальше. Мне нужно было остановить и запустить службу платформы защиты программного обеспечения Майкрософт (службу SPPSvc). В командной строке администрирования я использую доверенные net stop и net start команды. Сначала я замечаю, что служба не работает, поэтому я думаю, что это должно быть.

Однако после запуска службы и попытки активировать Windows снова я по-прежнему получаю ошибку продукта.

Затем я просмотрел журнал событий приложений на одном из проблемных серверов. Я обнаружил ошибку, связанную с активацией лицензии, событие с идентификатором 8198 и кодом 0x8007007B.

При поиске этого кода я нашел статью, которая говорит, что код ошибки означает, что имя файла, имя каталога или синтаксис метки тома неверны. Читая методы, описанные в статье, это не казалось, что любой из них соответствует ситуации. Когда я выполнил nslookup -type=all _vlmcs._tcp команду, я нашел существующий сервер KMS (все еще много компьютеров Windows 7 и Server 2008 в среде, поэтому было необходимо сохранить его вокруг), но и пять контроллеров домена. Это означает, что это не проблема DNS, и проблемы были в других местах.

Итак, я знал, что DNS в порядке. Служба Active Directory правильно настроена в качестве источника активации с помощью KMS. Физический сервер был активирован должным образом. Возможно, проблема связана только с виртуальными машинами? Интересное примечание: в тот момент мой клиент говорит мне, что кто-то в другом отделе также решил создать более десятка виртуальных машин Windows Server 2016. Так что теперь я предполагаю, что у меня есть еще десятки серверов для борьбы с этим не будет активироваться. Однако эти серверы активировались просто хорошо.

Ну, я направился обратно к команде slmgr , чтобы выяснить, как получить эти монстры активированы. На этот раз я собираюсь использовать /ipk переключатель, который позволит мне установить ключ продукта. Я пошел в приложение A: ключи установки клиента KMS, чтобы получить соответствующие ключи для стандартной версии Windows Server 2016. Некоторые серверы являются центром обработки данных, но мне нужно сначала исправить этот сервер.

Я использовал /ipk параметр для установки ключа продукта, выбрав стандартный ключ Windows Server 2016.

Здесь я записал только результаты для версии Datacenter, но они такие же. Я использовал переключатель /ato для принудительной активации. Мы получаем удивительное сообщение о том, что продукт был успешно активирован.

Используя переключатель /dlv снова, мы видим, что теперь мы были активированы Active Directory.

Итак, что же пошло не так? Почему мне пришлось удалить установленный ключ и добавить эти универсальные ключи, чтобы обеспечить правильную активацию этих компьютеров? Почему десяток (или около того) других компьютеров был активирован без каких-либо проблем? Как я уже говорил, я пропустил кое-что важное на начальных этапах изучения проблемы. Я был тщательно смущен, так что обратился к плакату из первоначального блога. Плакат увидел проблему сразу и помог мне понять, что я пропустил рано.

Когда я запустил первый /dlv переключатель, в описании был ключ. Описание содержало следующее: Windows® Operating System, RETAIL Channel. Я видел это и решил, что канал RETAIL означал, что лицензия была приобретена и имела допустимый ключ.

При просмотре выходных данных коммутатора /dlv с правильно активированного сервера обратите внимание, что описание теперь указывает канал VOLUME_KMSCLIENT. Это позволяет нам знать, что это действительно корпоративная лицензия.

Что же означает канал RETAIL? Это означает, что носителем, использованным для установки операционной системы, был ISO-файл с сайта MSDN. Я вернулся к клиенту и спросил, существует ли вероятность того, что в сети есть второй ISO-файл Windows Server 2016. Оказалось, что да, в сети есть другой ISO-файл, который использовался для создания десятка других компьютеров. Они сравнили эти два ISO-файла — и, разумеется, образ, который мне предоставили для создания виртуальных серверов, оказался ISO-файлом MSDN. Они удалили, что MSDN ISO из своей сети, и теперь у нас есть все существующие серверы активированы, и больше не беспокоится о сбое активации в будущих сборках.