Ошибка 0xC004F074 "Не удалось подключиться к службе управления ключами (KMS)"

  • Статья

Область применения: ✔️ Виртуальные машины Windows

В этой статье описывается, как устранить ошибку 0xC004F074, возникающую при попытке активировать виртуальную машину Windows в Microsoft Azure.

Необходимые компоненты

Симптомы

При попытке активировать виртуальную машину Windows Azure в узле скриптов Windows возникает следующее сообщение об ошибке:

Ошибка: 0xC004F074 Служба лицензирования программного обеспечения сообщила, что компьютер не удалось активировать. Невозможно связаться со службой управления ключами (KMS). Дополнительные сведения см. в журнале событий приложений.

Причина

Виртуальная машина не может подключиться к службе KMS для активации. Если azure KMS используется для активации (выбор по умолчанию), запрос на активацию должен быть получен из общедоступного IP-адреса Azure. Возможные причины сбоя подключения:

  • Принудительное туннелирование, в котором весь трафик направляется за пределы Azure (обычно в локальную среду) с помощью Azure ExpressRoute или сетевого виртуального устройства

  • Трафик, заблокированный сетевым виртуальным устройством или стандартной внутренней подсистемой балансировки нагрузки

Исследование

Чтобы определить конкретную причину проблемы, выполните трехкомпонентную процедуру в следующих разделах.

Часть 1. Настройка соответствующего ключа установки клиента KMS

Примечание.

Эта часть не требуется для виртуальных машин, работающих Windows 10 Корпоративная нескольких сеансов (также известных как Windows 10 Корпоративная для виртуальных рабочих столов) в виртуальном рабочем столе Azure).

Чтобы определить, работает ли виртуальная машина с несколькими сеансами, выполните следующую команду скрипта Software License Manager:

slmgr.vbs /dlv

Если выходные данные содержат Name: Windows(R), ServerRdsh edition строку, виртуальная машина выполняет выпуск с несколькими сеансами, и вы можете пропустить остальную часть этой части.

Примечание.

Если развернуть Windows 10 Корпоративная многосеансовую виртуальную машину, а затем обновить ключ продукта до другого выпуска, вы не сможете вернуть виртуальную машину в Windows 10 Корпоративная нескольких сеансов. Вместо этого необходимо повторно развернуть виртуальную машину. Дополнительные сведения см. в статье "Можно ли обновить виртуальную машину Windows до Windows Enterprise с несколькими сеансами"?

Для виртуальной машины, созданной на основе пользовательского образа, необходимо настроить соответствующий ключ установки клиента KMS для виртуальной машины. Выполните следующие действия:

  1. В окне командной строки с повышенными привилегиями выполните следующую команду скрипта Software License Manager:

    cscript c:\windows\system32\slmgr.vbs /dlv

  2. Description Проверьте значение в выходных данных, чтобы определить, была ли виртуальная машина создана из розничной торговли (RETAILканала) или тома (VOLUME_KMSCLIENT) лицензированного носителя.

  3. Если предыдущие выходные данные команды указывают RETAIL канал, выполните следующие команды скрипта Software License Manager. Первая команда задает ключ установки клиента KMS для используемой версии Windows Server, а вторая команда выполняет другую попытку активации.

    cscript c:\windows\system32\slmgr.vbs /ipk <kms-client-setup-key>
cscript c:\windows\system32\slmgr.vbs /ato

    Например, если вы используете Windows Server 2016 Datacenter, первая команда будет отображаться следующим образом:

    cscript c:\windows\system32\slmgr.vbs /ipk CB7KF-BWN84-R7R2Y-793K2-8XDDG

Часть 2. Проверьте, находится ли виртуальная машина за внутренней подсистемой балансировки нагрузки SKU уровня "Стандартный"

