Cuando administras muchos ordenadores en una organización, tener los controladores centralizados y bajo control marca la diferencia entre un despliegue limpio y un caos absoluto. En lugar de ir equipo por equipo instalando drivers a mano, lo más eficiente es montar un repositorio local de controladores bien organizado, accesible por red y fácil de actualizar.
Además de simplificar las instalaciones desde cero, un buen repositorio te permite mantener todos los dispositivos actualizados, automatizar tareas de provisión, trabajar con varias ramas y repositorios de código en herramientas como Visual Studio, e incluso combinarlo con secuencias de tareas o scripts de despliegue. Vamos a ver cómo montar ese repositorio local de drivers, cómo gestionarlo y cómo sacarle todo el jugo en entornos con múltiples equipos.
¿Qué es un repositorio local de drivers y por qué te interesa?
Un repositorio local de drivers es, básicamente, una carpeta centralizada en un servidor donde almacenas todos los controladores que vas a usar para desplegar y mantener tus equipos. En muchas suites de gestión (como soluciones de Endpoint Management y Security) este repositorio se aloja, por defecto, en el servidor principal, aunque también puedes ubicarlo en un servidor preferido cercano a los clientes.
La clave está en que esta ubicación sea accesible tanto como ruta UNC (\\servidor\recurso) como a través de una URL HTTP/HTTPS. Muchas herramientas de aprovisionamiento de hardware (HII, Hardware Independent Imaging y similares) necesitan ambos métodos para poder descargar los drivers según el estado del equipo, si está en entorno de preinstalación (personalizar el OOBE con FlyOOBE) o si ya tiene sistema operativo.
Este repositorio es el que alimenta a las secuencias de tareas de imagen, scripts de despliegue y procesos de actualización. En lugar de incrustar los drivers en la propia imagen (lo que crea imágenes específicas para cada modelo), se trabaja con imágenes independientes de hardware y se dejan los drivers en este almacén central.
Requisitos básicos del repositorio de controladores
Antes de crear el repositorio, conviene tener claro qué necesitas a nivel de infraestructura para que todo funcione como debe y los equipos puedan descargar los controladores sin problemas.
En primer lugar, la carpeta donde vayas a guardar los drivers tiene que estar compartida en red con una ruta UNC estable y bien definida. Esa misma ubicación, o una réplica de contenido, debe estar disponible vía URL. Muchas implementaciones utilizan un servidor web, o el propio servidor de gestión, para exponer ese contenido por HTTP.
En la consola de tu herramienta de gestión suele existir el concepto de servidores preferidos o de réplica de contenido. Es aquí donde debes indicar en qué servidor quieres que resida el repositorio de drivers. En entornos con varias sedes, lo normal es que cada oficina importante tenga su servidor preferido para que las máquinas no tengan que descargar drivers a través de una WAN saturada.
Además, hay una condición técnica clave: cada controlador que añadas al repositorio debe incluir su archivo .inf. Este archivo es el que describe el hardware que soporta el driver, las rutas de instalación, las dependencias, etc. Las herramientas de HII o de gestión de drivers no se basan en los ejecutables, sino en los .inf para mapear el hardware real con el driver correcto.
Cómo se genera la base de datos de drivers en el repositorio
Cuando tienes todos los controladores colocados en la carpeta correspondiente, entra en juego la herramienta de administración de drivers de tu suite de aprovisionamiento, que suele llamarse algo tipo Administración de controladores HII o similar. Desde ahí es donde realmente conviertes esa carpeta en un repositorio utilizable por las secuencias de tareas.
El proceso habitual parte de la consola principal: se accede al menú de Herramientas > Aprovisionamiento > Administración de controladores (el nombre exacto varía según el producto, pero el flujo es muy parecido). Una vez ahí, sueles tener un botón equivalente a “Generar biblioteca” o “Crear base de datos de drivers”, que es el que pone todo en marcha.
En el asistente, lo primero es verificar que la ubicación del repositorio es una ruta UNC válida. Si los archivos de drivers están en otra carpeta, se selecciona la correcta usando el botón de examinar. Acto seguido, se comprueba que la URL asociada a ese repositorio es la adecuada, ya que los clientes la utilizarán cuando estén en entornos donde solo se permita tráfico HTTP(S).
Una vez confirmadas la ruta UNC y la URL, se guarda la configuración. En ese momento, la herramienta de HII empieza a rastrear la carpeta del repositorio y a leer cada .inf, generando un archivo de base de datos (normalmente llamado drivers.db3 o similar). Este archivo es el que permitirá al sistema relacionar los IDs de hardware de cada dispositivo con el driver correcto sin intervención manual.
Al finalizar, la consola muestra un mensaje indicando el número total de archivos encontrados y cuántos de ellos se han procesado como controladores válidos. Es un buen momento para revisar si el número de drivers coincide más o menos con tus expectativas; si la diferencia es muy grande, probablemente falten .inf o haya drivers empaquetados de forma inadecuada.
Cada vez que añadas más controladores a ese repositorio, tendrás que repetir el mismo proceso de generación de biblioteca. La herramienta volverá a analizar la carpeta completa y actualizará la base de datos para incluir los nuevos drivers sin perder los anteriores.
Actualización de un repositorio ya existente
Un repositorio de drivers no es algo estático; con el tiempo cambian modelos de equipos, se introducen nuevas versiones de controladores y aparecen correcciones críticas. Por eso es importante tener una rutina clara para mantener actualizada la base de datos de drivers.
El flujo habitual es bastante sencillo: primero recopilas los nuevos controladores desde la web del fabricante o desde repositorios oficiales, verificas que cada paquete disponga de su archivo .inf correctamente estructurado y luego copias esos ficheros a la misma carpeta del repositorio central.
Una vez copiados, vuelves a la consola de administración de drivers, entras de nuevo en la sección de Administración de controladores HII, revisas que la ruta UNC y la URL son las mismas que ya estabas usando y vuelves a lanzar el proceso de generación de biblioteca. El sistema inspecciona todo el contenido, detecta nuevos ficheros e incorpora esos drivers a la base de datos.
Es recomendable que, dentro de la carpeta del repositorio, mantengas una estructura de subcarpetas lógica por fabricante, modelo o tipo de dispositivo (por ejemplo: /Dell/Portátiles, /HP/Sobremesa, /Controladores_Red, etc.). Aunque la herramienta HII sea capaz de escanear todo sin necesidad de esta organización, a la hora de hacer mantenimiento te ahorrará muchos dolores de cabeza.
Uso del repositorio en secuencias de tareas de imagen
Una vez tienes el repositorio en marcha, lo más habitual es integrarlo en tus secuencias de tareas de despliegue de imagen. Así consigues que, al instalar un sistema operativo desde cero, los drivers adecuados se apliquen automáticamente en función del hardware detectado.
En muchos entornos se utiliza una única secuencia de imagen para todos los modelos de equipos, y se añaden varios pasos de tipo “desplegar paquete de drivers”. Cada paso va asociado a una consulta WMI o un filtro por modelo de hardware que se encarga de que el paquete solo se ejecute en los equipos adecuados.
Por ejemplo, puedes tener un paso que solo se ejecute si la consulta WMI devuelve que el equipo es un modelo concreto de portátil, otro paso distinto para una familia de sobremesas de otro fabricante y así sucesivamente. De este modo, la misma secuencia de tareas cubre un parque muy heterogéneo de dispositivos sin necesidad de clonar y mantener múltiples flujos.
Estos pasos de despliegue de drivers se apoyan en el repositorio central y en la base de datos de drivers. La secuencia de tareas determina qué paquete debe instalarse y la herramienta de aprovisionamiento, apoyada en HII o sistema equivalente, localiza los drivers necesarios en el repositorio y los descarga bien por UNC o por URL, según el contexto.
Repositorios de drivers para que los usuarios actualicen su sistema
Una duda frecuente en muchos equipos de IT es si se puede preparar una secuencia de tareas formada únicamente por pasos de “desplegar paquete de drivers” y exponerla en un portal tipo Centro de software para que el propio usuario ejecute la actualización de drivers cuando la necesite.
Técnicamente es posible montar algo así siempre que tu herramienta de gestión permita lanzar secuencias de tareas bajo demanda y controle los permisos necesarios. El flujo consistiría en crear una secuencia sin pasos de instalación de sistema operativo ni formateos, únicamente con pasos de actualización de drivers basados en paquetes de tu repositorio.
Estos pasos seguirían utilizando el mismo mecanismo de consultas WMI o filtros por modelo, de modo que cada equipo solo ejecute los paquetes que realmente le corresponden. La gran diferencia es que, en lugar de disparar la secuencia desde la consola central como parte de un proyecto de imagen, se publicaría en una especie de “catálogo de aplicaciones” para que el usuario la ejecute cuando note problemas de drivers o cuando se planifique una campaña de actualización.
Eso sí, hay que tener en cuenta aspectos de estabilidad y soporte: no es lo mismo actualizar drivers en un equipo recién instalado que en uno que lleva meses en producción. Conviene probar muy bien estos paquetes de drivers y quizá reservar este tipo de secuencias a usuarios avanzados o a casos concretos en los que la actualización controlada esté bien justificada.
Gestión avanzada de repositorios y configuración a bajo nivel
Además del repositorio de drivers asociado a la herramienta de aprovisionamiento, en algunos productos entra en juego otra pieza crítica: los repositorios internos de datos o copias de seguridad que usan los cores o servidores centrales. Su configuración puede condicionarse a través del Registro de Windows, lo cual añade una capa adicional de complejidad.
En entornos donde se trabaja con soluciones de recuperación o protección (con servicios Core que gestionan repositorios internos), hay procedimientos formales para detener el servicio de forma segura antes de cambiar la configuración del repositorio. Esto incluye pausar la replicación entre nodos, pausar la protección de todas las máquinas y asegurarse de que no haya procesos en curso que dependan de ese servicio.
Una vez pausadas estas operaciones desde la consola (normalmente desde una sección tipo “Protected Machines”, seleccionando todos los equipos y eligiendo acciones como “Pausar protección”, “Pausar replicación” y “Cancelar todas las operaciones”), se procede a detener el servicio principal en el sistema operativo, identificándolo en la consola de servicios de Windows.
En algunos escenarios muy concretos es necesario modificar la configuración interna del repositorio a través del Registro. Para ello se abre el editor de registro (regedit) desde el cuadro de ejecución, y se navega hasta rutas específicas del tipo HKLM\Software\AppRecovery\Core\Repositories\FileConfiguration\Specification.
En esa rama puede existir una entrada como “AllocationPolicy”, cuyo valor determina determinados comportamientos relacionados con la asignación de recursos del repositorio. Cambiar este valor (por ejemplo, estableciéndolo a 1) puede ser parte de un procedimiento de ajuste avanzado, siempre y cuando sepas exactamente qué estás haciendo y sigas una guía oficial.
Es fundamental recordar que tocar el Registro de Windows mal puede dejar tu sistema o tus repositorios inservibles. Por eso, los fabricantes suelen dejar claro que no dan soporte a problemas derivados de modificaciones incorrectas del Registro y recomiendan encarecidamente hacer una copia de seguridad antes de cambiar nada. Microsoft tiene documentación específica sobre qué es el Registro, cómo se estructura y cómo hacer copias de seguridad y restauraciones adecuadas.
Repositorios múltiples de código y drivers en Visual Studio
A la hora de gestionar drivers y herramientas asociadas, cada vez es más común que los equipos de desarrollo y sistemas trabajen juntos, usando herramientas de programación e IDE. En este contexto, Visual Studio 2022 y posteriores tienen una función muy interesante: la compatibilidad con múltiples repositorios Git activos a la vez, algo que ayuda bastante cuando el código y las herramientas de despliegue están repartidos en distintos proyectos.
A partir de la versión 17.4, Visual Studio permite tener hasta 25 repositorios activos simultáneamente en la misma instancia. Esto significa que puedes abrir una solución compleja que incluya proyectos de frontend, APIs, bases de datos, documentación, librerías de utilidades y scripts de despliegue, cada uno en su propio repositorio Git, y trabajar con todos a la vez sin necesidad de abrir múltiples ventanas del IDE.
La gestión de cuentas también está pensada para entornos multi-repositorio: si trabajas con más de una cuenta de GitHub, puedes cambiar entre ellas fácilmente. Visual Studio actualiza la configuración Git de cada repositorio para recordar qué cuenta se emplea en cada uno, lo que resulta muy útil si combinas repositorios corporativos y personales o si colaboras con diferentes organizaciones.
Administración de ramas y cambios en varios repositorios
La integración de varios repositorios en Visual Studio se refleja en todas las herramientas de Git integradas, especialmente en la ventana de “Cambios de Git” y en la del “Repositorio de Git”. Puedes gestionar escenarios donde una misma solución abarca varios repositorios de la misma forma que lo harías con uno solo, pero con mayor control y visibilidad.
Visual Studio permite crear ramas de forma simultánea en varios repositorios relacionados mediante un cuadro de diálogo extendido para la creación de ramas. Si, por ejemplo, estás preparando una nueva versión de tu herramienta de despliegue de drivers que toca tanto código del backend como scripts de automatización, puedes crear las ramas correspondientes en todos los repositorios de una sola vez.
Conforme vas haciendo cambios en cada proyecto, la ventana de “Cambios de Git” los separa por repositorio, manteniendo claro qué ficheros pertenecen a cada uno. Puedes preparar (stage) y confirmar (commit) esos cambios de la forma habitual, pero con una visión más ordenada sobre en qué repositorio estás trabajando en cada momento.
Los selectores de rama, tanto en la barra de estado como en la ventana de cambios, te permiten cambiar rápidamente de rama por repositorio. Además, desde el menú contextual de cada rama puedes realizar operaciones de flujo de trabajo habituales como fusionar (merge), reorganizar (rebase), renombrar, eliminar o comparar ramas, incluso en escenarios con varios repositorios abiertos.
Operaciones de red y configuración de repositorios Git
Cuando llega el momento de sincronizar tus cambios de código con los remotos, Visual Studio ofrece un diálogo de operaciones de red (push, fetch, pull) que te ayuda a seleccionar con precisión la rama de destino y el orden en el que empujas los cambios, lo que resulta especialmente importante cuando trabajas con múltiples repositorios a la vez.
En este diálogo puedes ejercer mayor control sobre operaciones como capturar (fetch) y extraer (pull), decidiendo qué ramas de qué repositorios quieres actualizar en cada momento. Esto es especialmente útil cuando no quieres mover todos los repositorios juntos, sino solo aquellos que están listos para sincronizarse con el remoto.
A nivel de configuración, Visual Studio permite ajustar opciones específicas de cada repositorio desde el panel de “Herramientas > Opciones”, dentro de la sección de Control de código fuente > Ajustes de Git > Configuración del repositorio Git. Desde ahí puedes, por ejemplo, indicar si deseas eliminar automáticamente ramas remotas obsoletas durante un fetch en ese repositorio en concreto.
Si necesitas aplicar ciertas políticas a todos los repositorios que manejas, puedes utilizar la configuración global de Git desde el mismo panel. De esta forma mantienes un conjunto de ajustes coherentes (como nombre de usuario, correo o comportamiento por defecto de ciertas operaciones) y, al mismo tiempo, tienes margen para personalizar el comportamiento de repositorios concretos según el proyecto.
Carga y activación de múltiples repositorios desde soluciones y carpetas
Hay dos enfoques principales para trabajar con múltiples repositorios en Visual Studio según cómo tengas organizado tu código y tus herramientas relacionadas con drivers y despliegues: a través de una solución (.sln) compartida o bien abriendo una carpeta que contenga varios directorios de repositorios.
En el caso de las soluciones, el flujo típico consiste en abrir una solución que ya tenga un repositorio inicializado y, después, agregar proyectos existentes que pertenezcan a otros repositorios. Para ello, haces clic derecho sobre la solución en el Explorador de soluciones, seleccionas “Agregar > Proyecto existente” y eliges el archivo .csproj del proyecto que tenga su propio repositorio Git inicializado.
Una vez agregado el proyecto, Visual Studio detecta automáticamente ese segundo repositorio y lo activa, de forma que todos los repositorios asociados a la solución pasan a ser visibles y manejables desde las ventanas de Git. Si creas un nuevo proyecto dentro de una solución que ya contiene otros repositorios, tendrás que inicializarlo con un git init para que también forme parte de la gestión multi-repositorio.
La otra modalidad es trabajar “por carpeta”. Si tus repositorios son relativamente independientes y no necesitan estar en la misma solución, puedes ubicarlos como subdirectorios dentro de una carpeta principal común. Desde la pantalla de inicio de Visual Studio eliges la opción “Abrir una carpeta local” y seleccionas esa carpeta raíz.
Visual Studio detectará cada subcarpeta que contenga un repositorio Git inicializado y los activará todos a la vez. A partir de ahí, las ventanas de “Cambios de Git” y “Repositorio de Git” realizarán el seguimiento de las modificaciones por repositorio, ofreciéndote una vista unificada pero a la vez separada, ideal cuando gestionas herramientas relacionadas entre sí (por ejemplo, scripts de automatización de drivers, utilidades de administración, módulos web de gestión, etc.).
Al final, montar y cuidar un repositorio local de drivers, integrarlo en tus secuencias de despliegue y coordinarlo con repositorios de código en herramientas como Visual Studio te permite automatizar al máximo el aprovisionamiento y la actualización de equipos.
Combinar una buena organización de los controladores, procedimientos seguros para ajustar repositorios internos y una gestión ordenada de ramas y repositorios Git hace que mantener muchos dispositivos y proyectos relacionados deje de ser un rompecabezas y se convierta en un proceso repetible, trazable y bastante más tranquilo. Comparte esta guía y más usuarios sabrán del tema.