Hoe u een PSADT v4-app verpakt voor Intune

De PowerShell App Deployment Toolkit en Intune vormen een goed duo: PSADT handelt de rommelige delen van het installeren van een Windows-applicatie af, en Intune zorgt dat hij op apparaten komt. De schakel ertussen is waar mensen tijd verliezen, want de twee hebben verschillende opvattingen over mappenstructuur, exitcodes en wat als succes telt.

Dit gaat specifiek over v4. Volgt u een gids die voor v3 is geschreven, dan is de commandosyntaxis gewijzigd en krijgt u fouten die op packagingproblemen lijken maar dat niet zijn.

De korte versie: houd de mappenstructuur van de toolkit intact, wijs zijn entry point aan als setupbestand wanneer u de .intunewin bouwt, spiegel het install-commando in het uninstall-commando, kies een detectieregel die de ene versie van de andere kan onderscheiden, en breng de exitcodes voor herstart en opnieuw proberen in kaart.

Waarom nog moeite doen, nu MSIX bestaat

Omdat heel wat applicaties geen MSIX-kandidaten zijn. Alles dat een driver of een systeemservice installeert, alles dat echte machinebrede schrijfacties nodig heeft, alles met een installer die per se een installer wil zijn. MSIX is het juiste doel wanneer het past, en PSADT is het juiste antwoord wanneer dat niet zo is.

PSADT geeft u ook dingen die MSIX niet geeft: meldingen aan gebruikers vóór een herstart, draaiende applicaties netjes sluiten, uitstelmogelijkheden, en logboeken die een servicedesk echt kan lezen.

De beslissing gaat meestal snel:

• Installeert hij een kernelmodus-driver, of een machinebrede service waarvan andere software afhangt? Gebruik PSADT.
• Leest een andere applicatie wat hij buiten zijn eigen map schrijft? Containeromleiding verbergt die schrijfactie, wat op een oplossing lijkt en dat niet is.
• Moet hij een geopend document sluiten of uitstel aanbieden vóór een herstart? Het thuisterrein van PSADT, zonder MSIX-equivalent.
• Niets van het bovenstaande, en de installer gedraagt zich netjes? Probeer eerst MSIX. Een EXE naar MSIX converteren loopt dat pad langs.

Een PSADT-bronmap wordt één intunewin-bestand, en vier Intune-instellingen bepalen of het werkt.

Stap 1: krijg de mappenstructuur goed

De packagingtool van Intune neemt een bronmap en produceert één .intunewin-bestand. Hij bundelt alles in die map, dus de indeling telt.

Houd de PSADT-structuur intact. De toolkit verwacht zijn eigen mappen op bekende plaatsen en vindt zijn bronnen niet als u ze plat maakt of herschikt. Zet de installer van de applicatie in de bestandenmap van de toolkit, laat de rest met rust, en richt de packagingtool op de top van die structuur.

In v4 ziet de werkende indeling er zo uit, met uw installer als het enige dat u toevoegt:

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

Bouw het package vervolgens met de Microsoft Win32 Content Prep Tool:

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

Het setupbestand dat u aanwijst hoort het deploymentscript te zijn, niet de eigen installer van de applicatie. Dit is veruit de meest voorkomende fout. De EXE van de leverancier aanwijzen levert een package op dat uw PSADT-wrapper volledig negeert, wat verwarrend is omdat het lijkt te werken.

Twee limieten zijn goed om te weten. Een Intune Win32-app is begrensd op 8 GB, en de tool versleutelt de map tot één ondoorzichtig bestand, dus u kunt achteraf geen regel van het deploymentscript aanpassen. Houd de bronmap in versiebeheer en behandel de .intunewin als een buildartefact.

Stap 2: de install- en uninstall-commando's

In v4 wijzigde de aanroep. Het deploymentscript en zijn wrapper-executable zijn hernoemd, en de eigen functienamen van de toolkit veranderden mee, dus een v3-commandoregel noemt een bestand dat er niet meer is. Er een kopiëren naar een Intune-app levert een directe fout op met een weinig behulpzame melding. De commando's die u wilt, zijn deze:

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

Twee dingen moeten kloppen:

Draai stil. Interactieve prompts hebben nergens om te verschijnen wanneer Intune het package in systeemcontext draait, en de installatie blijft hangen in plaats van netjes te falen.

Laat het uninstall-commando aansluiten op het install-commando. Intune gebruikt het, en een verwijdering die niet werkt verandert een simpele wijziging in de app-toewijzing in een handmatig bezoek aan het apparaat.

Geef de voorkeur aan de meegeleverde executable boven zelf powershell.exe aanroepen: hij regelt de architectuur van de PowerShell-host. De Intune Management Extension is een 32-bits proces, dus als u PowerShell wel rechtstreeks aanroept, wordt %windir%\System32 omgeleid naar SysWOW64 en hebt u %windir%\Sysnative\WindowsPowerShell\v1.0\powershell.exe nodig om de 64-bits host te bereiken.

Test beide commando's in systeemcontext voordat u iets verpakt. Draaien onder uw eigen beheerdersaccount bewijst minder dan u denkt, want uw profiel draagt omgevingsvariabelen en certificaatvertrouwen die SYSTEM niet heeft:

PsExec.exe -s -i cmd.exe

Draai install, dan uninstall, en lees de logboeken voordat u in de buurt van Intune komt. PSADT schrijft standaard naar C:\Windows\Logs\Software; de kant van Intune zit in C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\IntuneManagementExtension.log. Samen vertellen ze u of het probleem het package was of de toewijzing.

Stap 3: detectieregels, en daar gaat het echt mis

Intune bepaalt of de applicatie is geïnstalleerd met de detectieregel, niet door het package te vragen. Doe dit fout en er gebeurt een van twee dingen: Intune installeert de applicatie bij elke check-in opnieuw, of Intune gelooft dat hij is geïnstalleerd terwijl dat niet zo is.

Kies een detectiemethode die specifiek is voor de versie die u uitrolt:

• Een controle op bestandsversie op het hoofd-uitvoerbare bestand van de applicatie is meestal het betrouwbaarst. Wijs naar het echte installatiepad, kies versievergelijking in plaats van bestaan, en vergelijk groter dan of gelijk aan de versie die u levert.
• Een registercontrole op de uninstall-sleutel werkt goed wanneer de leverancier een zinnige DisplayVersion schrijft. Voor een 32-bits applicatie op 64-bits Windows staat die sleutel onder WOW6432Node, en Intune heeft daar een specifieke schakelaar voor. Dat vergeten is een zeer veelvoorkomende oorzaak van een applicatie die perfect installeert en zich meldt als niet geïnstalleerd.
• Een eigen detectiescript wanneer de status echt ingewikkelder is dan één bestand of één waarde. Intune beschouwt de applicatie pas als gedetecteerd wanneer het script afsluit met 0 en iets naar standaarduitvoer schrijft. Een script dat stil afsluit met 0 meldt zich als niet gedetecteerd.
• Alleen een controle op het bestaan van een bestand is een valkuil. Hij kan versie 1 niet van versie 2 onderscheiden, dus upgrades gebeuren stilletjes nooit.

De foutsignatuur om te herkennen is 0x87D00324, de applicatie die niet wordt gedetecteerd nadat de installatie succes meldde. Het betekent zelden dat de installatie faalde. Het betekent dat de detectieregel op de verkeerde plek kijkt, naar de verkeerde bitbreedte, of naar het verkeerde ding.

Wat u ook kiest, verifieer het tegen een machine waar de applicatie echt afwezig is, en een waar hij echt aanwezig is. Beide gevallen, elke keer.

Stap 4: exitcodes

PSADT retourneert betekenisvolle exitcodes en Intune heeft zijn eigen opvattingen over welke succes betekenen.

Intune levert een standaardtoewijzing die het meeste dekt wat u nodig hebt: 0 en 1707 zijn succes, 3010 is een zachte herstart, 1641 is een harde herstart, en 1618 is opnieuw proberen. De fout is die standaardwaarden wissen wanneer u een eigen code toevoegt. Voeg toe aan de lijst, vervang hem niet.

