App-V till MSIX: de fyra sakerna som går sönder varje gång

Att konvertera App-V-paket till MSIX är mestadels mekaniskt tills det inte är det. Fyra saker står för den överväldigande majoriteten av rapporterna om att "det konverterade fint och beter sig nu konstigt", och det är samma fyra varje gång.

De är värda att känna till innan du börjar, eftersom var och en är billig att hantera medvetet och dyr att upptäcka i en testring.

Den bakomliggande orsaken är densamma i alla fyra fallen: App-V virtualiserade saker som App-V styrde, och MSIX containeriserar dem annorlunda. Allt som applikationen förlitade sig på att App-V skulle göra åt den behöver ett nytt svar. Inget av detta är ett fel i MSIX. De två formaten drar helt enkelt gränsen mellan paket och miljö på olika ställen.

Öppna paketet innan du konverterar det

Ett App-V 5-paket är inte ogenomträngligt. Filen .appv är en OPC-container, i praktiken en zip med ett manifest inuti, så allt du behöver går att läsa innan ett konverteringsverktyg rör det.

Tre filer bär beteendet:

• AppxManifest.xml, inuti .appv, håller standardvärdena som producerades när applikationen sekvenserades.
• <PackageName>_DeploymentConfig.xml bär maskinomfattande inställningar och skript i maskinkontext.
• <PackageName>_UserConfig.xml bär inställningar per användare och skript i användarkontext.

Företrädet går UserConfig över DeploymentConfig över manifestet, så en inställning kan finnas i alla tre med olika värden och bara ett är aktivt. Läser du bara manifestet missar du de anpassningar som lades till senare för att få applikationen att fungera, och det är de bärande.

Att packa upp dem tar sekunder:

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 }

Läs alla tre konfigurationskällorna först, och dirigera sedan varje fynd dit det nu hör hemma.

1. Miljövariabler

Med App-V kunde du definiera miljövariabler i paketet, och applikationen såg dem inuti sin virtuella miljö. De ligger i ett <EnvironmentVariables>-delsystem, och endera konfigurationsfilen kan lägga till eller ta bort dem:

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

MSIX hanterar detta annorlunda, och variablerna du deklarerade i App-V kommer inte med. En applikation som läser en variabel för att hitta en datasökväg, ett servernamn eller en licensplats startar upp och beter sig som om den aldrig konfigurerats. Den fungerar, den vet bara ingenting.

Vad du bör göra: räkna upp variablerna paketet deklarerade innan du konverterar. Folk hoppar över detta, eftersom variablerna inte syns i applikationens egen konfiguration. Bestäm sedan för var och en: en variabel på maskin- eller användarnivå som dina distributionsverktyg sätter, ett värde i en konfigurationsfil applikationen läser, eller något ett startskript sätter först.

Felsignaturen är en applikation som startar rent och sedan klagar på en saknad server eller sökväg. Se upp för den tystare varianten, där den faller tillbaka på ett inbyggt standardvärde i stället för att ge fel och dyker upp veckor senare.

2. Genvägar

App-V-paket bar sina genvägsdefinitioner i sin helhet. Elementet <Shortcut> namnger den .lnk som ska skapas, dess <Target>, <Icon>, <Arguments>, <WorkingDirectory> och <Description>, så att ett sekvenserat paket återskapade vad installationsprogrammet än lade på Start-menyn.

MSIX genererar i stället sin post ur paketmanifestet, och resultatet är inte alltid det App-V producerade. Genvägen hamnar någon annanstans, ikonen är fel eller saknas, eller kommandoradsargumenten är borta.

Den sista är den farliga. Skickade App-V-genvägen ett argument som satte applikationen i ett visst läge och gör MSIX-posten inte det, får användarna en applikation som öppnas i fel tillstånd snarare än en som misslyckas synligt. Att publicera samma applikation två gånger, som "Finance" och som "Endast läsning", med skillnaden helt buren av en växel, är vanligare än man skulle önska.

Vad du bör göra: fånga hela genvägsdefinitionen, inklusive argument och arbetskatalog, och återskapa den medvetet. Där ett argument verkligen skiljer två sätt att köra applikationen blir det vanligen två applikationsposter i manifestet.

Kontrollera arbetskatalogen specifikt. Sätter inget den använder Windows katalogen System32 för en paketerad applikation, vilket är varför "den hittar inte sina egna filer" är ett så vanligt första symtom. Package Support Framework sätter den uttryckligen med ett workingDirectory-värde i config.json, den vanligast tillämpade fixen efter vilken konvertering som helst. Vilken PSF-fix behöver jag kartlägger resten.

3. Skript

Detta är den enskilt största skillnaden och den som spårar ur migreringar.

App-V stödde skript vid åtta punkter i livscykeln, vilket förklarar hur mycket logik miljöer samlar på sig ospårat:

App-V-miljöer som körts länge har ofta verklig logik i de skripten: koppla en enhet, hämta konfiguration, städa en temporär plats, registrera något. Flera skript kan hänga på en utlösare genom ScriptRunner.exe, så en enda AddPackage-post kan köra fyra saker i följd.

MSIX erbjuder inte samma krokar för livscykelskript. Närmaste motsvarighet är Package Support Framework, som kör ett PowerShell-skript före ett paketerat körbart program och ett efter att det avslutas, satt per körbart program som startScript och endScript i config.json.

