Jamf Blog
Août 1, 2018 Par Jonathan Yuresko

« L’Imaging, c’est dépassé ! » Et maintenant on fait quoi ? (Partie 2)

Dans cette deuxième partie nous examinerons les différentes règles, scripts et paquets à mettre en place pour construire de nouveaux workflows qui ne sont pas basés sur l’imaging.

Pour résumer, dans la première partie nous avons abordé la préparation et l’organisation du workflow nécessaire pour remplacer l’imaging.

Configuration

Maintenant que vous avez tous les éléments que vous souhaitez déployer dans une liste et un dossier des éléments que vous souhaitez uploader sur Jamf, lancez-vous : c’est parti ! Uploadez tous les paquets et tous les scripts/réglages que vous avez rassemblés et que vous installeriez normalement via l’image « maîtresse ». Une fois que tous les paquets sont dans Jamf Pro, nous pouvons créer une structure de règles qui fera d’une pierre plusieurs coups. Il s’agit d’une structure à trois règles : la règle Payload (entité), la règle Provision (approvisionnement) et la règle d’installation de Self Service. Consultez les captures d’écran ci-dessous. Il y a de nombreuses manières d’effectuer cette tâche, et il y aura d’autres messages expliquant encore d’autres options. L’utilisation de cette structure primaire rendra votre tâche 10 fois plus facile sur le long terme et garantira l’approvisionnement constant de tous vos scénarios de déploiement.

Pour l’exemple ci-dessous, nous déploierons une app non issue du Mac App Store et une règle contenant un réglage. Vous pouvez utiliser ces modèles pour chaque élément que vous souhaitez déployer, même si certains souhaiteront laisser de côté la « règle Self Service », puisque son déploiement ne s’avérera nécessaire qu’au moment de l’approvisionnement.

Exemple d’app - Google Chrome :

  1. Groupe intelligent
    1. Nom du groupe intelligent : “Has Google Chrome”
    2. Critères : “Application Title is Google Chrome.app”
  2. Règle Payload
    1. Nom de la règle : “Main – Google Chrome”
    2. Catégorie : “Main Policy”
    3. Trigger (déclencheur) : Custom – “main_googlechrome”
    4. Fréquence : “Ongoing”
    5. Payload 1 : Package - “Google Chrome.pkg”
    6. Payload 2 : Maintenance – “Update Inventory”
    7. Périmètre : Target - “All Computers” ou “All Managed Clients”
  3. Règle Provision
    1. Nom de la règle : “Provision – Google Chrome”
    2. Catégorie : “Provisioning”
    3. Trigger (déclencheur) : Custom – “provision_googlechrome”
    4. Fréquence : “Ongoing”
    5. Payload : Execute Command - “jamf policy -trigger main_googlechrome”
    6. Périmètre : Target - “All Computers”
    7. Périmètre : Exclude – Smart Group: “Has Google Chrome”
  4. Règle Self Service
    1. Nom de la règle : “Google Chrome”
    2. Catégorie : “Browsers” ou toute autre désignation
    3. Trigger (déclencheur) : “Self Service”
    4. Fréquence : “Ongoing”
    5. Payload : Execute Command - “jamf policy -trigger main_googlechrome”
    6. Périmètre : Target – “All Computers” ou “All Managed Clients”
    7. Périmètre : Exclude – Smart Group: “Has Google Chrome”

Exemple de réglage – Activation du Service de localisation

  1. Règle Payload
    1. Nom de la règle : “Main – Turn on Location Services”
    2. Catégorie : “Main Policy”
    3. Trigger (déclencheur) : Custom – “main_locationservices”
    4. Fréquence : “Ongoing”
    5. Payload 1 : Script - “turnOnLocationServices.sh”
    6. Payload 2 : Maintenance – “Update Inventory”
    7. Périmètre : Target - “All Computers” ou “All Managed Clients”
  2. Règle Provision
    1. Nom de la règle : “Provision – Turn on Location Services”
    2. Catégorie : “Provisioning”
    3. Trigger (déclencheur) : Custom – “provision_locationservices”
    4. Fréquence : “Ongoing”
    5. Payload : Execute Command - “jamf policy -trigger main_locationservices”
    6. Périmètre : Target - “All Computers” ou “All Managed Clients”