Degene die het meest telt is de code voor de zachte herstart. Als een uitrol een herstart nodig heeft en Intune niet weet dat die code succes in afwachting van een herstart betekent, toont de app zich als mislukt en probeert Intune het opnieuw. Configureer de retourcodes zo dat een resultaat met herstart in afwachting wordt behandeld als succes dat een herstart vereist.

De tweede is exitcode 1618, een andere installatie is bezig. Behandel hem als opnieuw proberen in plaats van als fout: hij is tijdelijk en komt vaak voor op net voorziene apparaten waar meerdere applicaties tegelijk landen.

Nog twee voor de lijst. PSADT reserveert een blok codes in het bereik 60000 voor uitkomsten op toolkitniveau, zoals een gebruiker die voorbij het toegestane venster uitstelt: dat zijn geen applicatiefouten, en ze toewijzen aan fout levert een dashboard op dat niemand vertrouwt. En 1603 is de generieke fatale fout van Windows Installer, die u op zichzelf niets vertelt, dus lees in plaats daarvan het PSADT-logboek.

Stap 5: test de hele keten

Op een schoon apparaat, in dezelfde context die Intune zal gebruiken:

1. Installeer. Bevestig dat het slaagt en dat de detectieregel hem als aanwezig meldt.
2. Herstart, en bevestig dat hij het overleeft.
3. Verwijder via Intune, en bevestig dat de detectieregel hem als afwezig meldt.
4. Installeer opnieuw, eroverheen, om het upgradegedrag te controleren.

Stap vier is degene die iedereen overslaat en degene die zes maanden later supporttickets oplevert.

Twee aanvullingen. Levert u een nieuwere versie van iets dat al is uitgerold, gebruik dan opvolging in plaats van een tweede app: twee apps die hetzelfde uitvoerbare bestand claimen vechten om de detectie en het apparaat verliest. En als de applicatie tijdens de apparaatinstelling als vereist wordt toegewezen, test hem dan ook achter de Enrollment Status Page, waar alles dat beleefd wacht de eerste aanmelding van een gebruiker blokkeert.

Dit herhaaldelijk doen

Voor één applicatie is dit een uur. Voor een catalogus is het een productielijn, en de interessante vraag is niet langer hoe u één applicatie verpakt maar welke packagingroute elke applicatie zou moeten nemen. Sommige zijn MSIX-kandidaten. Sommige zijn PSADT. Sommige moeten met rust worden gelaten.

Die routeringsbeslissing is het deel dat niet schaalt door mensen aan te nemen. Applicatie voor applicatie genomen door wie die week toevallig vrij is, levert het een omgeving op die niemand kan verklaren. Genomen tegen consistente criteria en vastgelegd, wordt het een inventaris waarop u kunt plannen, en dat is de basis van werk aan applicatiemodernisering en -migratie.

Waar EtherApps Forge past

EtherApps Forge neemt die routeringsbeslissing expliciet en produceert MSIX, MSI, PSADT en Intune-klare uitvoer uit dezelfde capture, zodat de keuze wordt vastgelegd in plaats van per applicatie opnieuw bediscussieerd. Het is een Windows-desktopapplicatie met een proefperiode van 7 dagen, dus captures en packaging blijven binnen uw eigen omgeving.

De pietluttige in plaats van moeilijke delen van dit artikel zijn de delen die het automatiseren waard zijn: elke keer dezelfde mappenindeling, bijpassende install- en uninstall-commando's, en een vastlegging van waarom een applicatie als PSADT eindigde in plaats van als MSIX. Waar er één netjes converteert en zich daarna misdraagt binnen de container, behandelt welke PSF-fix-up heb ik nodig de diagnose, en behandelt legacy Windows-applicaties moderniseren de beoordeling die eraan voorafgaat.

Verpakt u uw eigen builds in plaats van die van iemand anders, dan is de route voor ontwikkelaars en ISV's de relevante, en behandelt MSIX bouwen in CI zonder de Windows SDK de pipelinekant.

Ontdek applicatiemodernisering en -migratie

Eén applicatie goed verpakken is een vaardigheid; vierhonderd consistent verpakken is een beslissingsregister, en dat is het deel dat het bouwen waard is.