MSIX App Attach – Kan det brukes eller er det fortsatt betavare?


Har det endelig kommet en enkel og uproblematisk løsning for applikasjonspakking av alle Windows applikasjoner? Vi har undersøkt modenheten til MSIX App Attach, og har en del anbefalinger og tips i denne bloggen.

MSIX App Attach – Kan det brukes eller er det fortsatt betavare?


Har det endelig kommet en enkel og uproblematisk løsning for applikasjonspakking av alle Windows applikasjoner? Vi har undersøkt modenheten til MSIX App Attach, og har en del anbefalinger og tips i denne bloggen.

Bakgrunn for artikkelen

I stadig flere prosjekter som etableres med Citrix Virtual Apps and Desktops (CVAD) eller kun Windows 10 på klienter, viser det seg at antallet applikasjoner som skal installeres fortsatt er mange. Dersom alle applikasjoner må installeres i ett masterimage som skal dekke alle applikasjoner, vil dette imaget som oftest bli stort. Er det slik at noen av applikasjonene er legacy (noe som ikke er uvanlig for nyere CVAD installasjoner i dag), har de gjerne en eller flere krav som ofte kan gå i beina på andre applikasjoner.

Mange applikasjoner legger ofte igjen spor etter en avinstallasjon, eller at avinstallasjon faktisk ikke fungerer.

MSIX App Attach er en metode hvor man knytter en applikasjon med en virtuell disk som mountes på klient eller server. Dette kan sammenliknes litt med hvordan for eksempel FSLogix Profiles gjør det for å «lure» Windows til å tro at profil-data ligger lokalt på maskin når de faktisk er plassert på et SMB-share. På denne måten kan man legge til byggeklosser (disk containere VHD/VHDX eller CIM) hvor applikasjonene ligger, og disse fjernes like fort som de ble lagt til.

Dette høres forlokkende ut, spesielt i ett miljø hvor man har mange forskjellige basis-images grunnet flere applikasjoner. Det ville være tidsbesparende å kunne forholde seg til kun ett basis image og deretter bare mounte opp applikasjonsdisker etter behov. Høres litt ut som App-V egentlig bare med enklere krav til infrastruktur og mer fremtidsrettet.

Hva gir MSIX App Attach oss?

Jeg ser flere fordeler ved å benytte MSIX App Attach:

  • Forenkling av applikasjonsdrift og vedlikehold av programvare og man kan bruke eksisterende MSIX-pakker (om noen i det hele tatt har begynt med dette)
  • Ikke noe behov for egen infrastruktur enn ett fileshare (her støttes også Azure Fileshares, da dette er en tjeneste som er laget i utgangspunktet for Windows Virtual Desktop)
  • Funger Onprem og i sky og er kun begrenset av operativsystem og build på denne.
  • Fungerer på virtuelle eller fysiske maskiner, single eller multi-user miljøer.
  • MSIX app attach kan nå gi noe av de samme funksjonene som App-V ble brukt til. App-V blir ikke lenger utviklet videre, så dette er fremtidens metode for applikasjonshåndtering.

Hva krever MSIX App Attach?

Navnet sier litt om hva som kreves, da alt må pakkes om til MSIX-format. MSIX-format er ett moderne pakke-format som gir en utvidet funksjonalitet til alle Windows-applikasjoner (Win32, WPF og Windows Forms). Dette kan være kildefiler som MSI, EXE eller App-v pakker etc). MSIX App Attach krever også at pakkene signeres med ett CodeSigning sertifikat (Mer om det etterpå) og gjerne også en Timestamp-server.

Det anbefales at scripts som brukes for å trigge applikasjonene også signeres med samme sertifikat.

MSIX App Attach krever også nyere versjoner av Windows 10 (build 1909) og Windows Server 2019 (build 1909). MSIX og installasjon av pakken direkte krever lavere builds.

Filformater som kan brukes til App Attach til disk-volumene er VHD/VHDX eller CIM. Det siste formatet ble introdusert i build 2004, så det krever en forholdsvis oppdatert plattform, mens VHDx fungerer på build 1909. Det er verdt å merke seg da at det ikke fungerer på Windows Server 2019 LTSC som er build 1809. Da må man installere current release på server-plattformen også.

Noen tips

Dersom Azure Fileshares brukes i testen, husk å legge til disse sharene som Intranet Sites (med UNC-path om denne skal mappes som stasjon). Dette gjør at ved kjøring av script og mounting av diskvolumer, er disse som lokale disker å regne. Det samme gjelder å signere powershell-scripts for å slippe midlertidige stans under kjøring

Installer Hyper-V powershell module for å kunne manipulere og opprette disker:

Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V-Management-PowerShell

Pakkeverktøy

Det ble under testen brukt to forskjellige pakkeverktøy for å generere MSIX-pakker. Det ene var EMCO Package Builder Architect edition (som støtter flere formater å distribuere pakker på) og MSIX Packaging Tool fra Windows Store. Grunnen til at det ble brukt flere verktøy er at det rett og slett var forskjeller i resultatene når pakkene ble generert. Det verktøyet som fungerte best i denne testen var verktøyet fra Microsoft Store.

CodeSigning sertifikat

En viktig komponent i pakkingen er at det må signeres med ett sertifikat som har funksjonen CodeSigning. Det fungerer også med ett selfsigned sertifikat, MEN da må dette sertifikatet også legges på Trusted Root Authorities på alle klienter og servere hvor det skal distribueres pakker laget med dette sertifikatet. Husk også at sertifikatet som skal signere legges på brukerens personlige cert-store, mens trusted root authorities er på lokal maskin.

Opprette ett selfsigned cert i powershell:

New-SelfSignedCertificate -Type Custom -Subject “CN=Sicra Software, O=Sicra Lab, C=NO” -KeyUsage DigitalSignature -FriendlyName “Sicralabs” -CertStoreLocation “Cert:\CurrentUser\My” -TextExtension @(“2.5.29.37={text}1.3.6.1.5.5.7.3.3”, “2.5.29.19={text}”)

  • Eksporter med private-key om det skal brukes på en annen klient
  • Må trustes på alle klienter hvor applikasjonene skal distribueres.

 

Timestamp url, denne kan velges i EMCO, men må spesifiseres i MSIX Packager. En timestamp sørger for at det faktisk er mulig å installere pakken uten at sertifikatet trustes: http://tsa.swisssign.net

Cert signing: https://docs.microsoft.com/en-us/windows/msix/package/create-certificate-package-signing

Lage en MSIX App Attach disk.

Scriptet under lager en dynamisk VHDX-fil på 1Gb. Krever applikasjonen mer, justeres dette før innholdet kopieres inn (av åpenbare årsaker). Hyper-V Powershell-modulen må være installert for å bruke modulene nedenfor:

<#        
             .NOTES
=====================================================================

              Created on:   19/08/2020 23:38
              Created by:   Ryan Mangan
              Organization:              ryanmangans IT BLOG LTD
              Filename:        createvdisk.ps1
=====================================================================
             .DESCRIPTION
                          Create a virtual disk for MSIX App Attach
#>

# Create Vdisk for App Attach
write-Host “Ryan Mangans IT Blog Technical Demo” -ForegroundColor yellow
Write-Host “MSIX App Attach Disk creation” -ForegroundColor Green
#$filepath = read-Host “Enter the file path and name for the VHD e.g :\temp\notepad++.vhd”
$filepath = “c:\temp\DISK.vhdx”
#Create vdisk
Write-Host “Creating a 1 Gb dynamic VHDX-file in ” + $filepath -ForegroundColor Green
New-VHD -SizeBytes 1024MB -Path $filepath -Dynamic -Confirm:$false
#mount vdisk
$vhdObject = Mount-VHD $filepath -Passthru
#Intialise the disk
$vdisk = Initialize-Disk -Passthru -Number $vhdObject.Number
# create a disk partition
$partition = New-Partition -AssignDriveLetter -UseMaximumSize -DiskNumber
$vdisk.Number
# Format-Volume -FileSystem NTFS -Confirm:$false -DriveLetter $partition.DriveLetter -Force
Format-Volume -FileSystem NTFS -Confirm:$false -DriveLetter $partition.DriveLetter -Force

 

Når scriptet er kjørt, mountes disken til en ledig stasjon der hvor scriptet kjøres. Når en applikasjon er pakket i MSIX, kan denne åpnes ved å rename filen til .ZIP og pakke denne ut på vanlig måte i Explorer.

Kopier innholdet til en folder på rot i disken (feks MSIX). Scriptene her bruker også Applikasjonsnavnet som foldernavn på applikasjonen. Det unike navnet brukes også når det refereres til applikasjonen når denne skal registreres i etterkant.

Dette er viktig informasjon som lagres i en JSON-fil der hvor scriptene kjøres. Det lages script for staging og registrering som er mounting av volumer og mountpoints for filene, samt deregistrering og destaging, da dette fjerner applikasjonen og sporene til VHDx filene. Dette er viktig da mountpointene ellers blir liggende og må ryddes opp på en annen måte.

Innholdet i en slik JSON-fil kan da være (det innenfor klammene <> fjernes fra fila):

[
  {
    “_comment1”: “You can name the applicaton or provide notes in this comment section”,
    “vhdFileName”: “Notepad++.vhd”, <Navnet på diskfila>
    “parentFolder”: “MSIX”, <Navnet på rot-folder i diskfila>
    “packageName”: “NotepadPlusPlus_7.9.0.0_x64”, <Pakkenavnet, bør også være der hvor alle filene ligger>
    “volumeGuid”: “3b551b0b-9818-4fb1-a3e5-b739ed2e9ccd”, <id på diskvolumet>
    “msixJunction”: “C:\\temp\\AppAttach” <Der hvor diskjunctions opprettes>
  }
]

En slik JSON-fil kan inneholde referanser til mer enn en applikasjon. Det kan være at en applikasjon er avhengig av en annen, eller at det rett og slett er enklere å dele inn på denne måten.

Innholdet i VHDx fila

Her kan man se igjen variablene fra JSON-fila, samt innholdet fra MSIX-pakken på høyre side. Skal man ha flere applikasjoner i disk-fila, må disse ligge i hver sin folder under MSIX-rotfolderen.

Kjøre / installere en MSIX-disk

Det er dette som i bunn og grunn er MSIX app attach. I eksempelet her er det brukt 4 powershell-script for å teste det ut, det kan fint slåes sammen til 2, en for staging og registrering, ett siste for å fjerne og rydde opp. Det er henvist til kildeartikkel i bunn av denne, og der er det også referanse til Ryan Mangans script på Github, denne ligger her: https://github.com/RMITBLOG/MSIX_APP_ATTACH

Dersom sertifikatet som pakkene er signert med ikke trustes på den klienten som testes på, vil ikke applikasjonene heller registrere seg. Så det er viktig å ha kontroll på sertifikatene! Kjøres scriptene fra andre steder en lokalt fra, så er det kjekt å signere disse også, samt å klarere stien de kjøres ifra (f.eks. Azure File Share).

Dette scriptet signerer med det første CodeSigning sertifikatet den finner i Cert-store for kjørende bruker.

 ## Signs a file
param([string] $file=$(throw “Please specify a filename.”))
$cert = @(Get-ChildItem cert:\CurrentUser\My -codesigning)[0]
Set-AuthenticodeSignature $file $cert

 

 

Hvordan fungerer dette i praksis?

Årsaken til denne testen var personlig at jeg har for liten erfaring med MSIX og app attach (som veeeeldig mange prater om, men som ingen egentlig vet HVA er).

For meg som har bakgrunn fra Citrix og terminalserver, var det forlokkende å kanskje kunne klare seg med ett basis-image, og kun mounte opp disker etter behov. Og deretter bare endre innholdet i disse diskene når applikasjonene skulle endres. Dette vil jo bety øyeblikkelig endring på serverne (eller klientene) når diskene endres.

I praksis er jeg litt mer reservert, da jeg får forskjellig resultat på pakke-prosessen ved forskjellige verktøy. Testen er gjort med Notepad++ og Google Chrome Enterprise browser. Sistnevnte fikk jeg aldri til å hverken installere eller mounte opp, mens førstnevnte fikk jeg installert som MSIX. Sliter fortsatt med å få pakken til å fyre fra disk!

Applikasjonene registrerer seg, og jeg kan fyre disse opp om jeg browser meg frem til der hvor MSIX-applikasjonene ligger (C:\ProgramFiles\WindowsApps NotepadPlusPlus_7.9.0.0_x64__6mpbd5299gtgj\)

Med såpass komplisert fremgangsmåte, og det at det ikke fungerer «ut av boksen» når man følger «anvisningene» gjør meg litt betenkt. Dette er i beste fall beta-vare og jeg ville ikke vurdert dette i produksjon på en god stund enda. Er jo for såvidt det Microsoft selv sier, men man kan ha inntrykk av noen ganger at de mener noe annet 🙂

Referanser for testene: https://docs.microsoft.com/en-us/azure/virtual-desktop/app-attach