Configurer les apps natives

Les applications macOS natives — c’est-à-dire les applications téléversées soi-même sous forme de .pkg ou de .dmg — peuvent être préconfigurées dans Relution. La méthode prévue à cet effet diffère toutefois de celle des applications issues de l’App Store. C’est la source de l’application qui est déterminante, car elle définit la méthode disponible.

La source de l’application détermine la méthode de configuration #

La configuration de politique App gérée → suppose que l’application a été installée via un canal géré par Apple. macOS ne l’applique qu’aux applications installées depuis l’App Store ou via Apps et livres (VPP dans le portail). Pour ces applications, le système d’exploitation se charge d’associer la configuration à l’application à l’aide de l’identifiant de bundle.

Pour les applications natives, ce mécanisme ne s’applique pas, celles-ci n’ayant pas été installées via le canal géré de l’App Store. Elles peuvent certes être sélectionnées dans la configuration App gérée du portail, mais la configuration n’a aucun effet sur elles. La configuration d’une application native doit donc être transmise sous forme de charge utile via la configuration de politique Configuration d’Apple Configurator 2 →.

Configuration des applications natives via Apple Configurator 2 #

Les clés et valeurs prises en charge dans la charge utile (property list) sont définies par l’éditeur de l’application concernée. La mise en place s’effectue en quelques étapes :

1. L’application native est d’abord mise à disposition comme à l’accoutumée, de sorte qu’elle soit installée sur les appareils cibles (voir Installer des applications macOS natives →).
2. La configuration d’application souhaitée est assemblée sous forme de fichier .mobileconfig (voir la recommandation ci-dessous).
3. Une Configuration d’Apple Configurator 2 est ajoutée à la politique, un Nom est saisi et le fichier .mobileconfig est importé dans son intégralité via Sélectionnez le fichier .mobileconfig. Son contenu s’affiche ensuite dans le champ Contenu de la charge utile et peut y être adapté si nécessaire.
4. La politique est publiée puis attribuée aux groupes d’appareils concernés.

Un fichier .mobileconfig ne peut contenir qu’un seul type de configuration (type de charge utile) dans PayloadContent ; des charges utiles de certificat supplémentaires sont autorisées. Si le fichier contient plusieurs types, par exemple des paramètres pour plusieurs applications, la configuration ne peut pas être enregistrée. Une Configuration d’Apple Configurator 2 distincte est donc créée pour chaque application. Si le fichier contient plusieurs charges utiles du même type, seule la première est transmise. Les autres exigences relatives au fichier sont décrites dans l’article Configuration d’Apple Configurator 2 →.

Recommandation : créer la charge utile avec l’iMazing Profile Editor #

La rédaction manuelle d’une charge utile est source d’erreurs. Pour une création confortable, l’outil tiers iMazing Profile Editor est recommandé. Il permet d’assembler la configuration via une interface graphique, sans rédiger à la main la property list sous-jacente.

Le déroulement est le suivant :

1. Dans l’iMazing Profile Editor, les paramètres souhaités pour l’application sont définis via l’interface.
2. Le résultat est exporté sans signature sous forme de fichier .mobileconfig. Relution lit le fichier en tant que XML ; les profils signés ne peuvent pas être enregistrés.
3. Le fichier .mobileconfig complet est importé dans la Configuration d’Apple Configurator 2 de Relution.

Dans la charge utile, les espaces réservés fournis par Relution peuvent également être utilisés (par exemple ${user.email}) afin de remplir la configuration en fonction de l’utilisateur. Les espaces réservés disponibles sont affichés sous le formulaire de configuration et remplacés lors de la transmission de la configuration aux appareils, voir Espaces réservés avancés →.