Archives par mot-clé : MDM

Déployer les apps de Microsoft Office à la demande avec un profil de configuration

Parfois chez Gete.Net Consulting, nous sommes confrontés à des problèmes techniques… intéressants. Ainsi, chez certains clients, nous devons déployer la suite Microsoft Office, mais sans installer Outlook, le logiciel par défaut choisi dans l’entreprise étant Apple Mail.

Dans ce cas, l’installation d’Office est un peu compliquée puisqu’il faut installer chaque application séparément, ou installer l’ensemble de la suite puis supprimer Outlook. Et installer les apps séparément peut être beaucoup plus lourd, puisque l’ensemble des applications d’Office installée individuellement pèse plus du double du package complet de Microsoft Office !

Et oui, si on retire Outlook de l’installation, ça fait quand même 3,38 contre 1,92 Go pour le package complet d’Office.

Autre cas aussi : vous souhaitez ne pas installer l’application Microsoft AutoUpdate pour garder le contrôle sur les mises à jour. Mais elle est installée par défaut. Même si vous pouvez la supprimer à posteriori, ça pourrait être plus simple de ne juste pas l’installer (et de ne plus avoir à y penser).

Il existe pourtant une solution pour forcer l’installation uniquement des applications de votre choix depuis le package Office. Pour cela, il faut passer par un profil de configuration (proposé par Paul Bowden, ingénieur Microsoft de l’équipe Microsoft Office Mac) poussé par votre MDM. Ce profil doit contenir des informations personnalisées que vous pouvez retrouver ici :

https://github.com/pbowden-msft/Payloads/blob/master/DeploymentExcluder.plist

Téléchargez ce fichier Property List, et modifiez son contenu pour passer à false toutes les apps que vous ne souhaitez pas installer.

Dans notre cas, pour installer tout Microsoft Office sans installer Outlook, on utiliserait le fichier plist suivant :

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>InstallWord</key>
	<true/>
	<key>InstallExcel</key>
	<true/>
	<key>InstallPowerPoint</key>
	<true/>
	<key>InstallOutlook</key>
	<false/>
	<key>InstallOneNote</key>
	<true/>
	<key>InstallOneDrive</key>
	<true/>
	<key>InstallTeams</key>
	<true/>
	<key>InstallAutoUpdate</key>
	<true/>
</dict>
</plist>

Il suffit maintenant d’importer ce fichier dans un profil de configuration. La méthode dépendra évidemment de votre MDM. Par exemple, dans Jamf Pro :

  • Cliquez sur Profils de configuration > Nouveau
  • Ciquez sur Apps et réglages personnalisés > Upload.
  • Donnez un nom à votre profil.
  • Spécifiez com.microsoft.office dans la ligne Domaine de préférence et collez le contenu du fichier Plist modifié dans le champ Liste de propriétés.
  • Spécifiez enfin le scope de votre profil…
  • Et cliquez sur Enregistrer.

Si vous voulez faire la même chose dans FileWave, il suffit de créer un fileset contenant un profil de configuration, et d’ajouter les données comme Custom Settings.

Poussez ensuite le profil sur les appareils de votre choix, et lancez l’installation de Microsoft Office (via une policy pour Jamf Pro, ou un Fileset dédié pour FileWave, ou en le poussant avec Munki ou le MDM de votre choix). Et si tout va bien, seules les applications validées seront installées.

On dit merci qui ? Merci Paul Bowden (moi je ne suis que le messager) !

Jamf Pro : contrôler quand installer un profil durant le déploiement

Allez, ça faisait un longtemps, un article bien technique, à l’attention d’un public averti. Je vais d’ailleurs cette année essayer de pousser un peu plus ces articles techniques destinés aux administrateurs systèmes et gestionnaires de MDM Apple.

Dans le cadre d’une intégration Jamf Pro chez un des mes clients, j’ai du gérer la problématique suivante :

Comment contrôler à quel moment un profil de configuration doit être installé sur un Mac ?

En effet, une fois un Mac enrôlé dans le MDM (que ça soit automatiquement au démarrage via le programme Apple Business Manager ou Apple School Manager, ou manuellement), à partir du moment où l’on souhaite par exemple déployer un profil Wi-Fi, il est déployé automatiquement via la magie du push. Ce qui pose le risque de casser le déploiement si le profil Wi-Fi impose une bascule automatique.

Exemple : vous êtes employé de Gete.Net Consulting, et vous recevez votre nouveau Mac rutilant. Votre nouveau boss, qui a tout prévu, vous a fait livrer votre Mac, et vous devez l’enrôler dans votre solution de gestion. Ce Mac a été prévu pour se connecter automatiquement au réseau GeteOuEssayéMaisRienNWiFi, dont le mot de passe particulièrement complexe est intégré au profil. Ce qui peut présenter l’avantage d’éviter de devoir transmettre le mot de passe oralement ou par écrit, et de lui donner une complexité bien plus importante. Le profil pourrait aussi permettre de pousser une authentification au Wi-Fi via certificat, ce qui est bien plus sécurisé.