Выполните следующие действия, чтобы проверить, находится ли виртуальная машина за внутренней подсистемой балансировки нагрузки SKU уровня "Стандартный", которая блокирует исходящий интернет-трафик по умолчанию:

  1. На портале Azure найдите и выберите Виртуальные машины.

  2. В списке виртуальных машин выберите имя виртуальной машины.

  3. В области меню виртуальной машины найдите заголовок сети и выберите балансировку нагрузки. Если отображается сообщение о том, что ресурсы балансировки нагрузки не отображаются, виртуальная машина не стоит за подсистемой балансировки нагрузки. В этом случае можно перейти к части 3. Проверьте подключение между виртуальной машиной и службой Azure KMS.

  4. Если вы видите ресурс подсистемы балансировки нагрузки, выберите имя подсистемы балансировки нагрузки, чтобы перейти на страницу обзора подсистемы балансировки нагрузки.

  5. В области меню подсистемы балансировки нагрузки выберите "Свойства".

  6. На странице "Свойства" найдите значения SKU и типа балансировки нагрузки, а затем в следующей таблице приведены выводы.

    Значения SKU и типа балансировки нагрузки Заключение
    Значение SKU — "Стандартный", а значение типа балансировки нагрузки — "Закрытый". Виртуальная машина находится за внутренней подсистемой балансировки нагрузки SKU уровня "Стандартный", которая блокирует исходящий интернет-трафик по умолчанию. Чтобы включить исходящее подключение, см. решение 2. (Для стандартной внутренней подсистемы балансировки нагрузки) Используйте шлюз NAT или общедоступную подсистему балансировки нагрузки уровня "Стандартный".
    Значение SKU не является стандартным, а значение типа балансировки нагрузки — общедоступным. Виртуальная машина не находится за внутренней подсистемой балансировки нагрузки SKU уровня "Стандартный", а исходящий интернет-трафик по умолчанию не блокируется. Перейдите к части 3. Проверьте подключение между виртуальной машиной и службой Azure KMS.

