App-V naar MSIX: de vier dingen die elke keer breken

App-V-packages naar MSIX converteren is grotendeels mechanisch tot het dat niet meer is. Vier dingen zijn verantwoordelijk voor de overweldigende meerderheid van de meldingen "het converteerde prima en nu doet het raar", en het zijn elke keer dezelfde vier.

Ze zijn het waard om te kennen voordat u begint, want elk ervan is goedkoop om bewust af te handelen en duur om in een testring te ontdekken.

De onderliggende reden is in alle vier de gevallen dezelfde: App-V virtualiseerde dingen die App-V beheerde, en MSIX containert ze anders. Alles waarvoor de applicatie op App-V leunde, heeft een nieuw antwoord nodig. Niets hiervan is een gebrek in MSIX. De twee formaten trekken simpelweg de grens tussen package en omgeving op verschillende plekken.

Open het package voordat u het converteert

Een App-V 5-package is niet ondoorzichtig. Het .appv-bestand is een OPC-container, in de praktijk een zip met een manifest erin, dus alles wat u nodig hebt is leesbaar voordat een conversietool het aanraakt.

Drie bestanden dragen het gedrag:

• AppxManifest.xml, binnen de .appv, bevat de standaardwaarden die zijn geproduceerd toen de applicatie werd gesequencet.
• <PackageName>_DeploymentConfig.xml draagt machinebrede instellingen en scripts in machinecontext.
• <PackageName>_UserConfig.xml draagt instellingen per gebruiker en scripts in gebruikerscontext.

De voorrang loopt van UserConfig boven DeploymentConfig boven het manifest, dus een instelling kan in alle drie met verschillende waarden voorkomen en slechts één is actief. Leest u alleen het manifest, dan mist u de aanpassingen die later zijn toegevoegd om de applicatie werkend te krijgen, en dat zijn juist de dragende.

Ze uitpakken duurt seconden:

Copy-Item .\LineOfBusinessApp.appv .\LineOfBusinessApp.zip
Expand-Archive .\LineOfBusinessApp.zip -DestinationPath .\LineOfBusinessApp
Select-Xml -Path .\LineOfBusinessApp\AppxManifest.xml -XPath '//*[local-name()="EnvironmentVariables" or local-name()="Shortcut" or local-name()="FileTypeAssociation"]' | ForEach-Object { $_.Node.OuterXml }

Lees eerst alle drie de configuratiebronnen, en leid daarna elke bevinding naar waar ze nu thuishoort.

1. Omgevingsvariabelen

Met App-V kon u omgevingsvariabelen in het package definiëren, en de applicatie zag ze binnen haar virtuele omgeving. Ze zitten in een <EnvironmentVariables>-subsysteem, en elk van beide configuratiebestanden kan ze toevoegen of verwijderen:

<EnvironmentVariables Enabled="true">
  <Include>
    <Variable Name="LOBAPP_DATA" Value="%UserProfile%\LineOfBusinessApp" />
  </Include>
</EnvironmentVariables>

MSIX gaat hier anders mee om, en de variabelen die u in App-V declareerde komen niet mee. Een applicatie die een variabele leest om een datapad, een servernaam of een licentielocatie te vinden, start op en gedraagt zich alsof ze nooit is geconfigureerd. Ze werkt, ze weet alleen niets.

Wat u moet doen: som de variabelen op die het package declareerde voordat u converteert. Mensen slaan dit over, omdat de variabelen niet zichtbaar zijn in de eigen configuratie van de applicatie. Beslis daarna per variabele: een variabele op machine- of gebruikersniveau die uw deploymenttooling zet, een waarde in een configuratiebestand dat de applicatie leest, of iets dat een startscript eerst zet.

De foutsignatuur is een applicatie die netjes start en daarna klaagt over een ontbrekende server of een ontbrekend pad. Let op de stillere variant, waarin ze terugvalt op een ingebouwde standaardwaarde in plaats van te falen en pas weken later opduikt.

2. Snelkoppelingen

App-V-packages droegen hun snelkoppelingsdefinities volledig mee. Het <Shortcut>-element benoemt de aan te maken .lnk, zijn <Target>, <Icon>, <Arguments>, <WorkingDirectory> en <Description>, zodat een gesequencet package reproduceerde wat de installer ook op het startmenu zette.

