XFA vooraf installeren met Microsoft Configuration Manager (SCCM)

Maak een Application aan met een deployment type Windows Installer en geef je koppeltoken mee als MSI-eigenschap. Vooraf installeren is een Enterprise-functie.

XFA heeft geen MDM nodig

XFA is gemaakt om zelf geïnstalleerd te worden door het team dat je wilt beveiligen. Zij installeren het zelf na een uitnodiging via Awareness, of bij een aanmelding die door Enforcement beschermd wordt. Voor de meeste organisaties is dat de hele uitrol.

1. Download het installatiebestand

Download XFA.msi en zet het op je content share.

Eén installatiebestand dekt x64 en ARM64. Op ARM64 draait het onder emulatie en vervangt XFA zichzelf automatisch door de native versie.

2. Maak de applicatie aan

Ga in de console van Configuration Manager naar Software Library > Application Management > Applications en maak een applicatie aan op basis van XFA.msi. Configuration Manager leest de product code en maakt de detectiemethode voor je aan.

De koppeling bevestigen, niet alleen de installatie

De regel die je instelt meldt of XFA geïnstalleerd is, niet of deze gebruiker aan je organisatie gekoppeld is. Wil je de koppeling bevestigen, bijvoorbeeld wanneer een toestel al XFA voor een andere organisatie draait, gebruik dan een compliance rule die in de context van de gebruiker draait. Een detectiemethode draait als het systeemaccount en kan niet bij de installatie per gebruiker, dus %LOCALAPPDATA% hieronder wijst alleen naar het juiste profiel wanneer de regel als de gebruiker draait.

xfa staat niet in het PATH en is een venstertoepassing, dus een regel die het rechtstreeks uitvoert wacht er niet op en krijgt de afsluitcode niet te zien. Start de backend, wacht erop en meld alleen bij afsluitcode 0 dat het toestel gekoppeld is (10 betekent niet gekoppeld):

$run = Start-Process "$env:LOCALAPPDATA\XFA\xfa-backend.exe" -Wait -PassThru `
  -ArgumentList 'enrollment-status', '--organization-id', '<id>'
if ($run.ExitCode -eq 0) { Write-Output 'Affiliated' }

Vervang de detectieregel op product code voordat je uitrolt

Dit is de instelling die goed moet staan. De regel die Configuration Manager aanmaakt, controleert de product code van de MSI. XFA maakt die code opnieuw aan telkens wanneer het zichzelf bijwerkt, dus na de eerste zelfupdate komt de genoteerde code niet meer overeen. Configuration Manager meldt XFA dan als niet geïnstalleerd en installeert bij elke evaluatiecyclus de versie uit het pakket over de nieuwere heen. Laat je die regel staan, dan duw je een oudere versie over je hele vloot.

Vervang die door een PowerShell-detectiescript. Configuration Manager beschouwt XFA als geïnstalleerd wanneer het script iets naar standaarduitvoer schrijft, en als ontbrekend wanneer het niets schrijft.

Het script moet met twee dingen rekening houden. Configuration Manager voert de detectie uit als het systeemaccount, ook wanneer de app voor de gebruiker installeert, dus een regel onder HKEY_CURRENT_USER of %LOCALAPPDATA% leest het profiel van dat systeemaccount en ziet de installatie van de gebruiker nooit. En XFA installeert per gebruiker, dus "geïnstalleerd" is een vraag over de aangemelde gebruiker en niet over de machine: op een gedeelde pc heeft elke gebruiker een eigen kopie nodig.

Detecteer dus de installatie van de aangemelde gebruiker. XFA schrijft per gebruiker een markering weg op HKCU\Software\XFA\DesktopApp, die het systeemaccount kan lezen in de hive van die gebruiker onder HKEY_USERS. Nog een addertje: XFA.msi is een 32-bits installatiebestand, dus op een 64-bits machine komt de markering in de 32-bits registerweergave terecht, en na de zelfupdate naar ARM64 verhuist die naar de 64-bits weergave. Detectiescripts draaien standaard 64-bits, dus controleer beide weergaven en aanvaard de markering in elk van beide:

$console = (Get-CimInstance Win32_ComputerSystem).UserName
if ($console) {
    try {
        $sid = ([System.Security.Principal.NTAccount]$console).Translate(
            [System.Security.Principal.SecurityIdentifier]).Value
        $installed = $false
        foreach ($view in @([Microsoft.Win32.RegistryView]::Registry32,
                            [Microsoft.Win32.RegistryView]::Registry64)) {
            $base = [Microsoft.Win32.RegistryKey]::OpenBaseKey(
                [Microsoft.Win32.RegistryHive]::Users, $view)
            try {
                $key = $base.OpenSubKey("$sid\Software\XFA\DesktopApp")
                if ($key) { $installed = $true; $key.Close() }
            } finally { $base.Close() }
        }
        if ($installed) { Write-Output 'Installed' }
    } catch { }
}

De detectie kijkt naar aanwezigheid en niet naar de versie, zodat de zelfupdates van XFA er nooit over struikelen. Ze is gericht op de aangemelde gebruiker, dus op een gedeelde machine installeert Configuration Manager XFA voor elke persoon zodra die zich aanmeldt, in plaats van iedereen na de eerste over te slaan. De markering wordt bij de installatie weggeschreven en blijft staan bij zelfupdates, dus de regel klopt voor elke versie. De try/catch doet ertoe: kan het account niet naar een SID vertaald worden (bijvoorbeeld omdat een domeincontroller even onbereikbaar is), dan schrijft het script niets en leest Configuration Manager "niet geïnstalleerd", wat de veilige kant is, nooit een verkeerde match.

Dit gaat uit van één interactieve gebruiker tegelijk, het normale geval bij een laptop of desktop. Op een host met meerdere sessies (Remote Desktop Session Host) geeft Win32_ComputerSystem.UserName alleen de gebruiker aan de fysieke console door, dus de detectie dekt daar die ene gebruiker en niet elke sessie.

3. Stel het installatieprogramma in

Neem het commando over uit Integraties > XFA vooraf installeren via MDM > Microsoft Configuration Manager (SCCM) in het XFA-dashboard, waar je token al in staat:

msiexec /i "XFA.msi" /qn ENROLLMENT_TOKEN=<token-from-xfa-dashboard>

Zet EMAIL niet in een uitrol over een hele vloot

EMAIL stelt één adres in. Een Application heeft één installatieprogramma voor de hele collectie, dus een adres daarin koppelt elk toestel in die collectie als die ene persoon.

Bij toestellen in een domein leest XFA het adres per toestel uit het attribuut mail in Active Directory, en dat is wat je wilt. Het valt terug op de user principal name wanneer mail leeg is of er geen domeincontroller bereikbaar is.

Mislukken toestellen met een fout over het adres, dan ligt de oplossing in Active Directory (vul mail in voor die accounts) en niet in het installatiecommando. EMAIL is bedoeld voor een installatie op één toestel, waarvan je weet van wie het is.

Kies de UPN wanneer mail niet de identiteit is waaronder je koppelt

Standaard leest XFA eerst het attribuut mail uit Active Directory en daarna de user principal name. Bij een vloot met Entra of Microsoft 365 is de UPN meestal het echte adres van de persoon, terwijl mail verouderd of leeg kan zijn. Voeg PREFER_UPN=1 toe aan het installatiecommando om eerst de user principal name te proberen:

msiexec /i "XFA.msi" /qn ENROLLMENT_TOKEN=<token> PREFER_UPN=1

Laat die optie weg bij een klassieke vloot in een domein: een achtervoegsel als corp.local ziet eruit als een geldige UPN maar is geen adres, en daarom komt mail standaard eerst.

Verwijderprogramma:

powershell.exe -NoProfile -ExecutionPolicy Bypass -File uninstall-xfa.ps1

De product code verandert bij elke zelfupdate, dus het verwijderen kan niet naar de oorspronkelijke XFA.msi verwijzen: na een update komt die code niet meer overeen met wat er geïnstalleerd staat. Lever uninstall-xfa.ps1 mee naast XFA.msi in je content source. Het script zoekt het huidige product op via Windows Installer aan de hand van de vaste UpgradeCode van XFA, die voor elke versie dezelfde is en niet afhangt van de 32-bits of 64-bits registerweergave, en verwijdert het daarna:

$ErrorActionPreference = 'Stop'
$upgradeCode = '{FE5FD0A4-8D39-42FD-B0DE-18EB89B7CAC4}'
try {
    $installer = New-Object -ComObject WindowsInstaller.Installer
    $products = @($installer.RelatedProducts($upgradeCode))

    if ($products.Count -ne 1) { exit 1 }
    $p = Start-Process 'msiexec.exe' -ArgumentList "/x $($products[0]) /qn" -Wait -PassThru
    if (-not $p) { exit 1 }
    exit $p.ExitCode
} catch {
    exit 1
}

Hef de koppeling op voor je verwijdert

Het verwijderprogramma haalt het pakket weg maar voert xfa unenroll niet uit, dus blijft de koppeling met de organisatie op de server achter. Bij een toestel dat bij meerdere organisaties hoort, haalt het XFA ook bij die andere weg.

Voer eerst als de aangemelde gebruiker xfa unenroll --organization-id <id> uit, om alleen deze organisatie te verwijderen en XFA geïnstalleerd te houden. Verwijder de applicatie pas wanneer er geen koppeling meer is: xfa enrollment-status geeft afsluitcode 0 zolang het toestel nog aan een organisatie gekoppeld is, en 10 wanneer verwijderen veilig is.

4. Stel de opties van het deployment type in

XFA is een applicatie per gebruiker, dus die moet installeren terwijl de gebruiker aangemeld is.

Instelling	Waarde
Installation behavior	Install for user
Logon requirement	Only when a user is logged on
Installation program visibility	Hidden
Deployment target	User collection

Install for user is de instelling die goed moet staan

De client van Configuration Manager draait als SYSTEM. Laat je de instelling op Install for system staan, dan installeert een applicatie per gebruiker in het SYSTEM-profiel: Configuration Manager meldt succes, terwijl de aangemelde gebruiker geen XFA heeft en nooit op je pagina Toestellen verschijnt.

XFA weigert te koppelen wanneer het als systeemaccount draait, dus je krijgt een fout te zien die de instelling benoemt in plaats van een installatie in een profiel dat niemand gebruikt. De instelling blijft wel wat het probleem voorkomt.

5. Uitrollen en controleren

Rol de applicatie uit naar een user collection, zodat die installeert voor de aangemelde gebruiker.

Een beheerd toestel rondt het koppelen af bij de volgende aanmelding

XFA registreert het toestel bij de dienst tijdens de installatie, dus het verschijnt meteen op je pagina Toestellen. Daarna bewaart het de gegevens van het toestel in het profiel van de aangemelde gebruiker.

Een beheerde installatie kan draaien in een sessie die nog niet naar dat profiel kan schrijven. Configuration Manager installeert onder een aanmelding vanuit de dienst, die geen eigen opslag voor gegevens heeft. Gebeurt dat, dan noteert XFA de koppeling en bewaart het de gegevens de volgende keer dat de gebruiker zich aanmeldt, vanuit een sessie die dat wel kan, en geeft het van daaruit de beveiligingsstatus door. Een net uitgerold toestel kan dus verschijnen voor het volledig rapporteert, en komt goed zodra de gebruiker zich heeft aangemeld. Dat gaat vanzelf, je hoeft niets in te stellen.

Controleer daarna of:

het XFA-icoon in het systeemvak van de aangemelde gebruiker verschijnt, en
het toestel bij die gebruiker verschijnt op de pagina Toestellen in XFA.

Een geweigerd token laat de installatie mislukken, dus toont Configuration Manager de uitrol als mislukt in plaats van een toestel door te laten dat wel installeerde maar niet bij je organisatie kwam. Het meldt een algemene installatiefout in plaats van de eigen reden van XFA, dus lees die in %TEMP%\xfa\xfa-enrollment.log op het toestel: een geweigerd token staat daar als code 2, een onbereikbare dienst als code 3 (dat is het opnieuw proberen waard). XFA blijft hoe dan ook geïnstalleerd.