Часть 3. Проверка подключения между виртуальной машиной и службой Azure KMS

  1. Убедитесь, что в настройках виртуальной машины указан правильный сервер Azure KMS. Для этого выполните следующую команду скрипта Software License Manager:

    Invoke-Expression "$env:windir\system32\cscript.exe $env:windir\system32\slmgr.vbs /skms azkms.core.windows.net:1688"

    Эта команда должна вернуть следующий текст:

    Задано имя компьютера со службой управления ключами: azkms.core.windows.net:1688.

  2. Убедитесь, что брандмауэр на виртуальной машине не блокирует исходящий сетевой трафик к конечной точке KMS через порт 1688. Для этого примените один из следующих вариантов:

    • Проверьте подключение, выполнив командлет Test-NetConnection в PowerShell:

      Test-NetConnection azkms.core.windows.net -port 1688

      Если попытка подключения разрешена, командлет отображает "TcpTestSucceed: True" в выходном тексте.

    • Проверьте подключение, выполнив средство PsPing:

      .\psping.exe azkms.core.windows.net:1688

      В выходных данных команды вторая и последняя строка должна выглядеть следующим образом:

      Sent = 4, Received = 4, Lost = 0 (0% loss)

      Если Lost значение больше 0 (ноль), виртуальная машина не имеет подключения к серверу KMS. В этом случае, если виртуальная машина находится в виртуальной сети и имеет пользовательский DNS-сервер, необходимо убедиться, что DNS-сервер может разрешить доменное azkms.core.windows.net имя. Если это не удается, измените DNS-сервер на один, который может разрешить azkms.core.windows.net.

      Примечание.

      При удалении всех DNS-серверов из виртуальной сети виртуальные машины используют внутреннюю службу DNS Azure. Эта служба может разрешить kms.core.windows.net.

  3. Используйте тест следующего прыжка в Azure Наблюдатель за сетями, чтобы убедиться, что тип следующего прыжка — интернет из затронутой виртуальной машины в определенные места назначения. Чтобы применить тест следующего прыжка, выполните следующие действия.

    1. На портале Azure найдите и выберите Виртуальные машины.

    2. В списке виртуальных машин выберите имя виртуальной машины.

    3. В области меню виртуальной машины найдите заголовок справки и выберите "Устранение неполадок подключения".

    4. На странице устранения неполадок подключения виртуальной машины укажите следующие значения полей.

      Поле значение
      Конечный тип Указание вручную
      URI, полное доменное имя или IP-адрес 20.118.99.224, 40.83.235.53 (дляazkms.core.windows.net) или IP-адрес соответствующей конечной точки KMS, которая применяется к вашему региону
      Порт назначения 1688;
      Исходный порт 1688;
      Диагностические тесты Следующий прыжок

    5. Нажмите кнопку "Выполнить диагностические тесты ".

    6. После завершения диагностических тестов просмотрите поле результатов , которое отображается под кнопкой. Тест следующего прыжка (из источника) должен иметь значение "Состояние успеха", а значение "Сведения" должно содержать тип следующего прыжка: Интернет в тексте. Если тип следующего прыжка — Интернет, повторите следующий тест прыжка для каждого из оставшихся IP-адресов. Однако если следующий тип прыжка отображается как VirtualAppliance, VirtualNetworkGateway или что-либо другое, кроме Интернета, может возникнуть один из следующих сценариев:

      • Маршрут по умолчанию существует, который направляет трафик за пределы Azure до отправки трафика в конечную точку Azure KMS.

      • Трафик блокируется где-то вдоль пути.

      В этих сценариях см . решение 1. Использование пользовательского маршрута Azure для маршрутизации трафика активации на сервер Azure KMS.

  4. Убедившись, что подключение azkms.core.windows.net выполнено успешно, выполните следующую команду в командной строке Windows PowerShell с повышенными привилегиями. Эта команда пытается активировать виртуальную машину Windows несколько раз:

    1..12 | ForEach-Object {
    Invoke-Expression "$env:windir\system32\cscript.exe $env:windir\system32\slmgr.vbs /ato";
    Start-Sleep 5
}

    Если попытка активации выполнена успешно, команда отображает сообщение, похожее на следующий текст:

    Активация Windows(R), выпуск Server Datacenter (<kms-client-product-key>) ... Продукт успешно активирован.

Решение 1. (Для принудительного туннелирования) Используйте пользовательский маршрут Azure для маршрутизации трафика активации на сервер Azure KMS

Если причиной является сценарий принудительного туннелирования, в котором трафик направляется за пределами Azure, обратитесь к администратору сети, чтобы определить правильный ход действий. Одно из возможных решений описано в разделе "Решение" активации Windows в сценарии принудительного туннелирования. Примените это решение, если оно соответствует политикам вашей организации.

Решение 2. (Для стандартной внутренней подсистемы балансировки нагрузки) Используйте шлюз NAT или общедоступную подсистему балансировки нагрузки уровня "Стандартный"

Если стандартный внутренний подсистема балансировки нагрузки блокирует трафик, существует два разных подхода к устранению проблемы, как описано в разделе "Использование преобразования адресов исходной сети " (SNAT) для исходящих подключений:

Рекомендуется использовать конфигурацию azure виртуальная сеть NAT для исходящего подключения в рабочих развертываниях. Дополнительные сведения о шлюзе Azure NAT см. в статье "Что такое шлюз Azure NAT"?

Однако если есть требование заблокировать весь интернет-трафик, убедитесь, что вы запрещаете исходящий доступ к Интернету с помощью правила группы безопасности сети (NSG) в подсети виртуальной машины, которую необходимо активировать. Обратите внимание, что трафик активации операционной системы к IP-адресам KMS через порт 1688 по-прежнему включен из-за внутренних правил платформы.

Свяжитесь с нами для получения помощи

Если у вас есть вопросы или помощь, создайте запрос на поддержку или попросите сообщества Azure. Вы также можете отправить отзыв о продукте в сообщество отзывов Azure.