Cómo empaquetar una app PSADT v4 para Intune

El PowerShell App Deployment Toolkit e Intune forman una buena pareja: PSADT se encarga de las partes desagradables de instalar una aplicación de Windows, e Intune se encarga de llevarla a los dispositivos. La cadena entre ambos es donde los equipos pierden tiempo, porque los dos tienen opiniones distintas sobre la estructura de carpetas, los códigos de salida y qué cuenta como éxito.

Esto cubre v4 en concreto. Si está siguiendo una guía escrita para v3, la sintaxis de los comandos ha cambiado y obtendrá errores que parecen problemas de empaquetado pero no lo son.

La versión corta: mantenga intacta la estructura de carpetas del toolkit, nombre su punto de entrada como archivo de instalación cuando cree el .intunewin, refleje el comando de instalación en el de desinstalación, elija una regla de detección capaz de distinguir una versión de otra, y mapee los códigos de salida de reinicio y reintento.

Por qué molestarse, si existe MSIX

Porque muchas aplicaciones no son candidatas a MSIX. Todo lo que instala un controlador o un servicio del sistema, todo lo que necesita escrituras genuinas a nivel de máquina, todo lo que trae un instalador que insiste en ser un instalador. MSIX es el destino correcto cuando encaja, y PSADT es la respuesta correcta cuando no.

PSADT también le da cosas que MSIX no ofrece: avisos al usuario antes de un reinicio, cierre ordenado de las aplicaciones en ejecución, aplazamientos y registros que un service desk puede leer de verdad.

La decisión suele ser rápida:

• ¿Instala un controlador en modo kernel, o un servicio a nivel de máquina del que depende otro software? Use PSADT.
• ¿Alguna otra aplicación lee lo que escribe fuera de su propia carpeta? La redirección del contenedor oculta esa escritura, lo que parece un arreglo y no lo es.
• ¿Necesita cerrar un documento abierto u ofrecer un aplazamiento antes de un reinicio? Terreno propio de PSADT, sin equivalente en MSIX.
• ¿Nada de lo anterior, y el instalador se comporta bien? Pruebe primero MSIX. Convertir un EXE a MSIX recorre esa ruta.

Una carpeta de origen PSADT se convierte en un archivo intunewin, y cuatro ajustes de Intune deciden si funciona.

Paso 1: acertar con la estructura de carpetas

La herramienta de empaquetado de Intune toma una carpeta de origen y produce un único archivo .intunewin. Empaqueta todo lo que hay en esa carpeta, así que la disposición importa.

Mantenga intacta la estructura de PSADT. El toolkit espera sus propias carpetas en lugares conocidos y no encontrará sus recursos si las aplana o las reordena. Ponga el instalador de la aplicación dentro de la carpeta de archivos del toolkit, deje el resto tal cual y apunte la herramienta de empaquetado a la raíz de esa estructura.

En v4 la disposición que funciona tiene este aspecto, siendo su instalador lo único que usted añade:

ContosoApp\
  Invoke-AppDeployToolkit.ps1
  Invoke-AppDeployToolkit.exe
  PSAppDeployToolkit\
  Config\
  Strings\
  Files\
    ContosoAppSetup.exe
  SupportFiles\

Después construya el paquete con la Microsoft Win32 Content Prep Tool:

IntuneWinAppUtil.exe -c C:\Packaging\ContosoApp -s Invoke-AppDeployToolkit.exe -o C:\Packaging\Output

El archivo de instalación que designe debe ser el script de despliegue, no el instalador propio de la aplicación. Este es con diferencia el error más común. Designar el EXE del fabricante produce un paquete que ignora por completo su envoltorio PSADT, lo cual confunde porque aparenta funcionar.

Dos límites que conviene conocer. Una app Win32 de Intune está limitada a 8 GB, y la herramienta cifra la carpeta en un único archivo opaco, así que después no puede corregir una línea del script de despliegue. Mantenga la carpeta de origen en control de versiones y trate el .intunewin como un artefacto de compilación.

Paso 2: los comandos de instalación y desinstalación

