.png)
Fondo:
Es necesario migrar varios sistemas Windows Server 2003 heredados de VMware a Azure.
Sí, sabemos que tienen un sistema operativo heredado. Sin embargo, tenemos que mantenerlos en funcionamiento. Y esto es (al menos en parte)apoyado por Microsoft.
Por supuesto, un paso fundamental es instalar los servicios de integración de Hyper-V en los servidores antes de trasladarlos a Azure. Elegimos realizar este paso manualmente, porqueEl proceso documentado oficialmente que se basa en scripts de inicio.ha demostrado ser algo poco fiable.
Por lo tanto, en nuestro proceso, los servidores se convertirán primero a máquinas Hyper-V; luego se instalará HVIS, se eliminarán VMware Tools y luego se trasladarán a Azure.
El proceso ha sido definido, probado y documentado; Funciona correctamente.
SIN EMBARGO.
Un sistema específico tiene un problema muy extraño con los controladores de dispositivos. no confíacualquiercontrolador de dispositivo, incluidos los nativos, y solicita confirmación manual antes de instalarcualquierhardware. Esto no sólo sucede con los controladores Hyper-V, sino también concada dispositivo, incluidos aquellos cuyos controladores son nativos del propio Windows; ejemplo a continuación:
Esto es doloroso (al pasar de VMware a Hyper-V hay entre 15 y 20 de esos mensajes), pero se puede sobrevivir siempre que haya interacción manual con el servidor. Sin embargo, cuando el servidor se mueve a Azure, (presumiblemente) espera la misma confirmación manual antes de instalar los nuevos dispositivos de Azure, incluido el nuevo adaptador de red; y, por supuesto, esto significa que no hay conexión a redes ni forma de acceder a la máquina virtual de Azure.
¿Por qué está pasando esto? ¿Cómo se puede arreglar?
Intentamos configurar el sistema para que acepte controladores no firmados automáticamente (aunquesonfirmado y esto no debería suceder en absoluto):
Sin embargo, el servidor sigue haciendo lo mismo y solicita confirmación antes de instalar cualquier hardware nuevo (y advierte que no ha pasado la prueba del logotipo de Windows).
También probamos sfc /scannow, que no detectó ningún problema y no solucionó el problema; chkdskTampoco encontré nada malo.
¿Por qué este servidor específico actúa de esta manera?
como podemos arreglar esto?
Nota: esto no se debe a una actualización faltante o a un certificado caducado; Probé una nueva instalación de Windows Server 2003 en Hyper-V usando el ISO original (todavía tengo una copia), sin ninguna actualización, y no hizo nada como esto.