Cuando quieres implementar aplicaciones de WinGet con Intune, debería ser un proceso sencillo. Al fin y al cabo, WinGet ya conoce la URL del instalador, la versión y los modificadores silenciosos de miles de aplicaciones de Windows, así que deberías poder indicar a Intune el catálogo e implementar la aplicación, ¿verdad?
Bueno, hay una pega. Intune no tiene ningún tipo de aplicación que pueda implementar directamente desde el repositorio comunitario de WinGet, solo aplicaciones de Microsoft Store. Para complicar aún más las cosas, la herramienta de línea de comandos de WinGet no es compatible cuando un script se ejecuta como SYSTEM, el contexto que usa Intune cuando el comportamiento de instalación de una aplicación está configurado como System.
Con esto en mente, ¿cómo puedes implementar WinGet con Intune? Hemos identificado cuatro métodos que pueden facilitar la implementación, así que veamos cuáles son, cuánto cuesta cada uno, cómo configurarlos y cómo resolver cualquier problema que puedas encontrar.
¿Puede Intune implementar aplicaciones de WinGet de forma nativa?
En parte. El tipo de aplicación de Microsoft Store (nuevo) de Intune usa Windows Package Manager para encontrar e instalar aplicaciones desde Microsoft Store. No puede acceder al repositorio comunitario de WinGet, el catálogo público que usa la mayoría de las guías de WinGet, y ningún tipo de aplicación de Intune realiza implementaciones desde él. Para implementar aplicaciones del repositorio comunitario, necesitas un contenedor de script o un paquete Win32.
Esa diferencia se debe a cómo está organizado WinGet. Extrae aplicaciones de dos fuentes principales: Microsoft Store (msstore) y el repositorio comunitario de WinGet en GitHub. La integración de Store de Intune, que sustituyó a Microsoft Store for Business, ya retirado, se conecta solo a la primera.
También puede que veas mencionado el Enterprise App Catalog de Microsoft en debates sobre Intune WinGet. Es una biblioteca independiente de aplicaciones Win32 que Microsoft prepara y aloja, y Microsoft afirma que no utiliza WinGet. También requiere una suscripción además de Intune Plan 1 o Plan 2.
Cuatro formas de usar WinGet con Intune
Si quieres implementar aplicaciones de WinGet con Intune, todavía hay formas de hacerlo. Estas son las cuatro formas más comunes de usar WinGet con Intune, incluida para qué es mejor cada una y sus limitaciones:
Método | Origen de la aplicación | Licencia adicional | Limitación principal | Ideal para |
1. Aplicación de Microsoft Store (nueva) | Microsoft Store (msstore) | Nada más allá de Intune | Solo aplicaciones publicadas en la Store; las aplicaciones Win32 de Store aún están en vista previa | Aplicaciones que el proveedor publica en Microsoft Store |
2. Ajuste de una aplicación Win32 en un script de WinGet | Repositorio de la comunidad de WinGet | Nada más allá de Intune | Escribes y mantienes scripts de instalación, detección y desinstalación; WinGet debe encontrarse y ejecutarse bajo SYSTEM | Una breve lista de aplicaciones de la comunidad y un equipo cómodo con PowerShell |
3. Correcciones que ejecutan actualizaciones de WinGet | Repositorio de la comunidad de WinGet | Windows Enterprise E3/E5 o Education A3/A5 | Mantiene actualizadas las aplicaciones instaladas; no gestiona la instalación inicial | Higiene de actualizaciones en dispositivos que ya tienen las aplicaciones |
4. Paquete Win32 nativo creado a partir del instalador | Instalador encontrado a través del manifiesto de WinGet o del proveedor | Nada más allá de Intune | Empaquetado, reglas de detección y pruebas para cada aplicación y versión | Implementaciones controladas y probadas a gran escala |
Así funciona cada método, paso a paso.
Método 1: implementa aplicaciones de Microsoft Store con el tipo de aplicación Microsoft Store (nuevo)
La primera forma (y posiblemente la más fácil) de implementar aplicaciones es a través de la aplicación Microsoft Store. Puedes hacerlo en unos pocos pasos rápidos:
En el centro de administración de Intune, ve a Apps → All Apps → Create y, después, selecciona Microsoft Store app (new) en Store app.
Selecciona «Buscar en la aplicación Microsoft Store» y busca la aplicación que quieras por nombre, editor o ID de aplicación de Store. Los resultados mostrarán si cada aplicación es Win32 o UWP.
Revisa la información precompletada de la aplicación, configura el comportamiento de instalación como Sistema o Usuario (ten en cuenta que algunas aplicaciones solo admiten una opción) y establece las opciones de Company Portal (como aplicación destacada y categoría).
Asigna la aplicación como Obligatoria, Disponible para dispositivos inscritos o Desinstalar, y configura las notificaciones para el usuario final, el periodo de gracia para el reinicio y la fecha límite de instalación.
Revisa y crea. Intune mantiene la aplicación actualizada a medida que aparecen nuevas versiones.
Dicho esto, hay algunas limitaciones y requisitos previos que te conviene tener en cuenta. Estos pueden complicar el proceso y puede que signifiquen que tengas que probar otro método:
Los dispositivos necesitan la Intune Management Extension, al menos dos núcleos de procesador y acceso de red a la Store y al contenido del editor.
Las aplicaciones Win32 en la Store siguen en vista previa, y no todas las aplicaciones Win32 se pueden buscar. Del mismo modo, las aplicaciones de pago y los instaladores ARM64 no son compatibles.
Las aplicaciones Win32 de la Store solo se mantienen actualizadas mientras sigan asignadas en Intune.
Los dispositivos registrados en Entra deben usar el comportamiento de instalación del sistema (por lo que Usuario no es una opción).
Método 2: incluir un comando de WinGet en una aplicación Win32
Si la aplicación Microsoft Store no se adapta a tus necesidades, puedes implementar WinGet a través de Intune encapsulando un comando de WinGet en una aplicación Win32. En estos casos, una aplicación Win32 es más fiable que un script de plataforma simple porque incluye detección de estado, códigos de retorno y un comando de desinstalación, de los que carecen las implementaciones con scripts de una sola línea.
Por qué WinGet falla cuando Intune se ejecuta como SYSTEM
Cuando el comportamiento de instalación de una aplicación Win32 se establece en System, Intune ejecuta su comando de instalación como SYSTEM, y ahí es donde falla WinGet. El WinGet CLI no es compatible con el contexto SYSTEM porque se distribuye dentro de App Installer, una aplicación empaquetada (MSIX) registrada por usuario. Como resultado, llamar a WinGet por nombre en un script SYSTEM normalmente falla porque SYSTEM no puede localizarlo.
Hay algunas soluciones alternativas. Los scripts de la comunidad suelen abordar este problema resolviendo winget.exe en C:\Program Files\WindowsApps\Microsoft.DesktopAppInstaller_*_x64__8wekyb3d8bbwe, pero este no es un método compatible con Microsoft. La opción compatible con Microsoft es el módulo de PowerShell Microsoft.WinGet.Client, que funciona en el contexto del sistema para las aplicaciones instaladas en todo el equipo.
Escribe el script de instalación
Para escribir el script de instalación, primero tendrás que encontrar el ID del paquete y luego instalarlo con ese ID exacto desde el repositorio de la comunidad. Puedes buscar el ID con winget search <app name>, o sin usar la línea de comandos en winstall, el navegador gratuito del catálogo WinGet de Splashtop. Una vez que tengas el ID, el comando de instalación tendrá un aspecto parecido a este: winget install --id Git.Git -e --source winget --silent --accept-package-agreements --accept-source-agreements
Para las instalaciones de SYSTEM, te convendrá incluir --scope machine. Ten en cuenta que Microsoft advierte que los instaladores EXE no gestionan el scope de forma coherente.
Para Microsoft Intune, el comando de instalación puede ser un script de PowerShell de hasta 50 KB. Usar powershell.exe en el campo de comando inicia la versión de 32 bits, mientras que usar la ruta Sysnative permite usar PowerShell de 64 bits.
Añade un script de detección
Asegúrate de añadir un script para detectar y confirmar cuándo la aplicación se instala correctamente. Intune considera que la aplicación está instalada solo cuando el script finaliza con el código 0 y escribe la salida en STDOUT; cualquier salida en STDERR se interpreta como no instalada. El script normalmente comprueba la carpeta de instalación de la aplicación, la versión del archivo o la clave de desinstalación del registro. Si lo compruebas con winget list, te encontrarás con el mismo problema de SYSTEM, así que es mejor usar comprobaciones de archivos o del registro.
Empaqueta los scripts y sube la aplicación Win32
Por último, empaqueta los scripts con Microsoft Win32 Content Prep Tool para generar el archivo .intunewin archivo. Después, puedes añadir ese archivo en Apps → All apps → Add → Windows app (Win32), establecer el comportamiento de instalación en System y añadir el comando de desinstalación, el script de detección y los requisitos. Usa rutas completas en el comando de desinstalación, ya que Intune no expande variables de entorno ahí.
Ten en cuenta que cada aplicación necesita su propio conjunto de scripts y actualizaciones, y que WinGet debe estar presente y funcionar en cada dispositivo en el que esté instalado. Por eso, este método puede requerir más mantenimiento que los demás.
Método 3: Mantén las aplicaciones de WinGet actualizadas con las correcciones de Intune
Con Intune Remediations, puedes emparejar un script de detección con un script de corrección. En el caso de WinGet, tu script de detección comprueba si una aplicación instalada tiene una nueva versión disponible; si es así, el script de corrección ejecuta winget upgrade para ese ID de paquete. Esto funciona como un método de actualización que se combina con los Métodos 2 y 4, pero no gestiona la instalación inicial.
La licencia es lo primero. Intune Remediations requiere Windows Enterprise E3 o E5 (incluido en Microsoft 365 F3, E3 o E5) o Windows Education A3 o A5, y los dispositivos deben estar administrados con Intune o coadministrados y ejecutar Windows Enterprise, Professional o Education.
Para mantener las aplicaciones actualizadas con Intune Remediations, solo tienes que seguir unos sencillos pasos:
En el centro de administración de Intune, ve a Dispositivos → Administrar dispositivos → Scripts y correcciones.
Crea un paquete de script con un script de detección que compruebe el ID del paquete para ver si hay una actualización disponible.
Añade un script de corrección que ejecute la actualización para ese ID con
--silenty ambas marcas--accept.Asígnalo a un grupo de dispositivos y configura una programación para comprobar si hay actualizaciones.
Asegúrate de seleccionar los ID de paquete específicos que quieres actualizar. Aunque puedes usar winget upgrade --all, eso actualizará todas las aplicaciones que WinGet reconozca, incluidas las que TI no ha aprobado ni probado. Ten también en cuenta que WinGet instala la versión más reciente del repositorio, por lo que puede implementar actualizaciones antes de que el equipo de TI tenga la oportunidad de probarlas. Si el script de corrección se ejecuta como SYSTEM, se encuentra con la misma limitación de WinGet que se explica en el Método 2.
Método 4: empaqueta el instalador como una aplicación Win32 nativa
También es posible volver a empaquetar el instalador como una aplicación Win32 nativa. En este caso, WinGet sirve como fuente de información de la aplicación, en lugar de la aplicación en sí. Al usar el manifiesto de WinGet para encontrar el instalador y sus modificadores silenciosos, puedes implementar el instalador como una aplicación Win32 estándar.
Esto significa que los dispositivos pueden implementar la aplicación sin un cliente WinGet operativo, el problema del contexto de SYSTEM no se aplica y tienes acceso a todas las funciones Win32 de Intune.
Puedes empaquetar el instalador como una aplicación Win32 en unos pocos pasos:
Encuentra el ID del paquete con
winget search(o búscalo en winstall) y revisa su manifiesto para ver el tipo de instalador, la URL de descarga y los modificadores silenciosos. (WinGet requiere que todos los instaladores incluidos admitan la instalación silenciosa).Descarga el instalador con WinGet o desde el proveedor.
Confirma el comando de instalación silenciosa para ese tipo de instalador. Nuestras guías sobre instalaciones silenciosas de MSI e instalaciones silenciosas de EXE explican los modificadores para cada tipo de instalador.
Empaqueta el instalador con Microsoft Win32 Content Prep Tool para crear el archivo .intunewin archivo.
Añádela como una aplicación de Windows (Win32), incluidos los comandos de instalación y desinstalación, una regla de detección (por código de producto MSI, archivo o registro), requisitos y códigos de retorno.
Prueba en un dispositivo de prueba limpio lo bien que la aplicación se instala, detecta una instalación completada y se desinstala antes de implementarla en más dispositivos.
Cada vez que se publique una nueva versión, tendrás que repetir la compilación y usar la sustitución para reemplazar la aplicación anterior.
Esta opción ofrece la mayor personalización y control para los equipos de TI, aunque también significa que tienen que repetir el proceso para cada aplicación y actualización. Como resultado, a los equipos con catálogos de aplicaciones grandes puede costarles seguir el ritmo de la carga de trabajo.
Entonces, ¿qué método es el más eficaz? Podemos desglosarlos y ver cuándo vale la pena esa compensación y cuándo otros métodos son mejores.
WinGet vs aplicación Win32 en Intune: qué enfoque encaja mejor
La decisión principal es si los dispositivos ejecutan WinGet en el momento de la instalación o reciben una aplicación Win32 que ya has empaquetado de antemano. Así se comparan ambas opciones:
Factor | WinGet en el momento de la instalación (métodos 2 y 3) | Aplicación Win32 empaquetada (método 4) |
Cliente WinGet en el dispositivo | Obligatorio y debe funcionar con SYSTEM | No es necesario |
De dónde procede el instalador | Descargado en cada dispositivo desde la URL del manifiesto | Subido una vez a Intune como un .intunewin archivo |
Versión que se instala | Lo que aparezca en el repositorio, a menos que se fije con | La compilación exacta que empaquetaste y probaste |
Detección | Un script que escribes y mantienes | Reglas integradas de MSI, archivo o registro, o un script |
Actualizaciones | Correcciones o un script nuevo por aplicación | Nuevo paquete con reemplazo |
Esfuerzo inicial | Precio reducido por aplicación | Más alto por aplicación |
Al comparar las opciones, podemos ver algunos detalles importantes. Para unas pocas utilidades de bajo riesgo, los scripts de WinGet pueden ser rápidos y requerir menos esfuerzo inicial. Para aplicaciones empresariales, dispositivos regulados o catálogos grandes, una aplicación Win32 empaquetada es más fiable porque proporciona versiones predecibles y permite hacer pruebas antes del despliegue.
Si la aplicación aparece en Microsoft Store, el método 1 suele ser la opción más ligera.
Problemas comunes al implementar aplicaciones WinGet con Intune
Incluso con el método adecuado, implementar aplicaciones WinGet con Intune tiene sus desafíos. Los equipos de TI pueden encontrar problemas comunes al implementar aplicaciones, pero pueden identificarlos y resolverlos.
Los problemas habituales incluyen:
1. WinGet no se reconoce en un script de Intune
Si tu script informa de que winget no se reconoce, lo más probable es que el script se esté ejecutando como SYSTEM, donde la CLI de WinGet no es compatible porque App Installer se registra por usuario. Esto puede solucionarse resolviendo winget.exe mediante su ruta completa o usando el módulo de PowerShell Microsoft.WinGet.Client, como se menciona en el Método 2.
2. La aplicación se instala para el usuario equivocado o en el lugar equivocado
Si la aplicación se instala en el lugar equivocado o para el usuario equivocado, es una cuestión del ámbito de instalación. Con SYSTEM, el ámbito de usuario se resuelve en el propio perfil de SYSTEM, mientras que los instaladores EXE gestionan de forma inconsistente el ámbito de usuario frente al de equipo. Para solucionarlo, usa --scope machine en las instalaciones con SYSTEM (asegúrate de probarlo primero antes de implementar la aplicación más ampliamente).
3. La descarga falla con un error 403 Forbidden
Si la descarga devuelve un error 403 Forbidden, es posible que el proveedor del software esté bloqueando el agente de usuario de WinGet en sus servidores de descarga. Si el instalador se descarga bien en un navegador, esa es probablemente la causa. Cuando eso ocurra, puedes descargar el instalador directamente e implementarlo como una aplicación Win32 empaquetada, como se explica en el Método 4.
4. Una aplicación de la Store no aparece en la búsqueda de Intune
Si una aplicación de Store no aparece cuando la buscas, puede deberse a una de estas tres razones: 1. No está disponible en tu región, 2. Es una aplicación de pago, lo que significa que no es compatible, o 3. Su plataforma no es compatible. Independientemente de la causa, empieza por confirmar la ficha de la aplicación y, si no está accesible, usa el método 2 o 4 para instalarla.
5. Una aplicación UWP Store informa "no detectada después de la instalación" (0x87D1041C)
Si recibes esta alerta, significa que se ha asignado una aplicación UWP con comportamiento de instalación System a un dispositivo que ya la tiene. En este caso, no te preocupes; la aplicación sigue instalada correctamente. Microsoft también recomienda no mezclar contextos de usuario y de sistema para la misma aplicación.
6. Descubre por qué falló una instalación de WinGet
Si una instalación de WinGet falló y no tienes claro por qué, puedes investigarlo para determinar y solucionar la causa. Si añades --verbose-logs al comando, obtendrás registros completos, y puedes ejecutar winget error <code> para traducir un código de salida en una descripción. Ten en cuenta que esto cubre los códigos de WinGet, MSIX y MSI, pero muchos instaladores EXE pueden usar códigos no estándar. Nuestra guía de instalación silenciosa de EXE explica cómo encontrarlos.
Cómo Splashtop Agentic Packr convierte las aplicaciones WinGet en paquetes de Intune probados
Implementar aplicaciones WinGet con Intune puede ser complicado, pero no tiene por qué serlo. Con la automatización adecuada, los equipos pueden empaquetar instaladores de forma rápida y eficiente sin consumir recursos de TI.
Eso nos lleva a Splashtop Agentic Packr, una herramienta de empaquetado e implementación de aplicaciones impulsada por IA para equipos de TI modernos. Agentic Packr puede empaquetar, validar e implementar aplicaciones a través de Microsoft Intune, SCCM y más, con mucho menos esfuerzo manual.
Splashtop Agentic Packr ofrece varias funciones y ventajas, entre ellas:
1. WinGet como fuente, sin cliente WinGet en los dispositivos
Splashtop Agentic Packr puede empaquetar aplicaciones desde un catálogo verificado de WinGet, mediante el ID de paquete de WinGet o Chocolatey, o desde tus propios instaladores. Crea una aplicación Win32 nativa de Intune, para que no tengas que preocuparte por los problemas de contexto de WinGet y SYSTEM con los que los usuarios suelen encontrarse.
2. Reglas de detección escritas y probadas antes de lanzar nada
Cuando el agente con IA lee el instalador, redacta reglas de detección y prueba la compilación en una máquina virtual limpia. Estas pruebas comprueban que la instalación, la detección y la desinstalación funcionen, ejecutan un análisis de malware y generan una hoja de puntuación de control de calidad y registros que los administradores de TI pueden revisar antes de que la aplicación llegue a Intune y se implemente en todos los dispositivos.
3. Publicación y nuevas versiones sin reconstrucciones manuales
Splashtop Agentic Packr elimina la necesidad de reconstruir manualmente los paquetes cada vez que sale una nueva actualización. Con su conexión Express de un clic al tenant de Intune y las actualizaciones automáticas de versiones, Agentic Packr detecta nuevas actualizaciones, las empaqueta, las prueba y despliega el paquete actualizado sin que los administradores tengan que gestionar cada actualización manualmente.
4. Control sobre lo que ven los usuarios
Splashtop Agentic Packr permite a TI controlar cómo aparecen a los usuarios las instalaciones y las actualizaciones. Los equipos pueden personalizar las notificaciones para el usuario final, los aplazamientos, los avisos de reinicio y los periodos de gracia, para que las instalaciones y actualizaciones obligatorias tengan menos probabilidades de interrumpir a los usuarios en mitad de una tarea.
Implementa aplicaciones WinGet en Intune sin mantener scripts
WinGet es una fuente sólida de información sobre aplicaciones, e Intune es excelente para implementar aplicaciones, pero Intune no puede implementarlas directamente desde el repositorio comunitario de WinGet. El método que escala consiste en convertir las entradas de WinGet en paquetes Win32 probados.
Con Splashtop Agentic Packr, puedes crear, probar y publicar paquetes de aplicaciones con mucho menos trabajo manual. Agentic Packr hace que el empaquetado sea más rápido y sencillo, usando una sola consola para empaquetar, implementar y actualizar aplicaciones mientras mantiene a los administradores con el control.
¿Quieres implementar aplicaciones de WinGet con Intune sin complicaciones? Descubre cómo Splashtop Agentic Packr puede ayudarte hoy.
