Come confezionare un'app PSADT v4 per Intune

Il PowerShell App Deployment Toolkit e Intune sono una buona coppia: PSADT gestisce le parti scomode dell'installazione di un'applicazione Windows, e Intune si occupa di recapitarla ai dispositivi. La catena fra i due è dove si perde tempo, perché i due hanno opinioni diverse sulla struttura delle cartelle, sui codici di uscita e su che cosa conti come esito positivo.

Questo articolo riguarda nello specifico la v4. Se state seguendo una guida scritta per la v3, la sintassi dei comandi è cambiata e otterrete errori che sembrano problemi di packaging ma non lo sono.

In breve: mantenete intatta la struttura delle cartelle del toolkit, indicate il suo punto di ingresso come file di setup quando costruite il .intunewin, rispecchiate il comando di installazione in quello di disinstallazione, scegliete una regola di rilevamento capace di distinguere una versione dall'altra e mappate i codici di uscita per riavvio e nuovo tentativo.

Perché farlo, visto che esiste MSIX

Perché moltissime applicazioni non sono candidate a MSIX. Tutto ciò che installa un driver o un servizio di sistema, tutto ciò che richiede vere scritture a livello di macchina, tutto ciò che ha un installer che pretende di restare un installer. MSIX è la destinazione giusta quando è adatta, e PSADT è la risposta giusta quando non lo è.

PSADT vi dà anche cose che MSIX non ha: richieste all'utente prima di un riavvio, chiusura ordinata delle applicazioni in esecuzione, rinvii e log che un service desk riesce davvero a leggere.

La decisione di solito è rapida se verificate in quest'ordine:

• Installa un driver in modalità kernel, o un servizio a livello di macchina da cui dipende altro software? Usate PSADT.
• Un'altra applicazione legge ciò che scrive fuori dalla propria cartella? Il reindirizzamento del contenitore nasconde quella scrittura, il che sembra una soluzione e non lo è.
• Deve chiudere un documento aperto o offrire un rinvio prima di un riavvio? Terreno di casa di PSADT, senza equivalente MSIX.
• Niente di tutto questo, e l'installer si comporta bene? Provate prima MSIX. Convertire un EXE in MSIX percorre quella strada.

Una cartella sorgente PSADT diventa un unico file intunewin, e quattro impostazioni di Intune decidono se funziona.

Passo 1: sistemare la struttura delle cartelle

Lo strumento di packaging di Intune prende una cartella sorgente e produce un unico file .intunewin. Impacchetta tutto ciò che si trova in quella cartella, quindi la disposizione conta.

Mantenete intatta la struttura PSADT. Il toolkit si aspetta le proprie cartelle in posizioni note e non troverà le sue risorse se le appiattite o le riorganizzate. Mettete l'installer dell'applicazione dentro la cartella files del toolkit, lasciate stare il resto e puntate lo strumento di packaging alla radice di quella struttura.

Nella v4 la disposizione di lavoro è questa, con il vostro installer come unica aggiunta:

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

Poi costruite il pacchetto con il Microsoft Win32 Content Prep Tool:

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

Il file di setup che indicate deve essere lo script di distribuzione, non l'installer dell'applicazione. Questo è l'errore singolo più comune. Indicare l'EXE del fornitore produce un pacchetto che ignora del tutto il vostro wrapper PSADT, il che confonde perché sembra funzionare.

Due limiti che vale la pena conoscere. Un'app Win32 di Intune ha un tetto di 8 GB, e lo strumento cifra la cartella in un unico file opaco, quindi non potete correggerne dopo una riga dello script di distribuzione. Tenete la cartella sorgente sotto controllo di versione e trattate il .intunewin come un artefatto di build.

Passo 2: i comandi di installazione e disinstallazione

Nella v4 l'invocazione è cambiata. Lo script di distribuzione e il suo eseguibile wrapper sono stati rinominati, e con loro sono cambiati i nomi delle funzioni del toolkit, quindi una riga di comando v3 nomina un file che non esiste più. Copiarne una dentro un'app Intune produce un fallimento immediato con un messaggio poco utile. I comandi che vi servono sono questi:

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