Cependant, si le réseau est à portée d’antenne, le Mac aura tendance durant l’enrôlement à basculer sur ce réseau Wi-Fi sécurisé dès qu’il sera disponible, sans s’occuper de savoir si le reste de l’enrôlement (installation de logiciels par ex) est terminé. Ce qui peut être gênant, vous en conviendrez.

Pour éviter cette rupture dans le déploiement, on peut avoir deux approches :

  1. Fournir le profil à l’utilisateur via le Self Service de Jamf Pro ;
  2. Utiliser une méthode un peu plus complexe, mais entièrement automatisée.

Si nous optons pour l’approche automatisée, voici comment faire. Attention, c’est particulièrement sioux.

Créer un attribut d’extension

Dans la console Jamf Pro, cliquez sur Réglages > Ordinateur et sélectionnez Attributs d’extension.

Cliquez sur Nouveau

Appliquez les différents réglages comme sur la capture d’écran ci-dessous. Pour ce qui est du script lui-même, voici son contenu :

!/usr/bin/env bash
RESULT="Wifi KO"
if [ -f "/var/db/.wifi-ok" ] ; then
RESULT="Wifi OK"
fi
/bin/echo "$RESULT"

Par défaut, on aura donc un attribut d’extension dont le résultat est Wi-Fi KO. Les chemins et les noms de fichier choisis ici sont par ailleurs totalement arbitraires, vous pouvez donc les customiser comme vous le souhaitez.

Variante : vous pouvez aussi créer le fichier à la fin d’un script d’enrôlement pour indiquer que l’enrôlement est bien terminé pour appliquer d’autres conditions. Vous pourriez donc nommer le fichier .EnrolementFini si ça vous chante. Par contre, je vous conseille de le laisser invisible. Perso, je génère un dossier au nom du client dans /usr/local et j’essaie de créer une petite hiérarchie propre dedans, donc ça pourrait être /usr/local/getenet/.EnrolementFini.

Créez un groupe intelligent

Une fois votre attribut étendu généré :

  1. Cliquez sur Groupe intelligent d’ordinateurs > Nouveau ;
  2. Cliquez sur Afficher les critères avancés ;
  3. Choisissez votre critère Activation Wi-Fi ;
  4. Dans la case Valeur, tapez Wifi OK (ou toute autre valeur générée dans le script).
  5. Enregistrez.

Associer le groupe au profil Wi-Fi

Il nous faut maintenant créer notre profil Wi-Fi pour l’associer au Groupe intelligent. Pas l’opération la plus dure :

  1. Cliquez sur Profils de configuration ;
  2. Cliquez sur Nouveau ;
  3. Remplissez votre profil de configuration Wi-Fi comme d’habitude ;
  4. Cliquez sur Périmètre ;
  5. Cliquez sur Computer Groups ;
  6. Cliquez sur le bouton Add en face de votre groupe intelligent créé précédemment (oui, la régionalisation de Jamf Pro, c’est pas toujours ça…) ;
  7. Validez, comme Johnny.

Pfiouuuu. Allez, c’est presque fini.

Activer l’état Wi-Fi Ready

Mais comment lui faire changer son état ? Facile : il suffit de générer le fichier /var/db/.wifi-ok via une simple commande, par exemple en ajoutant dans le script de déploiement la commande :

touch /var/db/.wifi-ok

Suivie d’une mise à jour de l’inventaire :

jamf recon

Notez que tout cela doit se faire dans le contexte du compte root (mais Jamf lance tous les scripts en tant que root, donc c’est OK).

Personnellement, j’ai utilisé cette méthode chez deux clients différents, et elle fonctionne parfaitement avec une version modifiée du script DEPNotify Starter, en générant le fichier à la fin du script.

Et si vous avez besoin d’aide pour mettre cette solution en place, il suffit de demander.

Comment bloquer l’installation de macOS Big Sur

Ça y est, macOS Big Sur est enfin disponible depuis jeudi 12 novembre ! Et du coup, en tant qu’administrateur système, vous êtes extrêmement pressé de voir tout votre parc adopter la nouvelle version…

Attendez, non, c’est pas ça ! Vous n’avez plutôt pas trop envie que vos utilisateurs basculent sur cette nouvelle version de macOS, parce que ça risque de vouloir dire incompatibilités en tout genre.

Faire le point sur les incompatibilités