Det täcker StartProcess och ExitProcess. Det täcker inte de andra sex. Allt som kördes vid tillägg, publicering, avpublicering eller borttagning flyttar in i dina distributionsverktyg, det enda som nu vet när ett paket kommer eller går.

Vad du bör göra: hitta skripten innan du konverterar, och läs dem. Några blir installations- eller avinstallationsbeteende i Intune eller Configuration Manager. Några blir ett startskript i paketet. Några blir applikationskonfiguration. Några dubblerar vad plattformen nu gör själv, och kan raderas med lättnad.

Två praktiska noteringar. Skriptkörning kräver att PowerShells körningspolicy är satt till RemoteSigned för både 64-bitars- och 32-bitarsvärden. Och StartingScriptWrapper.ps1 måste ligga i paketet bredvid det körbara programmet, annars körs ingenting och ingenting förklarar varför.

Felsignaturen här är den värsta av de fyra, eftersom applikationen fungerar perfekt för den som testar den, vars enhet redan var kopplad.

4. Filtypskopplingar

App-V registrerade kopplingar inuti sin virtuella miljö i detalj: filändelsen, dess ProgId, de begripliga namnen, och skalkommandon med egna kommandorader, så att ett högerklicksverb "Redigera" kunde starta programmet med en annan växel än "Öppna".

MSIX deklarerar dem i manifestet som ett tillägg, och deklarationen måste stämma:

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

Fyra saker går fel, ungefär i den frekvensordningen.

Kopplingen är inte deklarerad alls, så att dubbelklicka på en fil gör inget nyttigt.

Den är deklarerad men Windows respekterar den inte, eftersom en annan applikation redan äger filändelsen och användarens val vinner. Resultatet fungerar på paketeringsmaskinen och inte på en verklig användares enhet.

Name är fel. Det måste vara med små bokstäver, och det bör vara stabilt över uppdateringar, för det är identifieraren Windows grupperar filtyperna under.

Filändelsen är reserverad. Windows håller filändelser och URI-scheman för inbyggda applikationer, och en registrering för en sådan ignoreras snarare än avvisas, så det ser ut som om deklarationen inte tog.

De egna verben är den del folk glömmer. Skalkommandon utöver ett vanligt öppna överlever inte resan.

Vad du bör göra: lista filändelserna paketet registrerade, med deras ProgId-värden och eventuella skalkommandon, deklarera dem i manifestet, och testa på en enhet som har de applikationer en verklig användare har, inte en ren virtuell maskin utan konkurrerande anspråk.

Medan du ändå är där, notera URL-protokollen, AppPaths, programvaruklienterna och COM-inställningarna som samma filer bär. En lobapp://-hanterare som tyst upphörde att finnas är ett förvirrande ärende.

Ordningen som sparar tid

Gör hela inventeringen innan du konverterar något:

1. Hämta miljövariablerna paketet deklarerar, från alla tre källorna.
2. Hämta genvägsdefinitionerna, inklusive argument och arbetskatalog.
3. Hämta och läs skripten, med notering om vilken utlösare vart och ett hänger på.
4. Lista filtypskopplingarna, deras ProgId-värden och deras skalkommandon.
5. Notera de återstående delsystemen: URL-protokoll, AppPaths, programvaruklienter, COM.

Notera beslutet bredvid varje fynd, inte bara fyndet. "Sätter LOBAPP_DATA" är en anteckning. "Sätter LOBAPP_DATA, blir en användarvariabel i Intune-distributionen" är en plan.

Det är högst en timme per applikation, och det förvandlar konverteringen från inventering till genomförande. Hoppa över det så hittar du var och en av dessa i en testring, med en användare som rapporterar symtomet snarare än orsaken.

Ett exempel. En ekonomiapplikation konverterar rent, och sedan dyker två saker upp i piloten: den hittar inte sina mallar, eftersom paketet satte en variabel som pekade på en utdelad mapp, och halva gruppen öppnar den i fel läge, eftersom App-V-genvägen skickade en växel för endast läsning. Båda låg i _DeploymentConfig.xml innan någon konverterade något.

Konvertera sedan, och testa som standardanvändare på en enhet som liknar en verklig.

Var detta passar in

Den bredare migreringsvägen, inklusive vilka paket som över huvud taget bör bli MSIX, finns i migrering från App-V till MSIX. Värt att läsa jämsides: App-V Server tar slut, App-V gör det inte, för tidplanen är mindre brådskande än de flesta rapporter antydde och att forcera dessa konverteringar är hur de fyra problemen ovan når produktion.

Konvertering av äldre appar till MSIX täcker samma containerbeteenden för applikationer som aldrig gick genom App-V alls.

Var EtherApps Forge passar in

EtherApps Forge fångar in applikationer från äldre miljöer och förbereder åtgärderna som en del av paketeringen snarare än som ett separat projekt efteråt, så att åtgärden för arbetskatalogen, filomdirigeringen och startskriptet bestäms medan paketet byggs, inte efter att en pilot misslyckats.

Det är en Windows-skrivbordsapplikation med en kostnadsfri provperiod på 7 dagar, inte en värdbaserad tjänst, så infångningar och utdata stannar inuti din miljö. Rutten äldre appar täcker upptäckt och åtgärder, MSIX-paketering och utrullning täcker signering, validering och leverans, och applikationsmodernisering och migrering täcker vilka applikationer som över huvud taget tar den här vägen.

Utforska modernisering av äldre applikationer

Besvara de fyra frågorna innan du konverterar, så slutar konverteringen producera överraskningar.