Guides de déploiement géré

Résultat

La documentation destinée aux administrateurs donne les paramètres de déploiement exacts pour Microsoft Intune, Microsoft Configuration Manager et Jamf Pro.

Le dépôt de l'application native de bureau détient les paquets et les publie à des URL stables via distribution.xfa.tech. Ce dépôt renvoie vers ces fichiers au lieu d'en maintenir des copies.

Décisions

XFA est déployé par utilisateur.
Un MDM est facultatif. L'installation par l'utilisateur via Awareness ou Enforcement reste la voie normale et sans friction, tandis que ces guides couvrent le déploiement sans intervention et les parcs déjà gérés.
Le déploiement, c'est le paquet plus le token comme variable, pas un script d'enrobage. Le fichier que le client prépare est le fichier qui s'exécute, rien n'est téléchargé au moment de l'installation, et tout outil capable d'exécuter msiexec ou de pousser un profil peut déployer XFA. C'est aussi ainsi que des agents comparables sont déployés, donc les étapes sont déjà familières.
Sous Windows, le token est passé comme la propriété MSI publique ENROLLMENT_TOKEN. Intune utilise donc une line-of-business app : pas de Content Prep Tool, pas de règle de détection et pas de paramètre de comportement d'installation, car Intune lit tout cela dans le paquet. Intune n'autorise qu'un seul argument de ligne de commande, donc le token est la seule propriété.
Un seul MSI couvre les deux architectures. XFA.msi s'exécute sur ARM64 en émulation et l'updater le remplace par la version native. XFA-arm64.msi n'est documenté que pour les administrateurs qui veulent du natif immédiatement.
Configuration Manager utilise un deployment type de type Windows Installer avec la même propriété, installé pour un utilisateur connecté et déployé vers une user collection.
Sous macOS, le token se trouve dans un profil de configuration (com.xfa.desktop, EnrollmentToken), lu par le client au démarrage, avec un fichier de token comme seconde source. Jamf déploie donc un paquet et un profil, sans script et sans que rien ne s'exécute en tant que root alors que cela doit s'exécuter en tant qu'utilisateur.
Un token refusé fait échouer l'installation sous Windows, si bien que le MDM signale une erreur plutôt qu'un appareil installé mais non rattaché à l'organisation.
Une cinquième page couvre tout autre système, car le principe est que les commandes ci-dessus suffisent à elles seules.
Aucun MDM ne fournit l'adresse e-mail de l'utilisateur assigné. Le client la déduit du compte connecté et accepte --email pour la remplacer ; cela vit dans le client, pour qu'il y ait une seule implémentation et un seul message d'erreur.
Aucun script d'enrobage n'est livré. Les paquets de bureau lisent le token dans une propriété MSI (Windows) ou dans un profil de configuration ou un fichier de token (macOS), si bien que tout outil qui installe un paquet et passe une propriété ou pousse un profil peut déployer XFA sans script à relire.
Le retrait se fait avec xfa unenroll --organization-id <id>, exécuté en tant qu'utilisateur connecté, ce qui retire une seule organisation et conserve les autres. L'application partagée ne se retire par une désinstallation normale qu'une fois que xfa enrollment-status indique qu'il ne reste plus aucun rattachement.

Critères d'acceptation

Chaque système pris en charge a son propre guide avec les paramètres exacts.
Les guides renvoient vers les paquets publiés par le dépôt de l'application native de bureau ; aucun script n'est publié ni requis.
Le choix de l'architecture Windows est expliqué, et les identités d'éditeur que les administrateurs peuvent épingler sont documentées.
La détection sous Windows distingue le rattachement de l'installation. La détection MSI par défaut ne signale que l'installation ; xfa enrollment-status --organization-id <id> est documenté pour une détection propre à l'organisation, mais n'est pas encore la valeur par défaut dans les guides.
L'exécution en tant que root dans Jamf, la propriété par l'utilisateur, l'accès au trousseau et les mises à jour automatiques sont expliqués ; le déclencheur Login évite le cas de l'écran de connexion.
La disponibilité de l'adresse e-mail et son remplacement sont décrits, sans prétendre que le MDM fournit une variable qu'il ne fournit pas.
Le retrait sous Windows retire une seule organisation avec xfa unenroll --organization-id ; le retrait conditionnel de l'application via xfa enrollment-status est documenté mais pas automatisé.
Le rattachement de bout en bout contre le service en production reste à faire dans l'implémentation de l'application de bureau.