История вопроса:
необходимо перенести несколько устаревших систем Windows Server 2003 с VMware на Azure.
Да, мы знаем, что у них устаревшая ОС. Тем не менее, мы должны держать их в рабочем состоянии. И это (по крайней мере частично) поддерживается Microsoft .
Одним из важных шагов, конечно же, является установка служб интеграции Hyper-V на серверах перед их перемещением в Azure. Мы решили выполнить этот шаг вручную, потому что официально задокументированный процесс, основанный на сценариях запуска , оказался несколько ненадежным.
Таким образом, в нашем процессе серверы сначала будут преобразованы в машины Hyper-V; затем будет установлена ​​HVIS и удалены инструменты VMware, а затем они будут перемещены в Azure.

Процесс был определен, протестирован и задокументирован; работает правильно.

ТЕМ НЕ МЕНИЕ.

Одна конкретная система имеет очень странную проблему с драйверами устройств. Он не доверяет никаким драйверам устройства, в том числе родным, и требует ручного подтверждения перед установкой какого-либо оборудования. Это происходит не только с драйверами Hyper-V, но и с каждым устройством , включая те, драйверы которых являются родными для самой Windows; пример ниже:

введите описание изображения здесь

Это болезненно (при переходе с VMware на Hyper-V таких запросов 15–20), но с ним можно справиться, если есть ручное взаимодействие с сервером. Однако, когда сервер перемещается в Azure, он (предположительно) ожидает такого же ручного подтверждения перед установкой новых устройств Azure, включая новый сетевой адаптер; и, конечно же, это означает отсутствие сети и доступа к виртуальной машине Azure.

Почему это происходит? Как это исправить?

Мы попытались настроить систему на автоматический прием неподписанных драйверов (хотя они подписаны и этого не должно происходить вообще):

введите описание изображения здесь

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

Мы также попробовали sfc /scannow, но не обнаружили никаких проблем и не устранили проблему; chkdskтоже не нашел ничего плохого.

Почему именно этот сервер действует именно так?
Как мы можем это исправить?

Примечание: это не вызвано отсутствием обновления и / или просроченным сертификатом; Я попробовал новую свежую установку Windows Server 2003 на Hyper-V с использованием исходного ISO (у меня все еще есть копия), так что вообще без каких-либо обновлений, и ничего подобного не происходило.

no answer