Hoe u een EXE naar MSIX converteert, van begin tot eind

Een EXE naar MSIX converteren is eenvoudig wanneer de installer zich netjes gedraagt en echt lastig wanneer dat niet zo is. De meeste gidsen behandelen het eerste geval. Deze behandelt het hele pad, inclusief de stukken waar het misgaat, want daar gaat de tijd werkelijk heen.

De eindtoestand is een gesigneerd MSIX-package dat netjes installeert, netjes verwijdert en uitrolt via Intune.

Voordat u begint: is MSIX het juiste doel?

Dertig seconden waard, want het bespaart dagen.

MSIX past bij gewone desktopapplicaties in gebruikersmodus. Het past niet bij iets dat een driver installeert, een systeemservice registreert, naar machinebrede locaties moet schrijven die andere applicaties lezen, of diep in het besturingssysteem haakt. Doet uw EXE een van die dingen, verpak hem dan als MSI of via de PowerShell App Deployment Toolkit en ga verder. Hem in MSIX forceren levert een package op dat technisch bestaat en nooit helemaal werkt.

Drie vragen beslechten de meeste gevallen voordat u enige tooling opent:

• Heeft de installer beheerdersrechten nodig voor iets anders dan schrijven naar Program Files? Naar Program Files schrijven is normaal. Een service, een driver of een systeembrede hook installeren is het signaal om te stoppen.
• Leest iets anders wat deze applicatie schrijft? MSIX leidt schrijfacties om naar een container per gebruiker, dus als een tweede applicatie, een geplande taak of een monitoringagent een bestand of registersleutel leest die deze applicatie produceert, maakt de omleiding die gegevens voor hen onzichtbaar. Dat lijkt op een werkend package en is dat niet.
• Levert de leverancier al een MSIX? Vraag het voordat u captured. Een installer herverpakken waarvoor een ondersteunde MSIX bestaat, is werk dat u simpelweg niet hoeft te doen, en het houdt u meestal ondersteund.

Weet u het niet zeker, voer de conversie dan toch uit maar zet er een tijdslimiet op. De fout zal duidelijk zijn.

Zes stappen, één lus: een mislukte diagnose stuurt u terug naar de snapshot, niet vooruit met een opgelapt package.

Stap 1: een werkelijk schone machine

Dit is de stap die mensen overslaan en waarvoor ze daarna betalen.

Capture werkt door de machine voor en na de installatie te vergelijken. Alles wat er al is, is onzichtbaar voor die vergelijking, dus een machine waarop de dependencies van de applicatie al zijn geïnstalleerd levert een package op dat op uw machine werkt en nergens anders.

Gebruik een verse virtuele machine die overeenkomt met de doel-Windows-build, zonder iets erop behalve het besturingssysteem. Maak er een snapshot van voordat u begint, zodat u kunt terugkeren naar een bekende toestand, want u gaat dit meer dan één keer doen.

Twee details maken het verschil tussen een schone capture en een rommelige:

• Breng de machine eerst tot rust. Windows Update, updates van beveiligingsdefinities en updates van store-apps schrijven allemaal naar schijf terwijl uw capture draait, en elk van die schrijfacties wordt onderdeel van het package. Laat de machine zijn eerste updates afronden, pauzeer ze, en maak dan de snapshot.
• Match de build, niet alleen de versie. Capturen op een nieuwere Windows-build dan uw wagenpark draait, kan redistributables en frameworkversies inbakken die daar aanwezig zijn en op het doel ontbreken. Ondersteunt u meer dan één build, capture dan op de oudste.

De snapshot is het echte resultaat van deze stap. Een capturepoging op een machine die al één mislukte installatie draagt is waardeloos, dus u draait terug voor elke nieuwe poging.

Stap 2: leg de installatie vast

Neem de basislijn op, draai de installer precies zoals een gebruiker dat zou doen, en rond de capture dan af.

Twee dingen zijn de moeite waard tijdens de installatie:

Start de applicatie één keer voordat u de capture afrondt. Veel applicaties doen een eerste-start-instelling: configuratie aanmaken, standaardwaarden naar het register schrijven, bronnen uitpakken. Captured u voordat dat gebeurt, dan verpakt u een applicatie die nooit is geïnitialiseerd en doet hij zijn eerste start binnen de container, waar de schrijfactie mogelijk niet blijft bestaan.

Noteer alles wat de installer u vraagt. Licentiesleutels, serveradressen, installatielocaties. Die keuzes zitten nu ingebakken in het package, en als ze fout waren, bouwt u opnieuw.

U stelt hier ook de package-identiteit in, en die is later lastig te wijzigen. Ze staat in het manifest en ziet er zo uit:

<Identity Name="Contoso.LineOfBusinessApp"
          Publisher="CN=Contoso Ltd, O=Contoso Ltd, C=GB"
          Version="1.0.0.0" />

De Publisher-string is degene die telt. Hij moet teken voor teken overeenkomen met het onderwerp van het certificaat waarmee u gaat signen, dus beslis hem nu in plaats van bij stap vier een verschil te ontdekken. Version is een getal met vier delen en de uitrol geeft erom dat het toeneemt: hanteer een conventie, bijvoorbeeld het vierde veld op nul laten en het derde ophogen bij herverpakkingen, en leg dat vast.

Is er helemaal geen installer om te draaien, dan is capture niet uw pad. Herverpakken zonder de originele installer behandelt dat geval, en dezelfde discipline van een schone machine geldt.

Stap 3: verwacht wangedrag, en diagnosticeer goed

Het package installeert wel. Dan is er iets mis.

Begin niet speculatief met oplossingen toepassen. Reproduceer het probleem als standaardgebruiker, zoek uit waar de applicatie werkelijk om vraagt, en koppel het symptoom aan een specifieke oorzaak. We behandelden die koppeling in welke PSF-fix-up heb ik nodig, en de korte versie is: controleer de werkmap voordat u naar iets anders grijpt, want dat is veruit de meest voorkomende oorzaak.

Twee gewoontes houden dit kort. Reproduceer als standaardgebruiker in plaats van als beheerder, want veel gemelde MSIX-breuk is een rechtenaanname die altijd al in de applicatie zat en werd gemaskeerd doordat iedereen als lokale beheerder draaide. Kijk daarna waar de container de schrijfactie echt heeft neergezet: gegevens per gebruiker voor een verpakte applicatie landen onder %LOCALAPPDATA%\Packages\<PackageFamilyName>\LocalCache, en het bestand daar vinden bewijst dat de schrijfactie slaagde en dat de applicatie simpelweg op de oude plek kijkt.

Pas één wijziging tegelijk toe en test opnieuw. Een package met vier fix-ups waar er één nodig was, is een package dat niemand zal onderhouden.

Heeft de derde fix-up het niet opgelost, heroverweeg dan het doel. Een legacy applicatie naar MSIX converteren behandelt de bredere beslissing, en het is geen schande om een lastige applicatie via een andere route te leveren terwijl de omgeving verhuist.

Stap 4: sign het

Een niet-gesigneerde MSIX installeert niet op een beheerd apparaat. Dit is niet optioneel en het is waar veel eerste pogingen stoppen.

U hebt een code-signing-certificaat nodig waarvan het onderwerp exact overeenkomt met de publisher in het packagemanifest. Niet bij benadering. Exact. Een verschil hier levert een installatiefout op waarvan de foutmelding het certificaat helemaal niet noemt, en daarom kost het mensen een middag. Vergelijk de twee rechtstreeks voordat u signt:

Get-ChildItem Cert:\CurrentUser\My -CodeSigningCert |
  Select-Object Subject, Thumbprint, NotAfter

Wat er ook terugkomt onder Subject hoort in de Publisher van het manifest, inclusief de volgorde van de relatieve distinguished names en de spaties. Kopieer het in plaats van het over te typen.

Sign vanuit het certificaatarchief op vingerafdruk in plaats van een PFX-bestand te hanteren, en gebruik een RFC 3161-tijdstempelserver. Zonder tijdstempel stopt het package met valideren zodra het certificaat verloopt, ook al is het rechtmatig gesigneerd toen het certificaat nog geldig was.

signtool sign /sha1 <thumbprint> /fd SHA256 /tr <your RFC 3161 timestamp URL> /td SHA256 .\ContosoApp.msix

Nog één ding betrapt interne certificaten: het certificaat moet vertrouwd zijn op het apparaat dat het package installeert. Een openbare autoriteit ketent al naar een root die Windows vertrouwt; uw eigen interne autoriteit of een zelfondertekend testcertificaat niet, dus dat moet eerst het vertrouwensarchief van het apparaat bereiken. Rol het uit via uw normale certificaatbeheer in plaats van met de hand op één testmachine, anders slaagt uw validatie op het enige apparaat waar hij ooit had kunnen slagen.

Stap 5: valideer voordat u het levert

