XFA mit Microsoft Configuration Manager (SCCM) vorinstallieren
Legen Sie eine Application mit einem Deployment Type Windows Installer an und übergeben Sie Ihr Enrollment-Token als MSI-Eigenschaft. Das Vorinstallieren ist eine Enterprise-Funktion.
XFA ist dafür gemacht, vom Team selbst installiert zu werden, das Sie absichern wollen. Die Leute installieren es selbst, nach einer Einladung über Awareness oder bei einer Anmeldung, die durch Enforcement geschützt ist. Für die meisten Organisationen ist das der gesamte Rollout.
1. Das Installationspaket herunterladen
Laden Sie XFA.msi herunter und legen Sie es auf Ihre Content-Freigabe.
Ein Installationspaket deckt x64 und ARM64 ab. Auf ARM64 läuft es per Emulation, und XFA ersetzt sich automatisch durch die native Version.
2. Die Application anlegen
Gehen Sie in der Configuration Manager Console zu Software Library > Application Management > Applications und legen Sie eine Application aus XFA.msi an. Der Configuration Manager liest den Product Code und erstellt die Erkennungsmethode für Sie.
Die Regel, die Sie setzen, meldet, ob XFA installiert ist, nicht, ob dieser Benutzer mit Ihrer Organisation verbunden ist. Um die Affiliation zu bestätigen, etwa wenn ein Gerät XFA bereits für eine andere Organisation ausführen könnte, nutzen Sie eine Compliance-Regel, die im Kontext des Benutzers läuft. Eine Erkennungsmethode läuft als Systemkonto, das die Installation pro Benutzer nicht erreicht, %LOCALAPPDATA% unten zeigt also nur dann auf das richtige Profil, wenn die Regel als Benutzer läuft.
xfa liegt nicht im PATH und ist eine Fensteranwendung, eine Regel, die es direkt ausführt, wartet also weder darauf noch bekommt sie seinen Exit-Code. Starten Sie das Backend, warten Sie darauf und melden Sie nur bei Exit-Code 0 als verbunden (10 heißt nicht verbunden):
$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' }
Das ist die eine Einstellung, auf die es ankommt. Die Regel, die der Configuration Manager erzeugt, prüft den MSI-Product Code. XFA erzeugt seinen Product Code neu, jedes Mal, wenn es sich selbst aktualisiert, nach der ersten Selbstaktualisierung passt der gespeicherte Code also nicht mehr. Der Configuration Manager meldet XFA dann als nicht installiert und installiert bei jedem Auswertungszyklus die paketierte Version über die neuere. Bleibt das so, verteilt er eine ältere Version über Ihre gesamte Flotte.
Ersetzen Sie sie durch ein PowerShell-Erkennungsskript. Der Configuration Manager betrachtet XFA als installiert, wenn das Skript etwas auf die Standardausgabe schreibt, und als fehlend, wenn es nichts schreibt.
Das Skript muss zwei Dinge berücksichtigen. Der Configuration Manager führt die Erkennung als Systemkonto aus, auch wenn die App für den Benutzer installiert wird. Eine Regel unter HKEY_CURRENT_USER oder %LOCALAPPDATA% liest also das eigene Profil des Systemkontos und sieht die Installation des Benutzers nie. Und XFA ist eine Installation pro Benutzer, "installiert" ist also eine Frage zum angemeldeten Benutzer, nicht zur Maschine: Auf einem gemeinsam genutzten PC braucht jeder Benutzer seine eigene Kopie.
Erkennen Sie also die Installation des angemeldeten Benutzers. XFA schreibt eine Markierung pro Benutzer nach HKCU\Software\XFA\DesktopApp, die das Systemkonto in der Hive dieses Benutzers unter HKEY_USERS lesen kann. Noch eine Feinheit: XFA.msi ist ein 32-Bit-Installationspaket, auf einer 64-Bit-Maschine landet die Markierung also in der 32-Bit-Registry-Sicht, und nach der ARM64-Selbstaktualisierung wandert sie in die 64-Bit-Sicht. Erkennungsskripte laufen standardmäßig 64-Bit, prüfen Sie also beide Sichten und akzeptieren Sie die Markierung in jeder davon:
$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 { }
}
Erkannt wird das Vorhandensein, nicht die Version, die Selbstaktualisierungen von XFA bringen die Regel also nie durcheinander. Das Skript ist auf den angemeldeten Benutzer bezogen, auf einer gemeinsam genutzten Maschine installiert der Configuration Manager XFA also für jede Person, sobald sie sich anmeldet, statt nach der ersten alle zu überspringen. Die Markierung wird bei der Installation geschrieben und bleibt über Selbstaktualisierungen hinweg bestehen, die Regel gilt also für jede Version. Das try/catch ist wichtig: Lässt sich das Konto nicht zu einer SID auflösen (etwa weil ein Domänencontroller kurz nicht erreichbar ist), schreibt das Skript nichts und der Configuration Manager liest "nicht installiert", was die sichere Richtung ist, nie ein falscher Treffer.
Das setzt voraus, dass jeweils nur ein Benutzer interaktiv angemeldet ist, der Normalfall bei einem Laptop oder Desktop. Auf einem Multi-Session-Host (Remote Desktop Session Host) meldet Win32_ComputerSystem.UserName nur den Benutzer an der physischen Konsole, die Erkennung deckt dort also diesen einen Benutzer ab und nicht jede Sitzung.
3. Das Installationsprogramm einstellen
Nehmen Sie den Befehl aus Integrationen > XFA über MDM vorinstallieren > Microsoft Configuration Manager (SCCM) im XFA-Dashboard, der Ihr Token bereits enthält:
msiexec /i "XFA.msi" /qn ENROLLMENT_TOKEN=<token-from-xfa-dashboard>
EMAIL setzt genau eine Adresse. Eine Application hat ein Installationsprogramm für die gesamte Collection, eine Adresse dort verbindet also jedes Gerät der Collection als diese Person.
In einer domänengebundenen Flotte liest XFA die Adresse pro Gerät aus dem Attribut mail in Active Directory, und das ist, was Sie wollen. Es greift auf den User Principal Name zurück, wenn mail leer ist oder kein Domänencontroller erreichbar ist.
Schlagen Geräte mit einem Adressfehler fehl, liegt die Lösung in Active Directory (pflegen Sie mail für diese Konten), nicht im Installationsbefehl. EMAIL ist für die Installation auf einem einzelnen Gerät, bei dem Sie wissen, wem es gehört.
mail nicht die Identität ist, unter der Sie verbindenStandardmäßig liest XFA zuerst das Attribut mail in Active Directory, danach den User Principal Name. In einer Flotte mit Entra oder Microsoft 365 ist der UPN meist die echte Adresse der Person, und mail kann veraltet oder leer sein. Fügen Sie PREFER_UPN=1 zum Installationsbefehl hinzu, damit zuerst der User Principal Name versucht wird:
msiexec /i "XFA.msi" /qn ENROLLMENT_TOKEN=<token> PREFER_UPN=1
Lassen Sie es in einer klassischen domänengebundenen Flotte weg: Eine Verzeichnisendung wie corp.local ergibt einen UPN, der wie eine Adresse aussieht, aber keine ist, und genau deshalb kommt mail standardmäßig zuerst.
Deinstallationsprogramm:
powershell.exe -NoProfile -ExecutionPolicy Bypass -File uninstall-xfa.ps1
Der Product Code ändert sich mit jeder Selbstaktualisierung, die Deinstallation kann die ursprüngliche XFA.msi also nicht benennen: Nach einem Update passt ihr Product Code nicht mehr zu dem, was installiert ist. Legen Sie uninstall-xfa.ps1 neben XFA.msi in die Content-Quelle. Das Skript ermittelt das aktuelle Produkt über Windows Installer anhand des festen UpgradeCode von XFA, der für jede Version derselbe ist und nicht von der 32- oder 64-Bit-Registry-Sicht abhängt, und entfernt es dann:
$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
}
Das Deinstallationsprogramm entfernt das Paket, führt aber nicht xfa unenroll aus, es lässt die Affiliation zur Organisation also auf dem Server zurück, und auf einem Gerät, das zu mehr als einer Organisation gehört, entfernt es XFA auch für die anderen.
Führen Sie zuerst xfa unenroll --organization-id <id> als angemeldeter Benutzer aus, um nur diese Organisation zu entfernen und XFA installiert zu lassen. Entfernen Sie die Anwendung erst, wenn keine Affiliation mehr besteht: xfa enrollment-status liefert den Exit-Code 0, solange das Gerät noch mit irgendeiner Organisation verbunden ist, und 10, wenn die Deinstallation sicher ist.
4. Die Optionen des Deployment Type einstellen
XFA ist eine Anwendung pro Benutzer, sie muss also installiert werden, während der Benutzer angemeldet ist.
| Einstellung | Wert |
|---|---|
| Installation behavior | Install for user |
| Logon requirement | Only when a user is logged on |
| Installation program visibility | Hidden |
| Deployment target | User collection |
Der Configuration Manager Client läuft als SYSTEM. Bleibt es bei Install for system, installiert sich eine Anwendung pro Benutzer in das SYSTEM-Profil: Der Configuration Manager meldet Erfolg, und der angemeldete Benutzer hat kein XFA und taucht nie auf Ihrer Seite Geräte auf.
XFA weigert sich zu verbinden, wenn es als Systemkonto läuft, das meldet also einen Fehler und benennt die Einstellung, statt die Installation in einem Profil abzuschließen, das niemand nutzt. Die Einstellung ist trotzdem das, was es verhindert.
5. Verteilen und prüfen
Verteilen Sie die Application an eine User Collection, damit sie für den angemeldeten Benutzer installiert wird.
XFA meldet das Gerät während der Installation beim Dienst an, es erscheint also sofort auf Ihrer Seite Geräte. Danach legt es die Zugangsdaten des Geräts im Profil des angemeldeten Benutzers ab.
Eine verteilte Installation kann in einer Sitzung laufen, die noch nicht in dieses Profil schreiben kann. Der Configuration Manager installiert unter einer dienstseitigen Anmeldung, die keinen eigenen Speicher für Zugangsdaten hat. Passiert das, hält XFA die Verbindung fest und legt die Zugangsdaten bei der nächsten Anmeldung des Benutzers ab, aus einer Sitzung, die das kann, und meldet den Sicherheitsstatus dann von dort. Ein frisch verteiltes Gerät kann also erscheinen, bevor es vollständig meldet, und ist vollständig eingerichtet, sobald der Benutzer sich angemeldet hat. Das passiert von selbst, es gibt nichts einzustellen.
Prüfen Sie dann, dass:
- das XFA-Symbol im Infobereich des angemeldeten Benutzers erscheint; und
- das Gerät für diesen Benutzer auf der XFA-Seite Geräte auftaucht.
Ein abgelehntes Token lässt die Installation fehlschlagen, der Configuration Manager zeigt den Rollout also als fehlgeschlagen, statt ein Gerät durchgehen zu lassen, auf dem die Installation gelaufen ist, ohne dass es Ihrer Organisation beigetreten ist. Er meldet einen allgemeinen Installationsfehler statt des eigenen Ergebniscodes von XFA, lesen Sie den Grund also auf dem Gerät in %TEMP%\xfa\xfa-enrollment.log: Ein abgelehntes Token steht dort als Code 2, ein nicht erreichbarer Dienst als Code 3 (ein erneuter Versuch lohnt sich). XFA bleibt in beiden Fällen installiert.