MSIX genereert zijn item in plaats daarvan uit het packagemanifest, en het resultaat is niet altijd wat App-V produceerde. De snelkoppeling landt ergens anders, het pictogram is fout of ontbreekt, of de commandoregelargumenten zijn weg.

Die laatste is de gevaarlijke. Gaf de App-V-snelkoppeling een argument mee dat de applicatie in een bepaalde modus zette en doet het MSIX-item dat niet, dan krijgen gebruikers een applicatie die in de verkeerde toestand opent in plaats van een die zichtbaar faalt. Dezelfde applicatie tweemaal publiceren, als "Finance" en als "Alleen lezen", met het verschil volledig gedragen door een schakelaar, komt vaker voor dan u zou willen.

Wat u moet doen: leg de volledige snelkoppelingsdefinitie vast, inclusief argumenten en werkmap, en reproduceer haar bewust. Waar een argument echt twee manieren van draaien onderscheidt, worden dat meestal twee applicatie-items in het manifest.

Controleer specifiek de werkmap. Zet niets hem, dan gebruikt Windows de map System32 voor een verpakte applicatie, en daarom is "hij kan zijn eigen bestanden niet vinden" zo'n veelvoorkomend eerste symptoom. Het Package Support Framework zet hem expliciet met een workingDirectory-waarde in config.json, de meest toegepaste fix-up na welke conversie dan ook. Welke PSF-fix-up heb ik nodig brengt de rest in kaart.

3. Scripts

Dit is het grootste enkele verschil en degene die migraties doet ontsporen.

App-V ondersteunde scripts op acht punten in de levenscyclus, wat verklaart hoeveel logica omgevingen ongevolgd verzamelen:

App-V-omgevingen die lang draaien hebben vaak echte logica in die scripts: een schijf koppelen, configuratie ophalen, een tijdelijke locatie opruimen, iets registreren. Meerdere scripts kunnen aan één trigger hangen via ScriptRunner.exe, dus één AddPackage-item kan vier dingen na elkaar draaien.

MSIX biedt niet dezelfde hooks voor levenscyclusscripts. Het dichtstbijzijnde equivalent is het Package Support Framework, dat één PowerShell-script draait vóór een verpakt uitvoerbaar bestand en één nadat het afsluit, per uitvoerbaar bestand ingesteld als startScript en endScript in config.json.

Dat dekt StartProcess en ExitProcess. Het dekt de andere zes niet. Alles dat draaide bij toevoegen, publiceren, depubliceren of verwijderen verhuist naar uw deploymenttooling, het enige dat nu weet wanneer een package aankomt of vertrekt.

Wat u moet doen: vind de scripts voordat u converteert, en lees ze. Sommige worden install- of uninstall-gedrag in Intune of Configuration Manager. Sommige worden een startscript in het package. Sommige worden applicatieconfiguratie. Sommige doen dubbel werk met wat het platform nu zelf doet, en kunnen met opluchting worden verwijderd.

Twee praktische opmerkingen. Voor het uitvoeren van scripts moet het PowerShell-uitvoeringsbeleid op RemoteSigned staan voor zowel de 64-bits als de 32-bits host. En StartingScriptWrapper.ps1 moet in het package naast het uitvoerbare bestand staan, anders draait er niets en legt niets uit waarom.

De foutsignatuur is hier de ergste van de vier, want de applicatie werkt perfect voor degene die haar test, wiens schijf al gekoppeld was.

4. Bestandstypekoppelingen

App-V registreerde koppelingen binnen zijn virtuele omgeving tot in detail: de extensie, de ProgId ervan, de weergavenamen, en shell-commando's met hun eigen commandoregels, zodat een rechtsklik-werkwoord "Bewerken" het uitvoerbare bestand met een andere schakelaar kon starten dan "Openen".

MSIX declareert ze in het manifest als een extensie, en de declaratie moet kloppen:

<uap:Extension Category="windows.fileTypeAssociation">
  <uap:FileTypeAssociation Name="lobdoc">
    <uap:SupportedFileTypes>
      <uap:FileType>.lob</uap:FileType>
    </uap:SupportedFileTypes>
  </uap:FileTypeAssociation>
</uap:Extension>

Vier dingen gaan mis, ruwweg in die volgorde van frequentie.

De koppeling is helemaal niet gedeclareerd, dus dubbelklikken op een bestand doet niets nuttigs.

Ze is gedeclareerd maar Windows honoreert haar niet, omdat een andere applicatie die extensie al bezit en de keuze van de gebruiker wint. Het resultaat werkt op de packagingmachine en niet op het apparaat van een echte gebruiker.

De Name klopt niet. Hij moet in kleine letters staan, en hij hoort stabiel te blijven over updates heen, want het is de identificator waaronder Windows de bestandstypen groepeert.

De extensie is gereserveerd. Windows houdt extensies en URI-schema's apart voor ingebouwde applicaties, en een registratie voor zo'n extensie wordt genegeerd in plaats van geweigerd, waardoor het lijkt alsof de declaratie niet is aangeslagen.

De aangepaste werkwoorden zijn het deel dat mensen vergeten. Shell-commando's die verder gaan dan een gewoon openen overleven de reis niet.

Wat u moet doen: som de extensies op die het package registreerde, met hun ProgId-waarden en eventuele shell-commando's, declareer ze in het manifest, en test op een apparaat dat de applicaties heeft die een echte gebruiker heeft, niet op een schone virtuele machine zonder concurrerende aanspraken.

Noteer terwijl u er toch bent de URL-protocollen, AppPaths, softwareclients en COM-instellingen die dezelfde bestanden dragen. Een lobapp://-handler die stilletjes ophield te bestaan is een verwarrend ticket.

De volgorde die tijd bespaart

Doe alle inventarisatie voordat u iets converteert:

1. Haal de omgevingsvariabelen op die het package declareert, uit alle drie de bronnen.
2. Haal de snelkoppelingsdefinities op, inclusief argumenten en werkmap.
3. Haal de scripts op en lees ze, met een notitie aan welke trigger elk hangt.
4. Som de bestandstypekoppelingen op, hun ProgId-waarden en hun shell-commando's.
5. Noteer de resterende subsystemen: URL-protocollen, AppPaths, softwareclients, COM.

Leg de beslissing naast elke bevinding vast, niet alleen de bevinding. "Zet LOBAPP_DATA" is een notitie. "Zet LOBAPP_DATA, wordt een gebruikersvariabele in de Intune-uitrol" is een plan.

Dat is hooguit een uur per applicatie, en het verandert conversie van inventarisatie in uitvoering. Slaat u het over, dan vindt u elk hiervan in een testring, met een gebruiker die het symptoom meldt in plaats van de oorzaak.

Een voorbeeld. Een financiële applicatie converteert netjes, en dan komen er in de pilot twee dingen boven: ze kan haar sjablonen niet vinden, omdat het package een variabele zette die naar een share wees, en de helft van de groep opent haar in de verkeerde modus, omdat de App-V-snelkoppeling een schakelaar voor alleen lezen meegaf. Beide zaten in _DeploymentConfig.xml voordat iemand ook maar iets converteerde.

Converteer daarna, en test als standaardgebruiker op een apparaat dat op een echt apparaat lijkt.

Waar dit past

Het bredere migratiepad, inclusief welke packages überhaupt MSIX zouden moeten worden, staat in migratie van App-V naar MSIX. Het waard om ernaast te lezen: App-V Server stopt, App-V niet, want de tijdlijn is minder dringend dan de meeste berichtgeving suggereerde en deze conversies doordrukken is hoe de vier problemen hierboven de productie bereiken.

Legacy-naar-MSIX-conversie behandelt hetzelfde containergedrag voor applicaties die nooit door App-V zijn gegaan.

Waar EtherApps Forge past

EtherApps Forge legt applicaties uit oudere omgevingen vast en zet het herstel klaar als onderdeel van het packagen in plaats van als apart project achteraf, zodat de oplossing voor de werkmap, de bestandsomleiding en het startscript worden beslist terwijl het package wordt gebouwd, niet nadat een pilot is mislukt.

Het is een Windows-desktopapplicatie met een gratis proefperiode van 7 dagen, geen gehoste dienst, dus captures en uitvoer blijven binnen uw omgeving. De route legacy apps behandelt inventarisatie en herstel, MSIX-packaging en uitrol behandelt signing, validatie en levering, en applicatiemodernisering en -migratie behandelt welke applicaties deze weg überhaupt nemen.

Ontdek modernisering van legacy applicaties

Beantwoord de vier vragen voordat u converteert, en de conversie levert geen verrassingen meer op.