Error 0x80070002 al crear conmutador virtual

Error 0x80070002 al crear conmutador virtual

Con las tarjetas de red de 1 Gb de 4 puertos Hewlett Packard Enterprise (HPE) [controlador Intel 369i o Intel 350i] al intentar crear y asignar una tarjeta de red en una máquina con Windows Server 2019 y 2022 aparece el error:

Error applying virtual switch properties changes. Failed while adding virtual ethernet switch connections.
[...]
The system cannot find the file specified. (0x80070002)

Error al agregar conexiones del conmutador Ethernet virtual.
[...]
El sistema no puede encontrar el archivo especificado.

El problema aparece con los drivers de Microsoft, es necesario descargar e instalar los drivers del fabricante Intel E1R, en estos momentos la versión 12.18.11.1 (19 abr 2021), una vez instalados (no es necesario reiniciar) puedes crear cualquier adaptador virtual asociado sin problema.

Windows NT virtualizado en VMware

En ocasiones por limitaciones de presupuesto, disponibilidad de software, recursos… no es posible en la práctica real tener todos los sistemas actualizados como nos gustaría. Con estas premisas nos toca virtualizar un equipo obsoleto con nada más y nada menos que Windows NT, nos remontamos al año 1993! Aquí es donde la virtualización nos ayuda a dar una solución estable a varios problemas que nos podemos encontrar:

– Reutilización de dongles de seguridad con puerto paralelo (LPT1)
– Ejecución de código de programas para Win16

En nuestro caso concreto no era posible ejecutar el programa ni en Windows 2000, por lo que tuvimos que extraer los discos para crear un disco duro virtual a partir del físco. Una vez creada la máquina en nuestro entorno de virtualización pudimos empezar a actualizar Windows NT a la última versión disponible Service Pack 6a y los discos de instalación originales.

El siguiente paso tocaba mejorar el sistema de ficheros, desde FAT (no fat32) a NTFS dentro del entorno ya virtualizado y redimensionar las particiones originales de 2 GB, ciertamente la máquina NT se había comportado de forma más o menos estable (dentro de los esperable) todos estos años. La conversión desde el propio equipo con el comando:

convert C: /fs:ntfs


Después de un par de reinicios, ya teníamos una mejora necesaria. Aprovechamos para optimizar el funcionamiento, añadiendo un disco duro adicional al sistema para el archivo de paginación y ampliar la RAM hasta los 3 GB, más que suficiente en este caso. La máquina virtualizada en un entorno más estable y controlado empezada a notarse menos perezosa en sus inicios.

Ahora necesitábamos red, en VMware la instalación debía ser sencilla instalando los drivers y las herramientas de integración para el driver AMD PCNET Family Ethernet Adapter pero en este caso se torno algo más complicado al no encontrar los drivers en las fuentes que indica el fabricante. Tras varias pruebas con diferentes discos de instalación, encontramos 2 fuente fiables para los drivers:

– Driver de HP: SP1657
– Driver de IBM: 32p0067

En ambos casos hallamos los archivos que requeríamos para la instalación de la tarjeta de red, sin acudir a los CDs de Windos NT 4.0:

– amddlg.dll
– Amdpcn.sys
– Oemsetup.inf
– vmxnet.sys

Tras el obligado reinicio, ya disponíamos de conectividad de red a través del host:

Actualización: dependiendo de los requisitos tambien es posible virtualizar Windows NT en Hyper-v

Drivers firmados en Windows

Para la mayoría de nosotros, con el avance de las versiones de Windows, la instalación de drivers (controladores de dispositivos) se ha simplificado hasta prácticamente no tener que realizar ninguna acción si disponemos de una conexión a internet.

La relación de un fabricante o ensamblador con Microsoft va a poder verse a la hora de instalar nuestro nuevo hardware. Aquellos pantallazos azules (Blue Screen of Death, BSoD) solían estar producidos por drivers o fallos físicos, pero la percepción del usuario final es que el sistema operativo se había quedado “colgado”.

Con el paso de las versiones, empezaba a ser obligatorio/necesario la firma de los controladores como paso para ser instalados. De este modo Microsoft añadía una opción mínima de defenderse frente a paradas del sistema y los fabricantes se veían en la obligación de pasar ciertas pruebas de compatibilidad.

Denominaremos drivers al software que comunica un dispositivo con el sistema operativo, esta labor de mediación puede fallar, dependerá del fabricante corregirla y del S.O. tratarla para que no afecte al resto de programas.

Si el día de mañana Microsoft restringiera el soporte hardware a un único fabricante, pongamos por ejemplo HP; estaríamos frente a una nueva Apple, en la que el fabricante controla mayoritariamente la plataforma física sobre la que debe funcionar su sistema operativo. Con este control es más fácil evitar problemas de compatibilidades, interrupciones… pero no deja de ser una restricción comercial, casi monopolio llevándolo al extremo.

Teniendo en cuenta que existe soporte a millones de dispositivos y fabricantes no todos ellos tienen la misma relación… teniendo en cuenta lo que hasta ahora hemos comentado, seguimos teniendo la posibilidad de instalar drivers no firmados sabiendo lo que ello significa:

BCEDIT /set nointegritrychecks ON

Para desactivar de nuevo:

BCEDIT /set nointegritrychecks OFF

Recuerda ejecutar el comando BCEDIT con privilegios de administrador, de otro modo aparecerá un mensaje de error como este: