Windows en Arm: ¿se cargará realmente el controlador de VPN?
Una aplicación emulada puede iniciarse mientras un controlador de VPN en modo núcleo no puede cargarse. Compruebe la arquitectura del paquete y los componentes necesarios antes de migrar un portátil.
El instalador se ejecuta, la ventana se abre y aparece el aviso de inicio de sesión, así que la migración parece terminada. Luego el túnel falla en el punto en que el cliente necesita su adaptador virtual, y el error menciona un servicio o un controlador en lugar de credenciales. En Windows en Arm esta secuencia es habitual, porque la regla de compatibilidad cambia entre código en modo usuario y código en modo núcleo. Aprobar un portátil exige la segunda comprobación, no la primera.
Pida la arquitectura del paquete completo y luego vérifiquela en la máquina.
La parte que la emulación no cubre
Windows en Arm puede ejecutar aplicaciones x86 y x64 mediante emulación mientras permanezcan en modo usuario. Los componentes en modo núcleo no reciben ese trato: un controlador debe compilarse para Arm64 para cargarse. Microsoft documenta ese límite, y es exactamente donde suelen estar los clientes de VPN, porque muchos instalan un adaptador de red virtual o un controlador de filtro.
Así, un paquete puede mostrar una interfaz funcional y aun así ser inutilizable. El fallo aparece como un adaptador ausente, un servicio que no arranca o un túnel que nunca se establece. Ese es el punto en el que un piloto debe detenerse. Una pantalla de inicio de sesión no es prueba de una ruta de datos funcional.
Tres condiciones que deciden la migración
La primera es el paquete. Una compilación x64 y una compilación Arm64 se llaman ambas de 64 bits y no son intercambiables, así que una descarga descrita solo como Windows de 64 bits no demuestra nada sobre un dispositivo Arm. El instalador compatible del fabricante para esa arquitectura es el único punto de partida aceptable.
La segunda son los demás componentes necesarios. Las comprobaciones de estado del dispositivo, los asistentes de autenticación en el navegador y el middleware de tarjetas inteligentes pueden tener cada uno su propio requisito de arquitectura, y un éxito solo del túnel no demuestra que se cumpla la política de acceso de la organización.
La tercera es la pasarela y su conjunto de clientes compatible. Si el cliente aprobado no tiene compilación para Arm, otro cliente solo es aceptable cuando el propietario de la pasarela admite el protocolo de ese cliente, su método de autenticación y el comportamiento de su política. Un perfil de VPN de Windows integrado no puede sustituir a un cliente propietario solo porque ambos se describan como IPsec.
Lea la arquitectura en el dispositivo
Confirme qué es la máquina y luego mire qué controladores instaló realmente el paquete. Enumerarlos lleva un minuto y evita una discusión sobre qué significa "64 bits".
Get-CimInstance Win32_OperatingSystem | Select-Object OSArchitecture $env:PROCESSOR_ARCHITECTURE pnputil /enum-drivers | Select-String -Pattern 'vpn|tap|wintun' -Context 0,3 Get-NetAdapter | Format-Table Name,InterfaceDescription,DriverProvider
Si la lista de adaptadores no muestra nada para el cliente, o la entrada del controlador informa de una discrepancia de arquitectura, la migración se detiene ahí. Poner un controlador Arm64 en el contenedor antiguo no es algo que el fabricante admita, y los ajustes de modo de compatibilidad no convierten un controlador de núcleo x64.
Compare la versión instalada con la lista compatible del fabricante para Arm, y anote la diferencia si el instalador vino de un repositorio interno en lugar del fabricante.
Apruebe la carga de trabajo, no la pantalla de inicio de sesión
Ejecute el piloto con el dispositivo funcional anterior disponible como alternativa. Verifique el aprovisionamiento del perfil, la identidad prevista y cualquier comprobación del dispositivo, y luego pruebe la aplicación privada en lugar de solo el estado del túnel.
Incluya el DNS privado, las rutas y las familias de direcciones necesarias, la reconexión tras un cambio de red y el estado desconectado especificado. Registre las versiones del cliente y de los componentes junto con el resultado, porque la próxima actualización volverá a hacer las mismas preguntas.
Por último, confirme que existen vías de actualización y eliminación compatibles para esta plataforma. Un paquete que solo funciona tras sustituciones no documentadas crea el mismo problema de migración en la próxima versión, con menos tiempo para resolverlo.