0xC004F074 в корпоративной сети: журнал, DNS и KMS

Этот материал предназначен для администратора корпоративной KMS-среды. Код 0xC004F074 означает, что Windows не смогла связаться с KMS. Microsoft предлагает искать дополнительную информацию в журнале Application, а затем проверять конкретные звенья инфраструктуры.

Событие активации задаёт исходную точку

Сначала сопоставьте время ошибки с записью в Application Event Log на клиенте. Журнал нужен не для формального отчёта: он фиксирует дополнительный контекст, который определяет следующую ветку. Не начинайте со смены host или ключа без события и принадлежности устройства организации.

Службу sppsvc проверяют на штатном KMS-host

Одна из названных Microsoft причин — остановленная Software Protection Service, sppsvc, на KMS-host. Проверка относится к известному серверу организации. Публичный адрес из чужой инструкции не является заменой исправной корпоративной службы.

TCP 1688 тестируют между конкретной парой узлов

С клиента выполните Test-NetConnection -ComputerName <KMS Host Server> -Port 1688, подставив имя собственного KMS-host. Значение TcpTestSucceeded=False означает, что порт недоступен между этой парой узлов. Оно ещё не называет точку блокировки, но подтверждает сетевую ветку.

SRV _vlmcs должен вести на действующий сервер

Для DNS-проверки найдите запись _vlmcs._tcp и убедитесь, что она указывает на актуальный KMS-host. По умолчанию KMS использует TCP 1688. Старая или неверная запись способна отправлять клиент к серверу, который больше не обслуживает активацию.

Время проверяют при дополнительном 0xC004F06C

Рассинхронизацию нельзя объявлять универсальной причиной 0xC004F074. Если дополнительное событие показывает 0xC004F06C, разница времени клиента и KMS-host более четырёх часов может мешать активации. Microsoft указывает, что сравнение ведётся по UTC.

Результат оформляют как цепочку наблюдений

В итог диагностики включите событие Application, состояние sppsvc на штатном host, результат TCP 1688, назначение SRV _vlmcs и наличие или отсутствие 0xC004F06C. Такая последовательность отделяет службу, сеть, DNS и время. CID, случайные KMS-host и команды смены сервера вне своей организации в неё не входят.

Журналы клиента и host отвечают на разные вопросы

Событие на клиенте показывает, что он попытался активироваться и чем закончилась попытка. Журнал на самом KMS-host показывает, дошёл ли до него запрос. Пара этих наблюдений сразу делит задачу пополам: сеть или сервер.

На клиенте записи об активации ведёт служба защиты программного обеспечения, и в журнале Application видно как отправку запроса, так и обработку ответа. На host обращения клиентов пишутся в отдельный журнал службы управления ключами: каждая успешная регистрация клиента фиксируется собственным событием с именем машины.

Ключ активации Windows 10 Ключ и инструкция приходят на email за 1–5 минут.

Windows 10 Pro

499 ₽ 670 ₽

Добавить в корзину

Windows 10 Home

1 390 ₽ 1 850 ₽

Добавить в корзину

DNS: не только наличие записи

Проверка запроса nslookup -type=srv _vlmcs._tcp с указанием нужного домена показывает не одну строку, а весь список. И дальше важны детали, которые легко пропустить.

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

Для проверки конкретной пары «клиент — сервер» на клиенте можно временно задать адрес командой slmgr.vbs /skms с именем и портом, выполнить активацию и затем обязательно вернуть автоматический поиск командой slmgr.vbs /ckms. Оставлять жёстко прописанный адрес после диагностики не стоит: это создаёт вторую, невидимую схему маршрутизации.

Проверки на самом host

Когда сеть подтверждена, вопросы переходят к серверу. Их четыре, и они закрываются подряд.

1. Активирован ли сам host. Подробный вывод slmgr.vbs /dlv на сервере показывает состояние его собственной лицензии. Неактивированный host не обслуживает клиентов.
2. Поддерживает ли его ключ нужные версии. Ключ host рассчитан на определённый набор редакций и поколений Windows: чтобы активировать более новые клиентские системы, нужен ключ соответствующего поколения.
3. Слушает ли служба порт. На host смотрят, есть ли слушатель на порту службы и работает ли служба защиты программного обеспечения. Входящее правило для этого порта должно быть разрешено.
4. Каков текущий счётчик. Тот же подробный вывод показывает число учтённых клиентов. Пока порог не набран, host отвечает, но активацию не выдаёт.

Про счётчик стоит помнить отдельно: для клиентских систем порог составляет 25 уникальных устройств, для серверных — 5, и учитываются обращения за последние тридцать дней. В маленькой сети порог может не набираться никогда, и тогда KMS просто не подходит как схема.

Что даёт другой код, а не 0xC004F074

Ошибки активации в управляемой среде легко смешать в одну кучу. Разделение экономит часы.

• Недостаточный счётчик на host — это отдельный код с прямой формулировкой о нехватке учтённых клиентов, и появляется он тогда, когда связь как раз есть.
• Несовпадение ключа и редакции даёт свою ошибку и решается не сетью, а сверкой канала.
• Расхождение времени более чем на четыре часа сопровождается собственным кодом, о котором сказано выше, — без него время как причину не рассматривают.
• Отсутствие обращений к host вообще означает, что клиент не является KMS-клиентом: у него другой ключ, и ему нужна другая схема активации.

Когда KMS не тот инструмент

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

Для одиночных станций вне общей схемы разумнее выдать отдельную лицензию на устройство, чем тянуть к ним корпоративную инфраструктуру. Это же относится к подрядчикам и к компьютерам, которые организация не администрирует.

Пакет данных для эскалации

Если после всех проверок причина не найдена, соберите наблюдения в одном виде — они одинаково нужны и внутренней второй линии, и внешней поддержке.

• имя клиента, его редакция и версия, вывод подробной информации о лицензии;
• время события и записи из журнала клиента;
• имя host, его собственный статус активации и текущий счётчик;
• результат проверки порта между этой парой узлов;
• полный ответ запроса SRV с приоритетами и весами;
• сколько устройств затронуто: одно, подсеть или вся организация.

Последний пункт важнее, чем кажется: единичный случай почти всегда локальный, массовый — инфраструктурный. Проверять прокси и доступ к серверам в первом случае бессмысленно, во втором — обязательно.