En v4 cambió la invocación. El script de despliegue y su ejecutable envoltorio se renombraron, y los nombres de función del propio toolkit cambiaron con ellos, así que una línea de comandos de v3 nombra un archivo que ya no está ahí. Copiar una de esas en una app de Intune produce un fallo inmediato con un mensaje poco útil. Los comandos que quiere son estos:

Invoke-AppDeployToolkit.exe -DeploymentType Install -DeployMode Silent
Invoke-AppDeployToolkit.exe -DeploymentType Uninstall -DeployMode Silent

Dos cosas que hay que acertar:

Ejecute en modo silencioso. Los mensajes interactivos no tienen dónde aparecer cuando Intune ejecuta el paquete en contexto de sistema, y la instalación se quedará colgada en lugar de fallar limpiamente.

Haga que el comando de desinstalación coincida con el de instalación. Intune lo usará, y una desinstalación que no funciona convierte un simple cambio de asignación de app en una visita manual al dispositivo.

Prefiera el ejecutable suministrado antes que llamar usted mismo a powershell.exe: se ocupa de la arquitectura del host de PowerShell. La Intune Management Extension es un proceso de 32 bits, así que si invoca PowerShell directamente, %windir%\System32 se redirige a SysWOW64 y necesita %windir%\Sysnative\WindowsPowerShell\v1.0\powershell.exe para alcanzar el host de 64 bits.

Pruebe ambos comandos en contexto de sistema antes de empaquetar nada. Ejecutarlos con su propia cuenta de administrador demuestra menos de lo que cree, porque su perfil arrastra variables de entorno y confianza en certificados que SYSTEM no tiene:

PsExec.exe -s -i cmd.exe

Ejecute la instalación, luego la desinstalación, y lea los registros antes de acercarse a Intune. PSADT escribe en C:\Windows\Logs\Software de forma predeterminada; el lado de Intune está en C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\IntuneManagementExtension.log. Juntos le dicen si el problema era el paquete o la asignación.

Paso 3: reglas de detección, que es donde de verdad se tuerce

Intune decide si la aplicación está instalada usando la regla de detección, no preguntándole al paquete. Equivóquese aquí y ocurre una de dos cosas: Intune reinstala la aplicación en cada comprobación, o Intune cree que está instalada cuando no lo está.

Elija un método de detección que sea específico de la versión que está desplegando:

• Una comprobación de versión de archivo sobre el ejecutable principal de la aplicación suele ser la más fiable. Apunte a la ruta de instalación real, elija comparación de versión en lugar de existencia, y compare con mayor o igual que la versión que está entregando.
• Una comprobación de registry sobre la clave de desinstalación funciona bien cuando el fabricante escribe una DisplayVersion sensata. Para una aplicación de 32 bits sobre Windows de 64 bits esa clave vive bajo WOW6432Node, e Intune tiene un conmutador específico para ello. Olvidarlo es una causa muy común de una aplicación que se instala perfectamente y se reporta como no instalada.
• Un script de detección personalizado cuando el estado es realmente más complejo que un archivo o un valor. Intune considera la aplicación detectada solo cuando el script termina con 0 y escribe algo en la salida estándar. Un script que termina con 0 en silencio reporta no detectada.
• Una comprobación de existencia de archivo por sí sola es una trampa. No puede distinguir la versión 1 de la versión 2, así que las actualizaciones nunca ocurren en silencio.

La firma de error que hay que reconocer es 0x87D00324, la aplicación no se detecta después de que la instalación reportara éxito. Rara vez significa que la instalación falló. Significa que la regla de detección está mirando en el sitio equivocado, con la arquitectura equivocada o buscando lo que no es.

Elija lo que elija, verifíquelo contra una máquina donde la aplicación esté realmente ausente, y otra donde esté realmente presente. Ambos casos, siempre.

Paso 4: códigos de salida

PSADT devuelve códigos de salida con significado e Intune tiene sus propias opiniones sobre cuáles de ellos significan éxito.

