Si cada vez que estrenas equipo te toca pasar horas instalando programas, ajustando Windows y montando tu entorno de desarrollo, ha llegado el momento de simplificar. WinGet y los archivos YAML te permiten convertir todo ese ritual pesado en un proceso prácticamente automático que puedes repetir en cualquier PC con un solo comando.
La idea es describir en un fichero de configuración qué quieres tener instalado y cómo debe estar configurado tu sistema, y dejar que Windows Package Manager (winget) junto con PowerShell Desired State Configuration (DSC) hagan el trabajo sucio: instalar software, aplicar ajustes, ejecutar scripts y comprobar que tu máquina queda justo en el estado que necesitas para ponerte a trabajar sin perder tiempo.
Qué es WinGet y por qué es tan útil para automatizar tu PC
WinGet es el gestor de paquetes oficial de Microsoft para Windows 10 y Windows 11. Funciona desde la línea de comandos y te permite instalar, actualizar, configurar y desinstalar aplicaciones de forma muy similar a lo que se hace en GNU/Linux con apt, dnf o similares, pero perfectamente integrado en el ecosistema Windows.
En lugar de buscar instaladores en cientos de webs, descargar EXE o MSI y pulsar “Siguiente, siguiente, aceptar”, con WinGet puedes lanzar una orden como winget install nombre-del-paquete y el sistema se encarga de descargar el programa de un origen confiable, ejecutar la instalación silenciosa y registrar el paquete para futuras actualizaciones.
Los orígenes principales de software que utiliza WinGet son la Microsoft Store y el repositorio de la comunidad alojado en GitHub, donde cada aplicación se describe mediante un manifiesto YAML que indica cómo instalarla, qué versión es, qué hash de integridad tiene, etc. Además, es posible añadir repositorios privados, por ejemplo uno propio de tu organización, para distribuir software interno de forma controlada.
Todo el ecosistema de WinGet se apoya en tres pilares:
- La CLI winget (el comando que usas en terminal).
- Los servicios que alojan y validan paquetes.
- Los archivos de configuración YAML que permiten definir de forma declarativa el estado deseado de una máquina completa, no solo aplicaciones sueltas.
Comandos básicos de WinGet para gestionar aplicaciones
Antes de meternos en harina con los archivos YAML de configuración, conviene dominar las órdenes básicas de WinGet para el día a día. Todo se gestiona desde PowerShell, Windows Terminal o el clásico símbolo del sistema.
Si simplemente escribes winget en una consola, verás la versión instalada, los subcomandos disponibles y un resumen de opciones. Desde ahí puedes empezar a trastear sin miedo.
Para instalar una aplicación usas el subcomando install. Por ejemplo, para poner Visual Studio Code en tu PC bastaría con:
winget install Microsoft.VisualStudioCode
En este caso, Microsoft.VisualStudioCode es el identificador exacto del paquete en el repositorio de WinGet. En muchos casos puedes instalar también usando el nombre tal cual aparece en la Store, entre comillas si tiene espacios, pero usar el ID reduce ambigüedades.
Si quieres actualizar tus programas, puedes pedir a WinGet que intente subir todo lo que reconozca con:
winget upgrade --all
O bien centrarte en una app concreta, por ejemplo:
winget upgrade Microsoft.VisualStudioCode
Las versiones modernas de WinGet son capaces de actualizar no solo lo que él mismo instaló, sino también aplicaciones que detecta en el sistema y que tienen un manifiesto asociado en sus orígenes.
Para desinstalar software, la mecánica es igual de sencilla:
winget uninstall Microsoft.VisualStudioCode
La eliminación funcionará siempre que WinGet tenga el programa mapeado en su catálogo, bien porque lo instaló él o porque lo reconoce a través de la información registrada en el sistema.
Cuando necesites localizar un programa, puedes usar winget search. Por ejemplo, para ver qué opciones de bloc de notas hay disponibles:
winget search notepad
El comando devolverá una lista con nombre, ID de paquete y origen (repositorio comunitario, Store o repositorio privado), y ese ID será el que deberías usar en install o upgrade para ir sobre seguro.
Si lo que buscas es saber qué software tiene controlado WinGet en tu equipo, puedes tirar de:
winget list
Con esto obtendrás un inventario de aplicaciones detectadas por el gestor de paquetes. Muy útil para decidir qué actualizar o qué incluir en tus archivos de configuración.
Automatizar instalaciones con archivos YAML: la gracia de todo esto
Lo realmente interesante llega cuando pasas de teclear comandos uno a uno a describir tu entorno ideal en un único archivo YAML. En lugar de tener una chuleta de órdenes o un script frágil, defines de forma declarativa cómo quieres que quede la máquina y delegas en WinGet y DSC el trabajo.
Un archivo de configuración de WinGet contiene la lista de paquetes, versiones, herramientas, scripts y ajustes de sistema que necesitas para tu entorno de desarrollo (o para el de toda la empresa). No solo se limita a instalar programas: puede activar características de Windows, retocar el registro, gestionar servicios, lanzar scripts de PowerShell… Todo lo necesario para dejar el PC en un estado concreto.
Para que esto funcione necesitas tener una versión de WinGet suficientemente reciente, en concreto v1.6.2631 o superior, que es cuando se introduce de forma estable la integración con DSC 3.0 y el comando winget configure, encargado de procesar los archivos YAML de configuración.
La ventaja es que el proceso se vuelve desatendido y repetible. Ejecutas una orden, aceptas los acuerdos necesarios y puedes irte a por un café mientras el sistema instala todo lo necesario, ajusta Windows, configura tus IDE y deja el entorno listo para usar. Y si mañana cambias de PC, repites la jugada y listo.
Además, estos ficheros se pueden guardar en un repositorio Git, en OneDrive o donde quieras, compartir con tu equipo, versionar cambios, abrir issues y pull requests… En definitiva, tratar la configuración de tu máquina como código (IaC) y no como algo manual e irrepetible.
El comando winget configure y sus opciones principales
La puerta de entrada a todo el sistema declarativo es el comando winget configure. Este se encarga de leer tu archivo de configuración de WinGet, validar que es correcto, descargar los módulos de PowerShell necesarios y aplicar los cambios.
Antes de meterte a fondo conviene habilitar los componentes de configuración (si aún no están activos) con:
winget configure --enable
Una vez hecho, lo más sensato es empezar validando el fichero YAML con la orden:
winget configure validate -f ruta\a\archivo.winget
La validación comprueba tanto la sintaxis YAML como el cumplimiento del esquema JSON oficial de configuración. Hay que tener en cuenta que YAML es delicado con la indentación (espacios, no tabuladores), así que editar estos archivos en Visual Studio Code con la extensión YAML de RedHat y el esquema de WinGet enlazado es casi obligatorio para no volverse loco.
Cuando todo pinta bien, puedes aplicar la configuración en serio con:
winget configure --file ruta\a\archivo.winget --accept-configuration-agreements
En ese momento entra en juego el procesador de configuración, que interpreta el YAML, baja los módulos de DSC desde PowerShell Gallery si faltan y empieza a ejecutar aserciones y recursos. Las tareas que lo permitan se ejecutan en paralelo. Aquellas que requieran privilegios de administrador provocarán un aviso UAC al inicio para elevación.
Si prefieres hacer una “prueba en seco” antes de cambiar nada, puedes usar:
winget configure test -f ruta\a\archivo.winget --accept-configuration-agreements
Con test, WinGet evalúa el sistema comparándolo con el estado deseado descrito en el archivo y te indica qué cosas no cuadran, sin tocar todavía la máquina. Es muy útil para ajustar configuraciones complejas y garantizar que al aplicar el archivo no habrá sorpresas.
También es posible trabajar con archivos remotos, por ejemplo alojados en un repositorio público o privado, lanzando algo como:
winget configure --accept-configuration-agreements --disable-interactivity -f https://tu-servidor/tu-config.winget
Esta forma de uso encaja muy bien en escenarios de despliegue masivo o administración centralizada, donde IT publica una configuración y los usuarios o scripts solo tienen que ejecutar un comando para dejar el equipo corporativo con el estándar definido.
Argumentos, opciones y subcomandos de winget configure
El subcomando configure admite una serie de parámetros para afinar el comportamiento. Algunos de los más relevantes son:
- -f, –file. Ruta al archivo de configuración de WinGet que se va a aplicar.
- –module-path. Carpeta local donde se almacenarán los módulos DSC descargados (por defecto en %LOCALAPPDATA%\Microsoft\WinGet\Configuration\Modules).
- –processor-path. Ubicación de un procesador de configuración personalizado, si procede.
- –accept-configuration-agreements. Acepta de antemano la advertencia de configuración para evitar un aviso interactivo.
- –suppress-initial-details. Intenta ocultar los detalles iniciales de configuración para una salida más limpia.
- –enable / –disable. Activa o desactiva los componentes de configuración (requiere acceso a la Store).
- –logs, –open-logs. Abre la carpeta donde se guardan los registros de configuración.
- –verbose, –verbose-logs. Habilita registro detallado para depurar problemas.
- –nowarn, –ignore-warnings. Suprime los mensajes de advertencia en la salida.
- –disable-interactivity. Impide cualquier tipo de prompt interactivo, ideal para scripts desatendidos.
- –proxy / –no-proxy. Permite definir un proxy para esa ejecución concreta o desactivar el uso de proxy.
Además del comando principal, winget configure dispone de varios subcomandos que conviene conocer:
- winget configure show -f <archivo>. Muestra los detalles de un archivo de configuración concreto, útil para inspeccionarlo sin abrirlo en un editor.
- winget configure list. Enseña un resumen de las configuraciones que se han aplicado al sistema, lo que ayuda a tener rastro de lo que se ha ejecutado.
- winget configure test -f <archivo>. Modo de comprobación que contrasta el estado actual del sistema con el definido en la configuración.
- winget configure validate -f <archivo>. Valida sólo el archivo, sin tocar la máquina.
- winget configure export -o <salida>. Permite exportar recursos de configuración a un archivo, ya sea todas las configuraciones de paquete (
--all), un paquete concreto (--package-id) o un recurso específico (--moduley--resource), anexando al fichero de salida si ya existe.
Formato y convención de nombres de los archivos de configuración WinGet
Los archivos de configuración de WinGet usan formato YAML con un esquema JSON asociado que define la estructura válida. El sistema de manifiestos del propio WinGet también se basa en YAML. Así que todo encaja dentro del mismo modelo.
Por convención, estos archivos se guardan con la extensión .winget, por ejemplo configuration.winget. En proyectos con Git suele recomendarse guardarlos bajo un directorio oculto .config, quedando rutas como ./.config/configuration.winget para la configuración “por defecto” del proyecto.
Si tu proyecto maneja distintas combinaciones de herramientas o preferencias, puedes mantener varios archivos de configuración en esa misma carpeta, cada uno con un nombre descriptivo que indique qué entorno levanta (por ejemplo frontend.winget, backend.winget, etc.).
La primera línea del archivo suele ser un comentario especial para que los editores sepan qué esquema JSON deben utilizar. Suele verse algo del estilo:
# yaml-language-server: $schema=https://aka.ms/configuration-dsc-schema/0.2
En la dirección base https://aka.ms/configuration-dsc-schema/ puedes consultar la versión de esquema más reciente y actualizar tu archivo cuando Microsoft publique nuevas revisiones con más capacidades.
Tras esa cabecera, el nodo raíz del documento es siempre properties, que debe incluir un campo configurationVersion (por ejemplo 0.2.0) y las dos grandes secciones que articulan todo: assertions y resources.
Estructura de un archivo de configuración: properties, assertions y resources
Bajo el nodo properties se declara, por un lado, la configurationVersion, que deberías ir incrementando a medida que evolucionas el archivo, y por otro lado las colecciones assertions y resources que describen el comportamiento.
- La sección assertions. Engloba las aserciones o condiciones previas que deben cumplirse para que ciertos recursos tengan sentido: versión mínima de Windows, presencia de alguna característica, etc. No son acciones en sí mismas, sino comprobaciones del entorno.
- La sección resources. Recoge todos los recursos de configuración que pretendes aplicar: instalaciones de software, ajustes de sistema, scripts, gestión de servicios, cambios en el registro, etc. Cada elemento de estas listas se representa a través de un nodo de tipo
resourcecon la información necesaria.
En ambos casos, cada entrada se define indicando el recurso DSC que se va a usar, con el formato {NombreModulo}/{NombreRecursoDSC}. Por ejemplo, Microsoft.Windows.Settings/WindowsSettings para tocar ajustes de Windows, o Microsoft.WinGet.DSC/WinGetPackage para instalar un paquete de WinGet desde DSC.
Junto al campo resource, cada unidad suele llevar secciones de directives y settings, un identificador opcional id y, cuando hace falta, una lista de dependencias dependsOn hacia otros recursos o aserciones.
Aserciones: comprobar versión de Windows y otros requisitos previos
Las aserciones (assertions) actúan como filtros previos que deciden si tiene sentido ejecutar ciertos recursos en la máquina actual. De este modo, no intentas instalar o configurar algo en un sistema que no cumple los requisitos básicos.
Un ejemplo típico es comprobar la versión mínima del sistema operativo. Muchas configuraciones requieren, como poco, Windows 10 1809 o algún build concreto de Windows 11, y es absurdo seguir adelante si estás en una versión demasiado antigua que ni siquiera soporta WinGet.
Una aserción de este estilo utiliza recursos DSC como Microsoft.Windows.Developer/OsVersion, indicando vía settings una propiedad MinVersion (por ejemplo ‘10.0.22000’) que define el umbral aceptable para la configuración.
Las aserciones se pueden evaluar en paralelo, sin un orden estricto, y devuelven esencialmente un estado true o false. Si la aserción devuelve false (no se cumple), cualquier recurso que la incluya como dependencia mediante dependsOn se omitirá automáticamente.
Ese comportamiento se considera un resultado correcto desde la perspectiva del sistema declarativo: mejor saltarse un bloque que no tiene sentido, que forzar su ejecución en un entorno inadecuado. Los mensajes de salida pueden mostrar algo como que un recurso “no se ejecutó porque una aserción falló o fue falsa”.
Aunque parte de la configuración no se aplique, WinGet intentará seguir adelante con otros recursos independientes para llevar el sistema lo más cerca posible del estado deseado. Al finalizar, tú eres quien debe revisar los errores y decidir si cambias la configuración o el entorno.
Recursos: instalar paquetes, ajustar Windows y lanzar scripts
La sección resources es el corazón práctico del archivo de configuración. Aquí enumeras todo lo que quieres que ocurra en la máquina: instalación de software, cambios en la configuración del sistema, ejecución de scripts de PowerShell, gestión de servicios, etc.
Cada recurso se define con un campo resource que sigue la forma Modulo/RecursoDSC, por ejemplo Microsoft.Windows.Settings/WindowsSettings para activar funciones del sistema, o Microsoft.WinGet.DSC/WinGetPackage para orquestar la instalación de un paquete a través de WinGet desde DSC.
Opcionalmente, puedes asignar a cada recurso un id único que te servirá para referenciarlo desde dependsOn en otros recursos. Esto es muy útil cuando quieres, por ejemplo, que la configuración de componentes extra de Visual Studio dependa explícitamente de que el propio Visual Studio se haya instalado antes.
Dentro de cada recurso, la sección directives contiene información contextual sobre cómo debe ejecutarse: descripción textual de la tarea (description), si se aceptan módulos de versión preliminar desde PowerShell Gallery (allowPrerelease) y el securityContext que indica si la ejecución necesita privilegios elevados.
Cuando pones securityContext: elevated, WinGet solicitará permisos de administrador una vez al inicio de la configuración y a partir de ahí podrá ejecutar recursos elevados y no elevados usando procesos distintos, sin bombardearte con más ventanas de UAC.
La sección settings define los pares nombre-valor que se pasan al recurso DSC. Puede ser algo tan simple como DeveloperMode: true para activar el modo desarrollador de Windows, o parámetros más complejos como el id y source de un paquete de WinGet, la ruta a un archivo .vsconfig, un valor de registro concreto o los detalles de un servicio que hay que habilitar.
Por último, el campo dependsOn te permite declarar que este recurso debe ejecutarse solo cuando ciertas aserciones o recursos previos hayan concluido con éxito. Si una de esas dependencias falla, el recurso se marca automáticamente como no ejecutado o fallido, evitando efectos colaterales indeseados.
Organizar la sección resources de forma legible
En proyectos grandes, los archivos de configuración pueden crecer bastante, así que merece la pena pensar un poco cómo organizas la sección resources para que siga siendo mantenible con el paso del tiempo.
Una estrategia habitual es ordenar los recursos según un orden lógico de ejecución:
- Primero lo que prepara el sistema (aserciones, actualizaciones básicas).
- Luego herramientas genéricas (navegadores, compresores, utilidades).
- Después IDE y SDK.
- Al final scripts o ajustes más específicos.
Otro enfoque interesante es agruparlos por probabilidad de fallo o complejidad. Es decir, poner al principio las tareas que más suelen romperse (instalaciones pesadas que dependen de buena conexión o credenciales), para que el usuario se dé cuenta pronto de que algo no va bien sin esperar a que termine todo.
Mucha gente prefiere agrupar por tipo de recurso: primero paquetería WinGet, luego configuraciones de Windows (registro, características, servicios), después scripts y, por último, herramientas muy específicas de un proyecto concreto. Este estilo suele recordar a la estructura típica de un proyecto de software y ayuda a orientarse rápido.
Sea cual sea el criterio, es muy recomendable acompañar el archivo con un README en el repositorio explicando la estructura de la configuración, las dependencias clave, las versiones mínimas de Windows requeridas y los pasos recomendados de ejecución.
Esa documentación hace que otros desarrolladores puedan contribuir al archivo con menos riesgo de romper algo, ya que entienden mejor qué hace cada bloque y qué aserciones o dependsOn están en juego antes de añadir un recurso nuevo.
Uso de la variable ${WinGetConfigRoot} en rutas de archivo
Muchos recursos DSC aceptan parámetros que esperan rutas a ficheros concretos: configs de Visual Studio, scripts, plantillas, etc. Si usas rutas absolutas, tu archivo pierde portabilidad en cuanto cambias de usuario, unidad o carpeta.
Para evitarlo, WinGet introduce la variable ${WinGetConfigRoot}, que apunta al directorio desde el que ejecutas winget configure. A partir de ahí puedes construir rutas relativas que funcionarán igual en cualquier equipo donde se respete la misma estructura de carpetas.
Si, por ejemplo, guardas el archivo de configuración en .config/configuration.winget y el archivo .vsconfig en la raíz del repositorio, puedes usar una ruta como '${WinGetConfigRoot}\..\.vsconfig'. La parte .. sube un nivel desde la carpeta de trabajo y te deja justo en el directorio donde vive .vsconfig.
Esta técnica hace que la misma configuración sea válida para todos los miembros de un equipo que clonen el proyecto en rutas distintas, siempre que respeten la colocación relativa de los archivos dentro del repo.
Eso sí, conviene recordar en el README que el usuario debe asegurarse de que el archivo objetivo existe en la ruta relativa que espera la configuración antes de lanzar winget configure, o la ejecución marcará errores en esos recursos.
Dónde encontrar módulos DSC y recursos listos para usar
Para que todo este entramado funcione, WinGet se apoya en módulos de PowerShell que implementan recursos DSC. Algunos vienen “de serie” con el propio sistema (los llamados recursos de bandeja de entrada) y otros se consiguen desde PowerShell Gallery.
Entre los recursos estándar tienes módulos para gestionar variables de entorno (Environment), instalar o desinstalar paquetes MSI (msiPackage), manipular claves y valores del Registro (Registry), ejecutar bloques de script (Script), controlar servicios de Windows (Service), añadir o quitar roles y características (WindowsFeature) o arrancar y detener procesos (WindowsProcess).
La PowerShell Gallery alberga cientos de módulos adicionales con recursos DSC aportados por la comunidad. Puedes usar los filtros de búsqueda para mostrar solo aquellos marcados como “Recurso DSC” y así localizar piezas reutilizables para tus configuraciones.
Eso sí, hay que tener presente que la galería no es un entorno totalmente auditado: cualquiera puede publicar módulos, y algunos pueden incluir scripting arriesgado o directamente malicioso si no se revisa con cuidado.
Por ese motivo, Microsoft insiste en que se revise siempre la procedencia y el contenido de los módulos antes de usarlos en configuraciones que vayan a ejecutarse en máquinas de producción, sobre todo si esos recursos se ejecutan con contexto de seguridad elevado.
Para ver ejemplos concretos de archivos de configuración, Microsoft mantiene un repositorio de configuraciones WinGet y YAML de DSC accesible a través del enlace corto https://aka.ms/dsc.yaml, donde puedes inspirarte y tomar como base plantillas ya probadas.
Seguridad, confianza y políticas de grupo relacionadas con WinGet
Dado que WinGet y DSC pueden instalar y configurar software de forma masiva, la parte de seguridad es fundamental, sobre todo en entornos corporativos donde hay requisitos de cumplimiento bastante estrictos.
WinGet se integra con Microsoft Store a través del origen msstore y emplea técnicas de anclaje de certificados (certificate pinning) para comprobar que el certificado HTTPS de la Store coincide con uno de los certificados conocidos y así evitar ataques de intermediario (MITM).
En organizaciones que usan firewalls con inspección SSL, este comportamiento puede provocar problemas si el dispositivo de seguridad reempaqueta la conexión con un certificado propio. Para esos casos existe una directiva llamada BypassCertificatePinningForMicrosoftStore que permite indicar si WinGet debe saltarse esa verificación.
Las opciones posibles pasan por dejar la directiva sin configurar (respetando el comportamiento recomendado por defecto), habilitarla para que WinGet no valide el certificado de Store o deshabilitarla explícitamente para forzar que solo acepte certificados conocidos de Microsoft.
Desactivar el anclaje de certificados aumenta el riesgo de ataques man-in-the-middle, así que debería hacerse solo con pleno conocimiento de causa y cuando no haya alternativa razonable, ajustándolo dentro de una estrategia global de seguridad.
Además de esta directiva, hay plantillas de políticas de grupo específicas para WinGet (archivos .admx y .adml) que permiten a los administradores controlar orígenes permitidos o bloqueados, activar o no funciones experimentales, definir comportamiento ante proxies y, en general, moldear cómo se comporta el gestor de paquetes en la organización.
Estas plantillas se distribuyen dentro del paquete DesktopAppInstallerPolicies.zip en el repositorio de GitHub de WinGet. Una vez descomprimidos, los ficheros se copian a C:\Windows\PolicyDefinitions y a la carpeta de idioma correspondiente, de modo que ya se pueden gestionar desde la consola de administración de directivas de grupo.
También existen objetos de política de grupo como EnableWindowsPackageManagerConfiguration y EnableWindowsPackageManagerConfigurationExplanation que permiten bloquear el uso de archivos de configuración de WinGet en toda la organización, por si se considera que esta funcionalidad debe limitarse estrictamente.
Repositorios adicionales y uso de fuentes privadas en WinGet
De fábrica, WinGet usa como fuentes principales la Microsoft Store y el repositorio comunitario en GitHub, donde se encuentran manifiestos para montones de programas populares: navegadores, suites de desarrollo, herramientas de diseño, utilidades varias, etc.
Sin embargo, muchas empresas necesitan algo más: repositorios privados donde alojar sus propias aplicaciones, paquetes internos, versiones validadas de ciertas herramientas o catálogos filtrados que cumplan con sus políticas.
WinGet permite registrar orígenes adicionales a través del comando:
winget source add --name <nombre_del_repositorio> --arg <URL_del_repositorio>
Este origen suele ser de tipo REST por defecto, aunque puedes especificarlo con --type si lo necesitas. Además, existen parámetros como –trust-level para definir el nivel de confianza (none o trusted) y –accept-source-agreements para aceptar automáticamente los acuerdos de licencia del origen, algo esencial cuando automatizas la incorporación de repos.
Para comprobar qué fuentes tienes ahora mismo en tu equipo, puedes ejecutar:
winget source list
Esta orden devuelve todas las fuentes disponibles con su nombre y tipo. A partir de ese momento las búsquedas e instalaciones de WinGet tendrán en cuenta los repositorios adicionales según la configuración que hayas establecido.
Hay proyectos que ofrecen soluciones listas para desplegar repositorios WinGet privados en Azure o en instalaciones on-premise usando Docker, lo que da bastante juego a la hora de montar catálogos corporativos o entornos controlados donde sólo existe el software aprobado por IT.
En la práctica, combinar repositorios privados con archivos de configuración YAML bien diseñados permite estandarizar por completo el software y la configuración de los equipos de una empresa, con la tranquilidad de que todo sale de un origen del que tú mismo tienes el control.
Con todo lo anterior, WinGet, sus archivos YAML de configuración y los recursos de DSC convierten la tediosa tarea de preparar y mantener PCs con Windows en un proceso mucho más rápido, repetible y seguro, tanto si eres un desarrollador que quiere clonar su entorno en varios equipos como si gestionas una flota de ordenadores en una organización y quieres dejar de hacerlo todo a mano.