Valideer het package en behandel een exitcode die niet nul is als een stop. Het is veel goedkoper om nu een misvormd manifest te vinden dan nadat het een testring bereikt.

Bevestig dat de handtekening en het tijdstempel zijn geland, en niet alleen het manifest:

Get-AuthenticodeSignature .\ContosoApp.msix |
  Format-List Status, SignerCertificate, TimeStamperCertificate

Status hoort Valid te zijn en TimeStamperCertificate hoort niet leeg te zijn. Een leeg tijdstempelveld nu is een package dat op een toekomstige datum zonder zichtbare reden stopt met installeren.

Installeer het daarna daadwerkelijk op een schone machine, als standaardgebruiker, en controleer:

• Hij start.
• Hij behoudt instellingen na een herstart.
• Hij verwijdert netjes en laat niets achter.

Add-AppxPackage .\ContosoApp.msix
Get-AppxPackage -Name Contoso.LineOfBusinessApp | Select-Object Name, Version, PackageFullName
Remove-AppxPackage -Package <PackageFullName>

Die laatste is het punt van MSIX. Laat het verwijderen resten achter, dan wordt er iets buiten de container geschreven en bent u nog niet klaar.

Voeg een vierde controle toe als mensen de applicatie de hele dag open houden: installeer hem, start hem, en installeer er dan een opgehoogde versie overheen. Updates worden klaargezet terwijl de applicatie draait en toegepast bij de volgende start, dus een gebruiker die hem nooit sluit, krijgt de update nooit. Geen bug, maar wel een supportmelding als niemand het verwachtte.

Stap 6: uitrollen via Intune

Verpak de MSIX voor Intune en wijs hem toe. In het Intune-beheercentrum is dat Apps, Alle apps, Toevoegen, en daarna het type line-of-business-app, dat het .msix-bestand rechtstreeks accepteert. Wijs hem eerst als vereist toe aan een pilotgroep, en als beschikbaar aan de bredere groep zodra de pilot een paar dagen heeft standgehouden.

Goed om te weten: MSIX die zo wordt uitgerold, werkt bij op versie, dus uw versieschema telt nu. Doe het één keer fout en u hebt apparaten die de update weigeren omdat de versie niet toenam. Volg de installatiestatus per apparaat in plaats van de toewijzing te vertrouwen, en let erop dat een apparaat dat al een handmatig geïnstalleerde kopie draagt die door een andere publisher is gesigneerd, de beheerde versie zal weigeren, want voor Windows zijn het verschillende applicaties.

Waar de tijd echt heen gaat

Niet de conversie. De conversie duurt minuten. De tijd gaat naar de discipline van de schone machine, de diagnose wanneer de applicatie zich misdraagt, en de signingconfiguratie. Eén applicatie doen leert u het patroon. Vierhonderd doen is een ander probleem, en de reden dat applicatieverpakking specialistenwerk blijft.

Het verschil is niet inspanning per applicatie, het is consistentie. Bij vierhonderd applicaties zijn de vragen die tellen of elk package op dezelfde build is gecaptured, of dezelfde signingconfiguratie is gebruikt, of de fix-up-beslissingen ergens zijn vastgelegd, en of de persoon die ze nam hier nog werkt. Dat is een workflowprobleem en geen packagingprobleem, en het is waarom omgevingen eindigen met een map vol packages die niemand durft te herbouwen.

Waar EtherApps Forge past

EtherApps Forge is gebouwd voor het geval met vierhonderd: capturen, routeren, de fix-ups klaarzetten, signen en valideren als één stroom in plaats van zes tools en een draaiboek. De beslissingen worden bij het package vastgelegd in plaats van onthouden, en dat is wat de tweede ronde door een omgeving goedkoper maakt dan de eerste.

Het is een Windows-desktopapplicatie en geen gehoste dienst, dus capture en signing blijven binnen uw omgeving, en het draait op een gratis proefperiode van 7 dagen. Levert u uw eigen builds in plaats van de installer van iemand anders te capturen, dan is het ontwikkelaarspad anders en begint het bij een buildmap: MSIX-packaging voor ontwikkelaars en ISV's behandelt dat, en MSIX bouwen en signen in CI/CD zonder de Windows SDK toont de vorm van de pipeline. Voor het beeld over de hele omgeving is MSIX-packaging en uitrol de route die capture tot en met levering behandelt.

Ontdek MSIX-packaging en uitrol om te zien hoe capture, herstel, signing en levering als één stroom draaien in plaats van zes.