Il faut d’abord regarder où se trouvent les éventuelles incompatibilités logicielles. En particulier :

  • Les applications encore 32-bit. Tout comme pour Catalina, celles-ci ne feront pas le saut vers macOS Big Sur.
  • Les applications reposant sur des extensions de noyau (les fameux kext). Même si macOS Big Sur ne les abat pas encore totalement (pour certaines, un redémarrage peut suffire), ces dernières n’ont pas vocation à rester et peuvent poser problème. Il faut pour certaines extensions de noyau déployer un profil pour les valider, et il faut redémarrer le poste… Pas idéal. Si l’éditeur d’un logiciel utilisant des extensions de noyau vous annonce qu’il n’est pas encore compatible pour macOS Big Sur, et qu’il ne sait pas quand ça arrivera… Il est peut-être temps de changer de crémerie.
  • Vérifiez aussi la compatibilité de vos matériels avec macOS Big Sur, en particulier vos imprimantes, traceurs… Si certains constructeurs assurent un bon suivi dans le temps, ce n’est pas toujours le cas. Donc, méfiance.
  • Certaines apps web, si vous utilisez Safari. Même si ça semble peu probable, mais si cela vous arrive, il faudra peut-être changer de navigateur.
  • Historiquement, on sait que les versions point zéro de macOS peuvent contenir des bugs parfois réhdibitoires voire critiques. Du coup, attendre la version 11.0.2 est sûrement un choix raisonnable. Et j’ai bien écrit 11.0.2 et non pas 11.0.1 puisque la version finale de macOS cette année est la 11.0.1, et non pas la 11.0 comme la tradition le veut. Bref, attendre quelques semaines n’est pas totalement déconnant.

Je ne veux pas que mes utilisateurs passent sur Big Sur, je fais quoi ?

À une époque où le modern management des ordinateurs devient une idée de plus en plus courante (accès administrateur autorisé à l’utilisateur, sous supervision du système informatique) , il est important de communiquer sur les raisons du blocage. Certains utilisateurs souhaiteront avoir accès dès que possible au dernier macOS, d’autres n’y verront aucun intérêt, mais c’est l’administrateur du parc qui doit assurer la continuité de service. Donc, si vous pouvez bloquer… bloquez.

Pour cela, il existe différentes méthodes.

Déployer un profil de configuration pour retarder les mises à jour via MDM

Si vos Mac sont intégrés dans un MDM (si ce n’est pas le cas aujourd’hui, c’est mal) ou un outil de déploiement de profil comme Munki, vous pouvez déployer un profil masquant les mises à jour pour une certaine durée. Pour cela, utilisez la clé enforcedSoftwareUpdate du payload Restrictions.

Vous pouvez créer ce profil à la main, avec un outil comme ProfileCreator ou configurer directement le réglage dans votre MDM s’il supporte ce payload, par exemple ici dans Jamf Pro :

Attention à bien choisir de retarder les mises à jour de logiciels. Il faudra macOS 10.13.4 minimum pour déployer ce profil.

Le défaut de cette méthode est qu’elle masque toutes les mises à jour, y compris d’éventuelles nouvelles mises à jour de sécurité pour l’OS actuel.

Utiliser une règle de restriction pour empêcher le lancement de l’app d’installation de macOS Big Sur

Quid des utilisateurs qui copient le logiciel d’installation de macOS Big Sur depuis un autre poste pour le lancer ? Dans ce cas, il peut être intéressant de bloquer complètement l’app d’installation de macOS Big Sur pour empêcher toute installation. Sur Jamf Pro, il suffit de bloquer le processus Install macOS Big Sur pour empêcher son lancement.

Déployer un package pour bloquer complètement macOS Big Sur

Une autre solution consiste à installer un package qui bloquera l’installation de macOS Big Sur : BigSurBlocker. Installez le package via votre outil de gestion habituel, et hop, l’utilisateur aura le droit à un petit message pour lui dire que non, nope, c’est pas pour tout de suite. La page liste également une méthode pour désinstaller BigSurBlocker proprement via un script.

Bloquer l’affichage de la mise à jour

Un point agaçant : quelque soit la solution utilisée, la mise à jour macOS Big Sur continuera d’apparaître dans la préférence Système Mise à jour de logiciels. Pour la masquer définitivement, utilisez la commande suivante (en root) :

softwareupdate --ignore "macOS Big Sur"

Cependant, cette commande ne sera efficace que si votre Mac est intégré dans un MDM. Si ce n’est pas le cas, elle ne fera absolument rien. Si votre Mac fonctionne sous mac OS Catalina, elle ne devrait être fonctionnelle que pour macOS 10.15.6 avec les dernières mises à jour de sécurité (Apple ayant apporté quelques changements pénibles sur les versions précédentes de la commande softwareupdate).

Si vous souhaitez à nouveau faire apparaître la mise à jour, envoyez la commande :

softwareupdate --reset-ignored