Preinstalar XFA con Microsoft Configuration Manager (SCCM)
Cree una aplicación con un tipo de implementación Windows Installer y pase su token de inscripción como propiedad MSI. La preinstalación es una función Enterprise.
XFA está pensado para que lo instale por su cuenta el equipo que quiere proteger. Ellos mismos lo instalan tras una invitación a través de Awareness, o en un inicio de sesión protegido por Enforcement. Para la mayoría de organizaciones ese es todo el despliegue.
1. Descargue el instalador
Descargue XFA.msi y colóquelo en su recurso compartido de contenido.
Un solo instalador cubre x64 y ARM64. En ARM64 se ejecuta bajo emulación y XFA se sustituye automáticamente por la versión nativa.
2. Cree la aplicación
En la consola de Configuration Manager, vaya a Software Library > Application Management > Applications y cree una aplicación a partir de XFA.msi. Configuration Manager lee el product code y crea el método de detección por usted.
La regla que configure informa de si XFA está instalado, no de si este usuario está inscrito en su organización. Para confirmar la afiliación, por ejemplo cuando un dispositivo puede que ya ejecute XFA para otra organización, use una regla de cumplimiento que se ejecute en el contexto del usuario. Un método de detección se ejecuta como la cuenta del sistema, que no puede llegar a la instalación por usuario, así que %LOCALAPPDATA% de más abajo solo apunta al perfil correcto cuando la regla se ejecuta como el usuario.
xfa no está en el PATH y es una aplicación con ventana, así que una regla que lo ejecute directamente ni lo espera ni recibe su código de salida. Arranque el backend, espérelo e informe de afiliado solo con el código de salida 0 (10 significa no afiliado):
$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' }
Este es el ajuste que hay que acertar. La regla que genera Configuration Manager comprueba el product code del MSI. XFA regenera su product code cada vez que se actualiza, así que después de la primera autoactualización el código registrado ya no coincide. Configuration Manager informa entonces de que XFA no está instalado y reinstala la versión empaquetada sobre la más nueva, en cada ciclo de evaluación. Si se deja tal cual, distribuye una versión antigua por todo su parque.
Sustitúyala por un script de detección de PowerShell. Configuration Manager considera XFA instalado cuando el script escribe en la salida estándar, y ausente cuando no escribe nada.
El script tiene que tener en cuenta dos cosas. Configuration Manager ejecuta la detección como la cuenta del sistema, incluso cuando la app se instala para el usuario, así que una regla sobre HKEY_CURRENT_USER o %LOCALAPPDATA% lee el perfil propio de la cuenta del sistema y nunca ve la instalación del usuario. Y XFA se instala por usuario, así que "instalado" es una pregunta sobre el usuario con la sesión iniciada, no sobre la máquina: en un PC compartido cada usuario necesita su propia copia.
Así que detecte la instalación del usuario con la sesión iniciada. XFA escribe un marcador por usuario en HKCU\Software\XFA\DesktopApp, que la cuenta del sistema puede leer en el hive de ese usuario dentro de HKEY_USERS. Un detalle más: XFA.msi es un instalador de 32 bits, así que en una máquina de 64 bits el marcador acaba en la vista de registro de 32 bits, y tras la autoactualización a ARM64 pasa a la vista de 64 bits. Los scripts de detección se ejecutan en 64 bits por defecto, así que compruebe las dos vistas y acepte el marcador en cualquiera de ellas:
$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 { }
}
Esto detecta por presencia, no por versión, así que las autoactualizaciones de XFA nunca lo activan. Se limita al usuario con la sesión iniciada, así que en una máquina compartida Configuration Manager instala XFA para cada persona a medida que inicia sesión, en lugar de saltárselas todas después de la primera. El marcador se escribe en la instalación y se mantiene a lo largo de las autoactualizaciones, así que la regla vale para cualquier versión. El try/catch importa: si la cuenta no se puede resolver a un SID (por ejemplo, porque un controlador de dominio no está accesible un momento), el script no escribe nada y Configuration Manager lee "no instalado", que es la dirección segura, nunca una coincidencia falsa.
Esto da por supuesto un solo usuario interactivo a la vez, que es el caso normal en un portátil o un ordenador de sobremesa. En un host multisesión (Remote Desktop Session Host), Win32_ComputerSystem.UserName informa únicamente del usuario de la consola física, así que allí la detección cubre a ese usuario y no a todas las sesiones.
3. Configure el programa de instalación
Tome el comando de Integraciones > Preinstalar XFA mediante MDM > Microsoft Configuration Manager (SCCM) en el panel de XFA, que ya contiene su token:
msiexec /i "XFA.msi" /qn ENROLLMENT_TOKEN=<token-from-xfa-dashboard>
EMAIL fija una sola dirección. Una aplicación tiene un único programa de instalación para toda la colección, así que poner ahí una dirección inscribe todos los dispositivos de la colección como esa persona.
En un parque unido al dominio, XFA lee la dirección del atributo mail de Active Directory, por dispositivo, que es lo que quiere. Recurre al nombre principal de usuario cuando mail está vacío o no hay ningún controlador de dominio accesible.
Si los dispositivos fallan con un error de dirección, el arreglo está en Active Directory (rellene mail para esas cuentas), no en el comando de instalación. EMAIL es para instalar en un único dispositivo, cuando sabe de quién es.
mail no sea la identidad con la que inscribePor defecto XFA lee primero el atributo mail de Active Directory y después el nombre principal de usuario. En un parque con Entra o Microsoft 365 el UPN suele ser la dirección real de la persona, y mail puede estar desactualizado o vacío. Añada PREFER_UPN=1 al comando de instalación para probar primero el nombre principal de usuario:
msiexec /i "XFA.msi" /qn ENROLLMENT_TOKEN=<token> PREFER_UPN=1
Déjelo fuera en un parque clásico unido al dominio: un sufijo de directorio como corp.local es un UPN con aspecto válido que no es una dirección, y por eso mail va primero por defecto.
Programa de desinstalación:
powershell.exe -NoProfile -ExecutionPolicy Bypass -File uninstall-xfa.ps1
El product code cambia con cada autoactualización, así que la desinstalación no puede nombrar el XFA.msi original: después de una actualización su product code ya no coincide con lo instalado. Distribuya uninstall-xfa.ps1 junto a XFA.msi en el origen de contenido. El script resuelve el producto actual a través de Windows Installer por el UpgradeCode estable de XFA, que es el mismo para todas las versiones e independiente de la vista de registro de 32 o 64 bits, y después lo quita:
$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
}
El programa de desinstalación quita el paquete pero no ejecuta xfa unenroll, así que deja la afiliación con la organización en el servidor y, en un dispositivo que pertenece a más de una organización, le quita XFA también a las demás.
Ejecute primero xfa unenroll --organization-id <id> como el usuario con la sesión iniciada, para quitar solo esta organización y mantener XFA instalado. Después quite la aplicación solo cuando no quede ninguna afiliación: xfa enrollment-status devuelve el código de salida 0 mientras el dispositivo siga afiliado a alguna organización, y 10 cuando ya es seguro desinstalarlo.
4. Configure las opciones del tipo de implementación
XFA es una aplicación por usuario, así que tiene que instalarse mientras el usuario tiene la sesión iniciada.
| Ajuste | Valor |
|---|---|
| Installation behavior | Install for user |
| Logon requirement | Only when a user is logged on |
| Installation program visibility | Hidden |
| Deployment target | User collection |
El cliente de Configuration Manager se ejecuta como SYSTEM. Si se deja en Install for system, una aplicación por usuario se instala en el perfil de SYSTEM: Configuration Manager informa de éxito, y el usuario con la sesión iniciada no tiene XFA y nunca aparece en su página Dispositivos.
XFA se niega a inscribirse cuando se ejecuta como la cuenta del sistema, así que esto informa de un fallo que nombra el ajuste en lugar de terminar en un perfil que nadie usa. Aun así, es ese ajuste lo que lo evita.
5. Despliegue y verifique
Despliegue la aplicación en una user collection, para que se instale para el usuario con la sesión iniciada.
XFA registra el dispositivo en el servicio durante la instalación, así que aparece en su página Dispositivos de inmediato. Después guarda las credenciales del dispositivo en el perfil del usuario con la sesión iniciada.
Una instalación gestionada puede ejecutarse en una sesión que todavía no puede escribir en ese perfil. Configuration Manager instala con un inicio de sesión del lado del servicio que no tiene almacén de credenciales propio. Cuando eso ocurre, XFA registra la inscripción y termina de guardar las credenciales la próxima vez que el usuario inicia sesión, desde una sesión que sí puede, y a partir de ahí informa del estado de seguridad. Así que un dispositivo recién desplegado puede aparecer antes de estar informando del todo, y se estabiliza cuando el usuario ha iniciado sesión. Es automático, no hay nada que configurar.
Después confirme que:
- el icono de XFA aparece en la bandeja del sistema del usuario con la sesión iniciada; y
- el dispositivo aparece para ese usuario en la página Dispositivos de XFA.
Un token rechazado hace fallar la instalación, así que Configuration Manager muestra el despliegue como fallido en lugar de dar por bueno un dispositivo que se instaló sin unirse a su organización. Informa de un fallo genérico del instalador y no del código de motivo propio de XFA, así que lea el motivo en %TEMP%\xfa\xfa-enrollment.log del dispositivo: un token rechazado se lee ahí como código 2, y un servicio inaccesible como código 3 (vale la pena reintentarlo). XFA queda instalado en cualquier caso.