Intune incluye un mapeo predeterminado que cubre casi todo lo que necesita: 0 y 1707 son éxito, 3010 es un reinicio suave, 1641 es un reinicio duro y 1618 es un reintento. El error es borrar esos valores predeterminados cuando añade un código propio. Añada a la lista, no la sustituya.

El que más importa es el código de reinicio suave. Si un despliegue necesita un reinicio e Intune no sabe que ese código significa éxito pendiente de reinicio, la app aparece como fallida e Intune la reintenta. Configure los códigos de retorno para que un resultado de reinicio pendiente se trate como éxito que requiere un reinicio.

El segundo es el código de salida 1618, otra instalación en curso. Trátelo como un reintento en lugar de como un fallo: es transitorio y habitual en dispositivos recién aprovisionados donde varias aplicaciones aterrizan a la vez.

Dos más para la lista. PSADT reserva un bloque de códigos en el rango 60000 para resultados a nivel de toolkit, como que un usuario aplace más allá de la ventana permitida: esos no son fallos de la aplicación, y mapearlos como fallo produce un panel en el que nadie confía. Y 1603 es el error grave genérico de Windows Installer, que por sí solo no le dice nada, así que lea el registro de PSADT en su lugar.

Paso 5: probar la cadena completa

En un dispositivo limpio, en el mismo contexto que usará Intune:

1. Instalar. Confirme que tiene éxito y que la regla de detección lo reporta presente.
2. Reiniciar, y confirmar que sobrevive.
3. Desinstalar a través de Intune, y confirmar que la regla de detección lo reporta ausente.
4. Instalar de nuevo, encima, para comprobar el comportamiento de actualización.

El paso cuatro es el que todo el mundo se salta y el que genera tickets de soporte seis meses después.

Dos añadidos. Al entregar una versión más nueva de algo ya desplegado, use supersedence en lugar de una segunda app: dos apps que reclaman el mismo ejecutable se pelean por la detección y el dispositivo pierde. Y si la aplicación se asigna como requerida durante la configuración del dispositivo, pruébela detrás de la Enrollment Status Page, donde cualquier cosa que espere educadamente está bloqueando el primer inicio de sesión de un usuario.

Hacer esto de forma repetida

Para una aplicación esto es una hora. Para un catálogo es una cadena de producción, y la pregunta interesante deja de ser cómo empaquetar una aplicación y pasa a ser qué ruta de empaquetado debería tomar cada aplicación. Algunas son candidatas a MSIX. Algunas son PSADT. Algunas deberían dejarse en paz.

Esa decisión de enrutado es la parte que no escala contratando. Tomada aplicación por aplicación por quien esté libre esa semana, produce un estate que nadie puede explicar. Tomada con criterios consistentes y puesta por escrito, se convierte en un inventario contra el que puede planificar, que es la base del trabajo de modernización y migración de aplicaciones.

Dónde encaja EtherApps Forge

EtherApps Forge toma esa decisión de enrutado de forma explícita y produce salidas MSIX, MSI, PSADT y listas para Intune desde la misma captura, de modo que la elección queda registrada en lugar de rediscutirse por aplicación. Es una aplicación de escritorio de Windows con una prueba de 7 días, así que las capturas y el empaquetado permanecen dentro de su propio entorno.

Las partes engorrosas más que difíciles de este artículo son las que merece la pena automatizar: la misma disposición de carpetas cada vez, comandos de instalación y desinstalación que coinciden, y un registro de por qué una aplicación acabó como PSADT en lugar de MSIX. Donde una se convierte limpiamente y luego se porta mal dentro del contenedor, qué ajuste de PSF necesito cubre el diagnóstico, y modernizar aplicaciones de Windows heredadas cubre la evaluación previa.

Si está empaquetando sus propias compilaciones en lugar de las de otros, la ruta para desarrolladores e ISVs es la relevante, y construir MSIX en CI sin el Windows SDK cubre el lado de la pipeline.

Explore la modernización y migración de aplicaciones

Empaquetar bien una aplicación es una habilidad; empaquetar cuatrocientas de forma consistente es un registro de decisiones, y esa es la parte que merece la pena construir.