Så paketerar du en PSADT v4-app för Intune

PowerShell App Deployment Toolkit och Intune är ett bra par: PSADT sköter de stökiga delarna av att installera en Windows-applikation, och Intune sköter att få ut den till enheter. Länken mellan dem är där folk tappar tid, eftersom de två har olika åsikter om mappstruktur, avslutskoder och vad som räknas som framgång.

Detta gäller v4 specifikt. Följer du en guide skriven för v3 har kommandosyntaxen ändrats och du får fel som ser ut som paketeringsproblem men inte är det.

Kortversionen: håll verktygslådans mappstruktur intakt, utse dess startpunkt till installationsfil när du bygger .intunewin, spegla installationskommandot i avinstallationskommandot, välj en detekteringsregel som kan skilja en version från en annan, och mappa avslutskoderna för omstart och nytt försök.

Varför bry sig, när MSIX finns

Därför att gott om applikationer inte är MSIX-kandidater. Allt som installerar en drivrutin eller en systemtjänst, allt som behöver äkta maskinomfattande skrivningar, allt med ett installationsprogram som envisas med att vara ett installationsprogram. MSIX är rätt mål när det passar, och PSADT är rätt svar när det inte gör det.

PSADT ger dig också saker MSIX inte gör: meddelanden till användare före en omstart, att stänga körande applikationer varsamt, uppskov, och loggning som en servicedesk faktiskt kan läsa.

Beslutet går vanligen snabbt:

• Installerar den en drivrutin i kärnläge, eller en maskinomfattande tjänst annan programvara beror på? Använd PSADT.
• Läser en annan applikation det den skriver utanför sin egen mapp? Containeromdirigering döljer den skrivningen, vilket ser ut som en lösning och inte är det.
• Behöver den stänga ett öppet dokument eller erbjuda uppskov före en omstart? PSADT:s hemmaplan, utan MSIX-motsvarighet.
• Inget av ovanstående, och installationsprogrammet uppför sig? Prova MSIX först. Att konvertera en EXE till MSIX går igenom den vägen.

En PSADT-källmapp blir en intunewin-fil, och fyra Intune-inställningar avgör om det fungerar.

Steg 1: få mappstrukturen rätt

Intunes paketeringsverktyg tar en källmapp och producerar en enda .intunewin-fil. Det buntar ihop allt i den mappen, så layouten spelar roll.

Håll PSADT-strukturen intakt. Verktygslådan förväntar sig sina egna mappar på kända platser och hittar inte sina resurser om du plattar ut eller flyttar om dem. Lägg applikationens installationsprogram inuti verktygslådans filmapp, låt resten vara, och peka paketeringsverktyget på toppen av den strukturen.

I v4 ser den fungerande layouten ut så här, med ditt installationsprogram som det enda du lägger till:

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

Bygg sedan paketet med Microsoft Win32 Content Prep Tool:

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

Installationsfilen du utser ska vara distributionsskriptet, inte applikationens eget installationsprogram. Detta är det enskilt vanligaste misstaget. Att utse leverantörens EXE ger ett paket som helt ignorerar din PSADT-omslutning, vilket är förvirrande eftersom det ser ut att fungera.

Två gränser värda att känna till. En Intune Win32-app är begränsad till 8 GB, och verktyget krypterar mappen till en enda ogenomtränglig fil, så du kan inte laga en rad i distributionsskriptet efteråt. Håll källmappen i versionshantering och behandla .intunewin som en byggartefakt.

Steg 2: kommandona för installation och avinstallation

I v4 ändrades anropet. Distributionsskriptet och dess omslutande körbara program bytte namn, och verktygslådans egna funktionsnamn ändrades med dem, så en v3-kommandorad namnger en fil som inte längre finns. Att kopiera in en i en Intune-app ger ett omedelbart fel med ett föga hjälpsamt meddelande. Kommandona du vill ha är dessa:

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

Två saker att få rätt:

Kör tyst. Interaktiva dialoger har ingenstans att visa sig när Intune kör paketet i systemkontext, och installationen hänger sig i stället för att misslyckas rent.

Låt avinstallationskommandot matcha installationskommandot. Intune använder det, och en avinstallation som inte fungerar förvandlar en enkel ändring av apptilldelningen till ett manuellt enhetsbesök.

Föredra det medföljande körbara programmet framför att själv anropa powershell.exe: det hanterar PowerShell-värdens arkitektur. Intune Management Extension är en 32-bitarsprocess, så om du anropar PowerShell direkt omdirigeras %windir%\System32 till SysWOW64 och du behöver %windir%\Sysnative\WindowsPowerShell\v1.0\powershell.exe för att nå 64-bitarsvärden.

Testa båda kommandona i systemkontext innan du paketerar något. Att köra som ditt eget administratörskonto bevisar mindre än du tror, eftersom din profil bär miljövariabler och certifikatförtroende som SYSTEM inte har:

PsExec.exe -s -i cmd.exe

Kör installation, sedan avinstallation, och läs loggarna innan du går nära Intune. PSADT skriver som standard till C:\Windows\Logs\Software; Intunes sida finns i C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\IntuneManagementExtension.log. Tillsammans berättar de om problemet var paketet eller tilldelningen.

Steg 3: detekteringsregler, och det är där det verkligen går fel

Intune avgör om applikationen är installerad med detekteringsregeln, inte genom att fråga paketet. Gör detta fel och en av två saker händer: Intune installerar om applikationen vid varje incheckning, eller Intune tror att den är installerad när den inte är det.

Välj en detekteringsmetod som är specifik för den version du rullar ut:

