Att konvertera en EXE till MSIX är enkelt när installationsprogrammet uppför sig och verkligt svårt när det inte gör det. De flesta guider täcker det första fallet. Den här täcker hela vägen, inklusive de delar där det går fel, för det är dit tiden faktiskt går.
Sluttillståndet är ett signerat MSIX-paket som installeras rent, avinstalleras rent och rullas ut via Intune.
Innan du börjar: är MSIX rätt mål?
Värt trettio sekunder, för det sparar dagar.
MSIX passar vanliga skrivbordsapplikationer i användarläge. Det passar inte något som installerar en drivrutin, registrerar en systemtjänst, behöver skriva till maskinomfattande platser som andra applikationer läser, eller kopplar sig djupt in i operativsystemet. Gör din EXE något av det, paketera den som MSI eller genom PowerShell App Deployment Toolkit i stället och gå vidare. Att tvinga in den i MSIX ger ett paket som tekniskt finns och aldrig riktigt fungerar.
Tre frågor avgör de flesta fall innan du öppnar någon verktygslåda:
- Behöver installationsprogrammet administratörsrättigheter för något utöver att skriva till Program Files? Att skriva till Program Files är normalt. Att installera en tjänst, en drivrutin eller en systemomfattande hook är signalen att stanna.
- Läser något annat det som den här applikationen skriver? MSIX dirigerar om skrivningar till en container per användare, så om en andra applikation, en schemalagd uppgift eller en övervakningsagent läser en fil eller registernyckel som denna producerar gör omdirigeringen de data osynliga för dem. Det ser ut som ett fungerande paket och är det inte.
- Levererar leverantören redan en MSIX? Fråga innan du fångar in. Att ompaketera ett installationsprogram som har en MSIX med support är arbete du helt enkelt kan låta bli, och det håller dig oftast inom supporten.
Är du osäker, kör konverteringen ändå men sätt en tidsgräns. Felet blir uppenbart.
Sex steg, en slinga: en misslyckad diagnos skickar dig tillbaka till ögonblicksbilden, inte framåt med ett lappat paket.
Steg 1: en verkligt ren maskin
Detta är steget folk hoppar över och sedan betalar för.
Infångning fungerar genom att jämföra maskinen före och efter installationen. Allt som redan finns är osynligt för den jämförelsen, så en maskin där applikationens beroenden redan är installerade ger ett paket som fungerar på din maskin och ingen annanstans.
Använd en färsk virtuell maskin som matchar målets Windows-build, utan något på den utöver operativsystemet. Ta en ögonblicksbild innan du börjar så att du kan återgå till ett känt läge, för du kommer att göra detta mer än en gång.
Två detaljer avgör skillnaden mellan en ren infångning och en brusig:
- Lugna maskinen först. Windows Update, uppdateringar av säkerhetsdefinitioner och uppdateringar av butiksappar skriver alla till disk medan din infångning körs, och varje sådan skrivning blir en del av paketet. Låt maskinen slutföra sina första uppdateringar, pausa dem, och ta sedan ögonblicksbilden.
- Matcha builden, inte bara versionen. Att fånga in på en nyare Windows-build än den din flotta kör kan baka in omdistribuerbara paket och ramverksversioner som finns där och saknas på målet. Stöder du fler än en build, fånga in på den äldsta.
Ögonblicksbilden är det verkliga resultatet av det här steget. Ett infångningsförsök på en maskin som redan bär en misslyckad installation är värdelöst, så du återgår före varje nytt försök.
Steg 2: fånga in installationen
Ta baslinjen, kör installationsprogrammet precis som en användare skulle göra, och slutför sedan infångningen.
Två saker värda att göra under installationen:
Starta applikationen en gång innan du slutför infångningen. Många applikationer gör en förstagångsinställning: skapar konfiguration, skriver standardvärden till registret, packar upp resurser. Fångar du in innan det sker paketerar du en applikation som aldrig initierats, och den gör sin första körning inuti containern, där skrivningen kanske inte består.
Notera allt installationsprogrammet frågar dig. Licensnycklar, serveradresser, installationsplatser. De valen är nu inbakade i paketet, och om de var fel bygger du om.
Du sätter också paketidentiteten här, och den är besvärlig att ändra senare. Den bor i manifestet och ser ut så här:
<Identity Name="Contoso.LineOfBusinessApp"
Publisher="CN=Contoso Ltd, O=Contoso Ltd, C=GB"
Version="1.0.0.0" />
Strängen Publisher är den som betyder något. Den måste matcha ämnet i certifikatet du kommer att signera med, tecken för tecken, så bestäm den nu i stället för att upptäcka en avvikelse i steg fyra. Version är ett tal med fyra delar och utrullningen bryr sig om att det ökar: anta en konvention, till exempel att lämna det fjärde fältet på noll och räkna upp det tredje vid ompaketeringar, och skriv ner den.
Finns det inget installationsprogram alls att köra är infångning inte din väg. Ompaketering utan det ursprungliga installationsprogrammet täcker det fallet, och samma disciplin med en ren maskin gäller.
Steg 3: räkna med felbeteende, och ställ diagnos ordentligt
Paketet installeras. Sedan är något fel.
Börja inte tillämpa åtgärder spekulativt. Återskapa problemet som standardanvändare, ta reda på vad applikationen faktiskt ber om, och matcha symtomet mot en specifik orsak. Vi täckte den kopplingen i vilken PSF-fix behöver jag, och kortversionen är: kontrollera arbetskatalogen innan du griper efter något annat, för det är den enskilt vanligaste orsaken.
Två vanor håller detta kort. Återskapa som standardanvändare snarare än som administratör, för mycket rapporterad MSIX-trasighet är ett behörighetsantagande som alltid fanns i applikationen och som maskerades av att alla körde som lokal administratör. Titta sedan på var containern faktiskt lade skrivningen: data per användare för en paketerad applikation hamnar under %LOCALAPPDATA%\Packages\<PackageFamilyName>\LocalCache, och att hitta filen där bevisar att skrivningen lyckades och att applikationen helt enkelt letar på den gamla platsen.
Tillämpa en ändring i taget och testa om. Ett paket som bär fyra fixar där en behövdes är ett paket ingen kommer att underhålla.
Har den tredje fixen inte löst det, ompröva målet. Att konvertera en äldre applikation till MSIX täcker det bredare beslutet, och det är ingen skam att leverera en besvärlig applikation via en annan väg medan miljön flyttar.
Steg 4: signera det
En osignerad MSIX installeras inte på en hanterad enhet. Detta är inte valfritt och det är där många första försök stannar.
Du behöver ett kodsigneringscertifikat vars ämne exakt matchar utgivaren i paketmanifestet. Inte ungefär. Exakt. En avvikelse här ger ett installationsfel vars felmeddelande inte nämner certifikatet alls, vilket är varför det kostar folk en eftermiddag. Jämför de två direkt innan du signerar:
Get-ChildItem Cert:\CurrentUser\My -CodeSigningCert |
Select-Object Subject, Thumbprint, NotAfter
Vad som än kommer tillbaka under Subject hör hemma i manifestets Publisher, inklusive ordningen på de relativa särskiljande namnen och mellanrummen. Kopiera det i stället för att skriva av det.
Signera från certifikatarkivet med tumavtryck snarare än att hantera en PFX-fil, och använd en RFC 3161-tidsstämpelserver. Utan en tidsstämpel slutar paketet validera när certifikatet går ut, trots att det signerades korrekt medan certifikatet var giltigt.
signtool sign /sha1 <thumbprint> /fd SHA256 /tr <your RFC 3161 timestamp URL> /td SHA256 .\ContosoApp.msix
En sak till fångar interna certifikat: certifikatet måste vara betrott på enheten som installerar paketet. En publik utfärdare kedjar redan till en rot som Windows litar på; din egen interna utfärdare eller ett självsignerat testcertifikat gör det inte, så det måste nå enhetens förtroendearkiv först. Rulla ut det genom din normala certifikathantering snarare än för hand på en testmaskin, annars godkänns din validering på den enda enhet där den någonsin kunde ha godkänts.
Steg 5: validera innan du levererar det
Validera paketet och behandla en avslutskod som inte är noll som ett stopp. Det är mycket billigare att hitta ett felformat manifest nu än efter att det nått en testring.
Bekräfta att signaturen och tidsstämpeln landade, inte bara manifestet:
Get-AuthenticodeSignature .\ContosoApp.msix |
Format-List Status, SignerCertificate, TimeStamperCertificate
Status ska visa Valid och TimeStamperCertificate ska inte vara tomt. Ett tomt tidsstämpelfält nu är ett paket som slutar installeras vid något framtida datum utan synlig anledning.
Installera det sedan faktiskt på en ren maskin, som standardanvändare, och kontrollera:
- Den startar.
- Den behåller inställningar över en omstart.
- Den avinstalleras rent och lämnar inget kvar.
Add-AppxPackage .\ContosoApp.msix
Get-AppxPackage -Name Contoso.LineOfBusinessApp | Select-Object Name, Version, PackageFullName
Remove-AppxPackage -Package <PackageFullName>
Den sista är hela poängen med MSIX. Lämnar avinstallationen skräp skrivs något utanför containern och du är inte klar.
Lägg till en fjärde kontroll om folk håller applikationen öppen hela dagen: installera den, starta den, och installera sedan en uppräknad version ovanpå. Uppdateringar förbereds medan applikationen körs och tillämpas när den startar nästa gång, så en användare som aldrig stänger den får aldrig uppdateringen. Ingen bugg, men ett supportärende om ingen räknade med det.
Steg 6: rulla ut via Intune
Paketera MSIX för Intune och tilldela den. I administrationscentret för Intune är det Appar, Alla appar, Lägg till, och sedan apptypen verksamhetsapp, som tar emot .msix-filen direkt. Tilldela den som obligatorisk till en pilotgrupp först, och som tillgänglig till den bredare gruppen när piloten hållit i några dagar.
Värt att veta: MSIX som rullas ut på det här sättet uppdateras via version, så ditt versionsschema betyder något nu. Gör fel en gång och du får enheter som vägrar uppdateringen eftersom versionen inte ökade. Följ installationsstatus per enhet snarare än att lita på tilldelningen, och notera att en enhet som redan bär en manuellt installerad kopia signerad av en annan utgivare kommer att vägra den hanterade, eftersom de för Windows är olika applikationer.
Vart tiden faktiskt går
Inte konverteringen. Konverteringen tar minuter. Tiden går till disciplinen med den rena maskinen, diagnosen när applikationen missköter sig, och signeringskonfigurationen. Att göra en applikation lär dig mönstret. Att göra fyrahundra är ett annat problem, och skälet till att applikationspaketering förblir ett specialistjobb.
Skillnaden är inte arbetsinsats per applikation, det är konsekvens. Vid fyrahundra applikationer är frågorna som betyder något om varje paket fångades in på samma build, om samma signeringskonfiguration användes, om besluten om fixar dokumenterades någonstans, och om personen som fattade dem fortfarande arbetar här. Det är ett arbetsflödesproblem snarare än ett paketeringsproblem, och det är varför miljöer slutar med en mapp full av paket ingen vågar bygga om.
Var EtherApps Forge passar in
EtherApps Forge är byggt för fallet med fyrahundra: fånga in, dirigera, förbereda fixarna, signera och validera som ett flöde snarare än sex verktyg och en körplan. Besluten registreras med paketet i stället för att kommas ihåg, vilket är det som gör den andra rundan genom en miljö billigare än den första.
Det är en Windows-skrivbordsapplikation snarare än en värdbaserad tjänst, så infångning och signering stannar inuti din miljö, och det körs på en kostnadsfri provperiod på 7 dagar. Levererar du dina egna byggen snarare än fångar in någon annans installationsprogram är utvecklarvägen en annan och börjar från en byggmapp: MSIX-paketering för utvecklare och ISV:er täcker den, och att bygga och signera MSIX i CI/CD utan Windows SDK visar pipelineformen. För bilden över hela miljön är MSIX-paketering och utrullning rutten som täcker infångning till leverans.
Utforska MSIX-paketering och utrullning för att se hur infångning, åtgärder, signering och leverans körs som ett flöde i stället för sex.