.png)
Fundo:
Vários sistemas herdados do Windows Server 2003 precisam ser migrados do VMware para o Azure.
Sim, sabemos que eles têm um sistema operacional legado. No entanto, temos que mantê-los funcionando. E isso é (pelo menos parcialmente)suportado pela Microsoft.
Uma etapa crítica é, obviamente, instalar os Serviços de Integração Hyper-V nos servidores antes de movê-los para o Azure. Optamos por fazer esta etapa manualmente, poiso processo oficialmente documentado baseado em scripts de inicializaçãoprovou ser pouco confiável.
Assim, em nosso processo, os servidores serão primeiramente convertidos para máquinas Hyper-V; então o HVIS será instalado e o VMware Tools será removido e, em seguida, eles serão movidos para o Azure.
O processo foi definido, testado e documentado; funciona corretamente.
NO ENTANTO.
Um sistema específico tem um problema muito estranho com drivers de dispositivo. Não confiaqualquerdriver de dispositivo, incluindo os nativos, e pede confirmação manual antes de instalarqualquerhardware. Isso não acontece apenas com drivers Hyper-V, mas comcada dispositivo, inclusive aqueles cujos drivers são nativos do próprio Windows; exemplo abaixo:
Isso é doloroso (ao migrar do VMware para o Hyper-V, há de 15 a 20 desses prompts), mas pode ser sobrevivido desde que haja interação manual com o servidor. No entanto, quando o servidor é movido para o Azure, ele (presumivelmente) aguarda a mesma confirmação manual antes de instalar os novos dispositivos do Azure, incluindo o novo adaptador de rede; e, claro, isso significa nenhuma rede e nenhuma forma de acessar a VM do Azure.
Por que isso está acontecendo? Como isso pode ser consertado?
Tentamos configurar o sistema para aceitar drivers não assinados automaticamente (embora issosãoassinado e isso não deveria acontecer):
No entanto, o servidor continua fazendo o mesmo e pedindo confirmação antes de instalar qualquer novo hardware (e avisando que não passou no teste do logotipo do Windows).
Também tentamos sfc /scannow, que não detectou nenhum problema e não resolveu o problema; chkdsktambém não encontrei nada de errado.
Por que este servidor específico está agindo dessa maneira?
Como podemos consertar isso?
Observação: isso não é causado por uma atualização ausente e/ou um certificado expirado; Tentei uma nova instalação do Windows Server 2003 no Hyper-V usando o ISO original (ainda tenho uma cópia), portanto, sem nenhuma atualização, e não fez nada parecido com isso.