Pré-instalar o XFA com o Microsoft Configuration Manager (SCCM)

Crie uma Application com um deployment type do tipo Windows Installer e passe o seu token de inscrição como propriedade MSI. A pré-instalação é uma funcionalidade Enterprise.

O XFA não exige um MDM

O XFA foi feito para ser instalado pela própria equipa que quer proteger. As pessoas instalam-no elas próprias depois de um convite através do Awareness, ou num início de sessão protegido pelo Enforcement. Para a maioria das organizações, é essa toda a distribuição.

1. Transfira o instalador

Transfira o XFA.msi e coloque-o na sua content share.

Um único instalador cobre x64 e ARM64. Em ARM64 corre sob emulação e o XFA substitui-se automaticamente pela versão nativa.

2. Crie a aplicação

Na consola do Configuration Manager, vá a Software Library > Application Management > Applications e crie uma aplicação a partir do XFA.msi. O Configuration Manager lê o product code e cria o método de deteção por si.

Confirmar a inscrição, não apenas a instalação

A regra que define indica se o XFA está instalado, não se este utilizador está inscrito na sua organização. Para confirmar a afiliação, por exemplo quando um dispositivo já pode estar a correr o XFA para outra organização, use uma compliance rule que corra no contexto do utilizador. Um método de deteção corre como conta do sistema, que não consegue alcançar a instalação por utilizador, por isso o %LOCALAPPDATA% abaixo só aponta para o perfil certo quando a regra corre como o utilizador.

O xfa não está no PATH e é uma aplicação com janela, por isso uma regra que o execute diretamente não espera por ele nem recebe o seu código de saída. Arranque o backend, espere por ele e comunique como afiliado apenas com o código de saída 0 (10 significa não 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' }

Substitua a regra de deteção por product code antes de distribuir

Esta é a definição que tem mesmo de acertar. A regra que o Configuration Manager gera verifica o product code do MSI. O XFA gera um novo product code sempre que se atualiza, por isso, depois da primeira atualização automática, o código registado deixa de corresponder. O Configuration Manager comunica então o XFA como não instalado e reinstala a versão do pacote por cima da mais recente, em cada ciclo de avaliação. Se ficar assim, empurra uma versão mais antiga para toda a frota.

Substitua-a por um PowerShell detection script. O Configuration Manager considera o XFA instalado quando o script escreve na saída padrão, e em falta quando não escreve nada.

O script tem de ter em conta duas coisas. O Configuration Manager corre a deteção como conta do sistema, mesmo quando a aplicação se instala para o utilizador, por isso uma regra em HKEY_CURRENT_USER ou %LOCALAPPDATA% lê o perfil da própria conta do sistema e nunca vê a instalação do utilizador. E o XFA é uma instalação por utilizador, por isso "instalado" é uma pergunta sobre o utilizador com sessão iniciada, não sobre a máquina: num PC partilhado, cada utilizador precisa da sua própria cópia.

Detete portanto a instalação do utilizador com sessão iniciada. O XFA escreve um marcador por utilizador em HKCU\Software\XFA\DesktopApp, que a conta do sistema consegue ler na hive desse utilizador em HKEY_USERS. Há mais um pormenor: o XFA.msi é um instalador de 32 bits, por isso numa máquina de 64 bits o marcador fica na vista de registo de 32 bits, e depois da atualização automática para ARM64 passa para a vista de 64 bits. Os scripts de deteção correm em 64 bits por predefinição, por isso verifique ambas as vistas e aceite o marcador em qualquer uma delas:

$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 { }
}

Isto deteta pela presença, não pela versão, por isso as atualizações automáticas do XFA nunca o fazem disparar. O âmbito é o utilizador com sessão iniciada, por isso numa máquina partilhada o Configuration Manager instala o XFA para cada pessoa à medida que inicia sessão, em vez de saltar toda a gente depois da primeira. O marcador é escrito na instalação e mantém-se ao longo das atualizações automáticas, por isso a regra serve para qualquer versão. O try/catch conta: se a conta não puder ser resolvida para um SID (por exemplo, se um controlador de domínio estiver brevemente inacessível), o script não escreve nada e o Configuration Manager lê "não instalado", que é o lado seguro, nunca uma correspondência falsa.

Isto pressupõe um utilizador interativo de cada vez, que é o caso normal num portátil ou num computador de secretária. Num anfitrião multi-sessão (Remote Desktop Session Host), Win32_ComputerSystem.UserName comunica apenas o utilizador da consola física, por isso a deteção aí cobre esse utilizador e não todas as sessões.

3. Defina o programa de instalação

Copie o comando de Integrações > Pré-instalar o XFA através de MDM > Microsoft Configuration Manager (SCCM) no painel XFA, que já contém o seu token:

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