• En kontroll av filversion på applikationens huvudsakliga körbara program är oftast tillförlitligast. Peka på den verkliga installationssökvägen, välj versionsjämförelse snarare än existens, och jämför större än eller lika med den version du levererar.
• En registerkontroll på avinstallationsnyckeln fungerar bra när leverantören skriver en vettig DisplayVersion. För en 32-bitarsapplikation på 64-bitars Windows bor den nyckeln under WOW6432Node, och Intune har en specifik växel för det. Att glömma det är en mycket vanlig orsak till en applikation som installeras perfekt och rapporteras som inte installerad.
• Ett eget detekteringsskript när tillståndet verkligen är mer komplext än en fil eller ett värde. Intune betraktar applikationen som detekterad bara när skriptet avslutas med 0 och skriver något till standardutdata. Ett skript som avslutas med 0 tyst rapporteras som inte detekterat.
• Enbart en kontroll av att en fil finns är en fälla. Den kan inte skilja version 1 från version 2, så uppgraderingar sker tyst aldrig.

Felsignaturen att känna igen är 0x87D00324, att applikationen inte detekteras efter att installationen rapporterat framgång. Det betyder sällan att installationen misslyckades. Det betyder att detekteringsregeln letar på fel plats, i fel bitbredd, eller efter fel sak.

Vad du än väljer, verifiera det mot en maskin där applikationen verkligen saknas, och en där den verkligen finns. Båda fallen, varje gång.

Steg 4: avslutskoder

PSADT returnerar meningsfulla avslutskoder och Intune har sina egna åsikter om vilka som betyder framgång.

Intune levererar en standardmappning som täcker det mesta du behöver: 0 och 1707 är framgång, 3010 är en mjuk omstart, 1641 är en hård omstart, och 1618 är ett nytt försök. Misstaget är att rensa de standardvärdena när du lägger till en egen kod. Lägg till i listan, ersätt den inte.

Den som betyder mest är koden för mjuk omstart. Om en utrullning behöver en omstart och Intune inte vet att den koden betyder framgång i väntan på omstart visas appen som misslyckad och Intune gör om den. Konfigurera returkoderna så att ett resultat med väntande omstart behandlas som framgång som kräver en omstart.

Den andra är avslutskod 1618, en annan installation pågår. Behandla den som ett nytt försök snarare än ett fel: den är övergående och vanlig på nyligen tillhandahållna enheter där flera applikationer landar samtidigt.

Två till för listan. PSADT reserverar ett block koder i 60000-serien för utfall på verktygslådenivå, som att en användare skjuter upp förbi det tillåtna fönstret: de är inte applikationsfel, och att mappa dem till fel ger en instrumentpanel ingen litar på. Och 1603 är Windows Installers generiska allvarliga fel, som inte berättar något på egen hand, så läs PSADT-loggen i stället.

Steg 5: testa hela kedjan

På en ren enhet, i samma kontext som Intune kommer att använda:

1. Installera. Bekräfta att det lyckas och att detekteringsregeln rapporterar den som närvarande.
2. Starta om, och bekräfta att den överlever.
3. Avinstallera genom Intune, och bekräfta att detekteringsregeln rapporterar den som frånvarande.
4. Installera igen, ovanpå, för att kontrollera uppgraderingsbeteendet.

Steg fyra är det alla hoppar över och det som genererar supportärenden sex månader senare.

Två tillägg. När du levererar en nyare version av något som redan är utrullat, använd ersättning snarare än en andra app: två appar som gör anspråk på samma körbara program slåss om detekteringen och enheten förlorar. Och om applikationen tilldelas som obligatorisk under enhetsinstallationen, testa den bakom Enrollment Status Page, där allt som väntar artigt blockerar en användares första inloggning.

Att göra detta upprepade gånger

För en applikation är detta en timme. För en katalog är det ett löpande band, och den intressanta frågan slutar vara hur man paketerar en applikation och blir vilken paketeringsväg varje applikation bör ta. Några är MSIX-kandidater. Några är PSADT. Några bör lämnas i fred.

Det dirigeringsbeslutet är den del som inte skalar genom att anställa. Fattat applikation för applikation av den som är ledig den veckan ger det en miljö ingen kan förklara. Fattat mot konsekventa kriterier och nedskrivet blir det en inventering du kan planera mot, vilket är grunden för arbete med applikationsmodernisering och migrering.

Var EtherApps Forge passar in

EtherApps Forge fattar det dirigeringsbeslutet uttryckligen och producerar MSIX, MSI, PSADT och Intune-färdig utdata från samma infångning, så att valet registreras snarare än omdiskuteras per applikation. Det är en Windows-skrivbordsapplikation med en provperiod på 7 dagar, så infångningar och paketering stannar inuti din egen miljö.

De pilliga snarare än svåra delarna av den här artikeln är de värda att automatisera: samma mapplayout varje gång, matchande installations- och avinstallationskommandon, och en notering om varför en applikation hamnade som PSADT snarare än MSIX. Där en konverterar rent och sedan missköter sig inuti containern täcker vilken PSF-fix behöver jag diagnosen, och att modernisera äldre Windows-applikationer täcker bedömningen som ligger framför den.

Paketerar du dina egna byggen snarare än någon annans är rutten för utvecklare och ISV:er den relevanta, och att bygga MSIX i CI utan Windows SDK täcker pipelinesidan.

Utforska applikationsmodernisering och migrering

Att paketera en applikation väl är en färdighet; att paketera fyrahundra konsekvent är ett beslutsregister, och det är den del som är värd att bygga.