Due cose da fare bene:

Eseguite in modalità silenziosa. Le richieste interattive non hanno dove comparire quando Intune esegue il pacchetto nel contesto di sistema, e l'installazione resterà bloccata anziché fallire in modo pulito.

Fate corrispondere il comando di disinstallazione a quello di installazione. Intune lo userà, e una disinstallazione che non funziona trasforma una semplice modifica di assegnazione in una visita manuale al dispositivo.

Preferite l'eseguibile fornito al richiamo diretto di powershell.exe, perché gestisce per voi l'architettura dell'host PowerShell. Se richiamate PowerShell direttamente, ricordate che l'Intune Management Extension è un processo a 32 bit, quindi %windir%\System32 viene reindirizzato a SysWOW64 sotto di voi e vi serve %windir%\Sysnative\WindowsPowerShell\v1.0\powershell.exe per raggiungere l'host a 64 bit.

Testate entrambi i comandi nel contesto di sistema prima di confezionare qualsiasi cosa. Eseguirli con il vostro account amministrativo dimostra meno di quanto pensiate, perché il vostro profilo porta con sé variabili d'ambiente e attendibilità dei certificati che SYSTEM non ha:

PsExec.exe -s -i cmd.exe

Eseguite il comando di installazione da quella shell, poi quello di disinstallazione, e leggete i log prima di avvicinarvi a Intune. PSADT scrive in C:\Windows\Logs\Software per impostazione predefinita, e il lato Intune si trova in C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\IntuneManagementExtension.log. Insieme, quei due file di solito vi dicono nel giro di un minuto se il problema era il pacchetto o l'assegnazione.

Passo 3: le regole di rilevamento, dove le cose vanno davvero storte

Intune decide se l'applicazione è installata usando la regola di rilevamento, non chiedendolo al pacchetto. Sbagliatela e succede una di due cose: Intune reinstalla l'applicazione a ogni check-in, oppure Intune crede che sia installata quando non lo è.

Scegliete un metodo di rilevamento specifico per la versione che state distribuendo:

• Un controllo sulla versione del file dell'eseguibile principale dell'applicazione è di solito il più affidabile. Puntate al percorso di installazione reale, scegliete il confronto di versione anziché l'esistenza, e confrontate con maggiore o uguale alla versione che state rilasciando.
• Un controllo nel registro sulla chiave di disinstallazione funziona bene quando il fornitore scrive un DisplayVersion sensato. Per un'applicazione a 32 bit su Windows a 64 bit quella chiave si trova sotto WOW6432Node, e Intune ha un interruttore apposito. Dimenticarlo è una causa molto comune di un'applicazione che si installa perfettamente e risulta non installata.
• Uno script di rilevamento personalizzato quando lo stato è davvero più complesso di un file o di un valore. Intune considera l'applicazione rilevata solo quando lo script esce con 0 e scrive qualcosa sullo standard output. Uno script che esce con 0 in silenzio risulta non rilevato.
• Il solo controllo di esistenza di un file è una trappola. Non sa distinguere la versione 1 dalla versione 2, quindi gli aggiornamenti in silenzio non avvengono mai.

La firma d'errore da riconoscere è 0x87D00324, l'applicazione non rilevata dopo che l'installazione ha riportato esito positivo. Raramente significa che l'installazione è fallita. Significa che la regola di rilevamento sta guardando nel posto sbagliato, con il bitness sbagliato, o cerca la cosa sbagliata.

Qualunque cosa scegliate, verificatela su una macchina dove l'applicazione è davvero assente e su una dove è davvero presente. Entrambi i casi, ogni volta.

Passo 4: i codici di uscita

PSADT restituisce codici di uscita significativi e Intune ha le sue opinioni su quali indichino esito positivo.

Intune fornisce una mappatura predefinita che copre già quasi tutto ciò che vi serve: 0 e 1707 sono esito positivo, 3010 è un riavvio soft, 1641 è un riavvio hard e 1618 è un nuovo tentativo. L'errore non sta nei valori predefiniti, sta nel cancellarli quando aggiungete un codice vostro. Aggiungete all'elenco, non sostituitelo.