Vous vous dites peut-être : « Mais je croyais que ce serait plus simple et finalement on dirait que ça va prendre énormément de temps ! » Alors soyons francs, plus vous avez d’éléments dans votre workflow d’approvisionnement, plus la création de la structure ci-dessus devrait prendre du temps. Mais nous avons un kit d’API intégré à Jamf Pro qui est très performant et qui, avec des scripts et de l’automatisation, permet de créer des centaines de règles dans le même laps de temps que pour en créer une seule manuellement. Voyez sur https://github.com/jamfprofessionalservices/Provisioning-Workflows/tree/master/Automation_Scripts_and_Templates. Je n’insisterai jamais assez sur le fait qu’il faut utiliser les API et les webhooks pour éviter d’avoir à exécuter des tâches répétitives. N’ayez pas peur de recourir aux API ou aux scripts. Consultez notre documentation sur les bases : https://developer.jamf.com/apis/jamf-pro-api/index.

Au fur et à mesure que vous avancez, vérifiez votre travail pour vous assurer que l'entité (payload) ne se trouve que dans la règle Main et que toutes les autres règles (« Self Service » ou « Provisioning ») disposent des bons déclencheurs de personnalisation pour appeler la règle Main. Consultez ces captures d’écran à titre d’exemples. C’est là qu’on gagne du temps. Si vous respectez les étapes ci-dessus, à chaque fois qu’un fabricant lance une nouvelle mise à jour de son logiciel, vous, de votre côté, n’avez qu’une seule règle à mettre à jour ! La règle Main sera toujours utilisée pour déployer l’entité souhaitée, et comme c’est le seul endroit qui accueille l’entité à déployer, vous n’avez qu’à mettre à jour/modifier cette seule règle. Jusqu’à présent, dans les workflows, vous aviez peut-être besoin de plusieurs règles pour que tout soit toujours mis à jour, mais maintenant, de quelque façon que vous envisagiez le déploiement d’un nouveau logiciel Adobe, de BBedit, Slack ou d’un navigateur, vous n’avez plus qu’à remplacer l’entité qui se trouve dans la règle Main.

Un dernier conseil concernant le déploiement d’applications : essayez d’utiliser des scripts pour déployer les logiciels. Déployer une app via un script, cela signifie que dans la règle Main, vous aurez un script au lieu d’un fichier .pkg or .dmg et que le script va automatiquement accéder au fabricant, télécharger la toute dernière version et l’installer sur l’appareil cible en deux temps trois mouvements. En d’autres termes, vous n’aurez jamais à mettre à jour des règles pour cette app, car son fournisseur/fabricant adaptera la version en amont, mais votre script accédera à la bonne URL pour obtenir l’app mise à jour ! Vous trouverez des exemples sur des sites comme https://macapps.link/en ou http://www.getmacapps.com. Plus vous configurez maintenant, moins vous aurez d’adaptations à faire par la suite. Configurez pour être tranquille !

Dans la troisième partie, nous verrons comment le lancement d’un workflow d’approvisionnement est assuré par un ensemble très cohérent.

Vous n’êtes pas encore un client de Jamf ? Profitez d’un essai gratuit pour essayer vous-même notre solution.

Jonathan Yuresko
S'abonner au blog

Recevez directement dans votre boîte mail les tendances du marché informatique, les mises à jour Apple et les actualités Jamf.

Pour en savoir plus sur la manière dont nous collectons, utilisons, partageons, transférons et protégeant vos informations personnelles, veuillez consulter notre Politique de confidentialité.