Não ponha EMAIL numa distribuição em frota

EMAIL define um só endereço. Uma Application tem um único programa de instalação para toda a collection, por isso pôr aí um endereço inscreve todos os dispositivos da collection como essa pessoa.

Numa frota associada a um domínio, o XFA lê o endereço do atributo mail do Active Directory, por dispositivo, que é o que quer. Recua para o user principal name quando mail está vazio ou quando nenhum controlador de domínio está acessível.

Se os dispositivos falharem com um erro de endereço, a correção é no Active Directory (preencher mail para essas contas), não no comando de instalação. O EMAIL serve para instalar num único dispositivo, quando sabe de quem é.

Prefira o UPN quando mail não for a identidade sob a qual inscreve

Por predefinição, o XFA lê primeiro o atributo mail do Active Directory e depois o user principal name. Numa frota Entra ou Microsoft 365, o UPN é normalmente o endereço real da pessoa, e mail pode estar desatualizado ou por preencher. Acrescente PREFER_UPN=1 ao comando de instalação para tentar primeiro o user principal name:

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

Deixe-o de fora numa frota clássica associada a um domínio: um sufixo de diretório como corp.local é um UPN com aspeto válido que não é um endereço, e é por isso que mail vem primeiro por predefinição.

Programa de desinstalação:

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

O product code muda a cada atualização automática, por isso a desinstalação não pode nomear o XFA.msi original: depois de uma atualização, o product code deste já não corresponde ao que está instalado. Distribua o uninstall-xfa.ps1 juntamente com o XFA.msi na content source. Ele resolve o produto atual através do Windows Installer pelo UpgradeCode estável do XFA, que é o mesmo em todas as versões e independente da vista de registo de 32 ou 64 bits, e remove-o:

$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
}

Desinscreva antes de desinstalar

O programa de desinstalação remove o pacote mas não executa xfa unenroll, por isso deixa a afiliação à organização para trás no servidor e, num dispositivo que pertença a mais do que uma organização, retira também o XFA das outras.

Execute primeiro xfa unenroll --organization-id <id> como o utilizador com sessão iniciada, para remover apenas esta organização e manter o XFA instalado. Depois remova a aplicação apenas quando já não restar nenhuma afiliação: xfa enrollment-status devolve o código de saída 0 enquanto o dispositivo continuar afiliado a alguma organização, e 10 quando for seguro desinstalar.

4. Defina as opções do deployment type

O XFA é uma aplicação por utilizador, por isso tem de se instalar enquanto o utilizador tem sessão iniciada.

Definição	Valor
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 é a definição que tem de acertar

O cliente do Configuration Manager corre como SYSTEM. Se ficar em Install for system, uma aplicação por utilizador instala-se no perfil SYSTEM: o Configuration Manager comunica sucesso e o utilizador com sessão iniciada fica sem XFA e nunca aparece na sua página Dispositivos.

O XFA recusa inscrever-se quando corre como conta do sistema, por isso isto comunica uma falha que nomeia a definição em vez de concluir para um perfil que ninguém usa. Ainda assim, é a definição que o evita.

5. Distribua e verifique

Distribua a aplicação para uma user collection, para que se instale para o utilizador com sessão iniciada.

Um dispositivo gerido termina a inscrição no próximo início de sessão do utilizador

O XFA regista o dispositivo no serviço durante a instalação, por isso aparece de imediato na sua página Dispositivos. Depois guarda as credenciais do dispositivo no perfil do utilizador com sessão iniciada.

Uma instalação gerida pode correr numa sessão que ainda não consegue escrever nesse perfil. O Configuration Manager instala sob um logon do lado do serviço que não tem um cofre de credenciais próprio. Quando isso acontece, o XFA regista a inscrição e termina de guardar as credenciais no próximo início de sessão do utilizador, a partir de uma sessão que o consiga fazer, e comunica o estado de segurança a partir daí. Por isso, um dispositivo acabado de distribuir pode aparecer antes de estar a comunicar por completo, e estabiliza assim que o utilizador iniciar sessão. É automático e não há nada para configurar.

Depois confirme que:

o ícone do XFA aparece na área de notificação do utilizador com sessão iniciada; e
o dispositivo aparece para esse utilizador na página Dispositivos do XFA.

Um token recusado faz falhar a instalação, por isso o Configuration Manager mostra a distribuição como falhada em vez de deixar passar um dispositivo que instalou sem se juntar à sua organização. Comunica uma falha genérica do instalador em vez do código de razão do próprio XFA, por isso leia a razão em %TEMP%\xfa\xfa-enrollment.log no dispositivo: um token recusado lê-se aí como código 2, um serviço inacessível como código 3 (vale a pena tentar de novo). O XFA fica instalado de qualquer forma.