Quello che conta di più è il codice del riavvio soft. Se una distribuzione richiede un riavvio e Intune non sa che quel codice significa esito positivo in attesa di riavvio, l'app risulta fallita e Intune la riprova. Configurate i codici di ritorno in modo che un esito in attesa di riavvio venga trattato come positivo con riavvio necessario.

Il secondo è il codice di uscita 1618, un'altra installazione in corso. Trattatelo come un nuovo tentativo anziché come un fallimento: è transitorio e comune sui dispositivi appena predisposti, dove diverse applicazioni arrivano tutte insieme.

Altri due per l'elenco. PSADT riserva un blocco di codici nell'intervallo 60000 per esiti a livello di toolkit, come un utente che rinvia oltre la finestra consentita: quelli non sono fallimenti dell'applicazione, e mapparli come tali produce una dashboard di cui nessuno si fida. E 1603 è l'errore fatale generico di Windows Installer, che da solo non vi dice nulla, quindi leggete il log PSADT anziché il report di Intune.

Passo 5: testare l'intera catena

Su un dispositivo pulito, nello stesso contesto che userà Intune:

1. Installate. Confermate che riesca e che la regola di rilevamento la riporti presente.
2. Riavviate, e confermate che sopravviva.
3. Disinstallate tramite Intune, e confermate che la regola di rilevamento la riporti assente.
4. Installate di nuovo, sopra, per verificare il comportamento in aggiornamento.

Il passo quattro è quello che tutti saltano e quello che genera ticket di supporto sei mesi dopo.

Due aggiunte. Quando rilasciate una versione più recente di qualcosa già distribuito, usate la sostituzione anziché una seconda app: due app che rivendicano lo stesso eseguibile si contendono il rilevamento e il dispositivo ci rimette. E se l'applicazione è assegnata come obbligatoria durante la configurazione del dispositivo, testatela dietro l'Enrollment Status Page, dove qualsiasi cosa attenda educatamente sta bloccando il primo accesso di un utente.

Farlo ripetutamente

Per una sola applicazione è un'ora di lavoro. Per un catalogo è una linea di produzione, e la domanda interessante smette di essere come confezionare un'applicazione e diventa quale strada di packaging debba prendere ciascuna. Alcune sono candidate a MSIX. Alcune sono da PSADT. Alcune andrebbero lasciate stare.

Quella decisione di instradamento è la parte che non scala assumendo persone. Presa applicazione per applicazione da chi è libero quella settimana, produce un parco che nessuno sa spiegare. Presa secondo criteri coerenti e messa per iscritto, diventa un inventario su cui pianificare, che è la base del lavoro di modernizzazione e migrazione delle applicazioni.

Dove si inserisce EtherApps Forge

EtherApps Forge rende esplicita quella decisione di instradamento e produce output MSIX, MSI, PSADT e pronti per Intune dalla stessa cattura, così la scelta viene registrata anziché ridiscussa per ogni applicazione. È un'applicazione desktop per Windows con una prova di 7 giorni, non un servizio ospitato, quindi le catture e il packaging restano dentro il vostro ambiente.

Le parti di questo articolo che sono noiose più che difficili sono quelle che vale la pena automatizzare: la stessa disposizione di cartelle ogni volta, comandi di installazione e disinstallazione che corrispondono, e una traccia del perché un'applicazione sia finita come PSADT anziché come MSIX. Dove una si converte in modo pulito e poi si comporta male dentro il contenitore, quale correzione PSF mi serve copre la diagnosi, e modernizzare le applicazioni Windows legacy copre la valutazione che la precede.

Se confezionate le vostre build anziché quelle di qualcun altro, il percorso per sviluppatori e ISV è quello pertinente, e costruire MSIX in CI senza il Windows SDK copre il lato pipeline.

Esplora la modernizzazione e migrazione delle applicazioni

Confezionare bene una sola applicazione è un'abilità; confezionarne quattrocento in modo coerente è una traccia di decisioni, ed è quella la parte che vale la pena costruire.