„Imaging gehört der Vergangenheit an!“ - Und jetzt? (Teil 2)

Im ersten Teil unserer Blog-Serie haben wir erläutert, warum Imaging der Vergangenheit angehört und haben uns zudem mit der Vorbereitung und strukturierten Umsetzung des Workflows befasst, der die bisherigen Imaging-Vorgänge ersetzt.

Das Setup

Zuvor haben Sie alle Elemente, die Sie bereitstellen wollen, in eine Liste eingetragen und einen Ordner mit Elementen erstellt, die für den Upload in Jamf bereit sind. Im folgenden Schritt laden Sie alle Pakete und alle Skripte/Einstellungen hoch, die Sie zusammengetragen haben und die Sie normalerweise mithilfe des „Master“-Images installieren würden. Nachdem Sie alle Pakete in Jamf Pro hochgeladen haben, können Sie eine Richtlinienstruktur erstellen, mit der Sie mehrere Fliegen mit einer Klappe schlagen können. Die Struktur setzt sich aus drei Richtlinien zusammen: Payload-Richtlinie, Bereitstellungsrichtline und der Installationsrichtlinie für Self Service (werfen Sie hierzu einen Blick auf die untenstehenden Screenshots).
Es gibt verschiedene Möglichkeiten, diese Aufgabe durchzuführen, und weitere Optionen werden in anderen Beiträgen genauer erläutert. Diese Hauptstruktur wird Ihnen das Leben jedoch langfristig deutlich erleichtern und sicherstellen, dass alle Ihre Bereitstellungsszenarien einheitlich umgesetzt werden.

In dem folgenden Beispiel werden wir eine Anwendung, die nicht aus dem Mac App Store stammt, sowie eine Richtlinie mit einer bestimmten Einstellung anwenden. Sie können diese Vorlagen für alle weiteren Elemente verwenden, die Sie anwenden möchten. Unter Umständen können Sie die Richtlinie für Self Service jedoch auslassen, da diese möglicherweise nur bei der Bereitstellung benötigt wird.

Beispiel für eine Anwendung – „Google Chrome“:

1. Dynamische Gruppe
   1. Name of Smart Group: „Has Google Chrome“
   2. Criteria: „Application Title is ‚Google Chrom.app‘“
2. Payload-Richtlinie
   1. Name of Policy: „Main – Google Chrome“
   2. Category: „Main Policy“
   3. Trigger: „Custom“ – „main_googlechrome“
   4. Frequency: „Ongoing“
   5. Payload 1: „Package“ – „Google Chrome.pkg“
   6. Payload 2: „Maintenance“ – „Update Inventory“
   7. Scope: „Target“ – „All Computers“ oder „All Managed Clients“
3. Bereitstellungsrichtlinie
   1. Name of Policy: „Provision – Google Chrome“
   2. Category: „Provisioning“
   3. Trigger: „Custom“ – „provision_googlechrome“
   4. Frequency: „Ongoing“
   5. Payload: „Execute Command“ – „jamf policy -trigger main_googlechrome“
   6. Scope: „Target“ – „All Computers“
   7. Scope: „Exclude“ – „Smart Group“: „Has Google Chrome“
4. Richtlinie für Self Service
   1. Name of Policy: „Google Chrome“
   2. Category: „Browsers“ oder ein anderer beliebiger Name
   3. Trigger: „Self Service“
   4. Frequency: „Ongoing“
   5. Payload: „Execute Command“ – „jamf policy -trigger main_googlechrome“
   6. Scope: „Target“ – „All Computers“ oder „All Managed Clients“
   7. Scope: „Exclude“ – „Smart Group“: „Has Google Chrome“

Beispiel für eine Einstellung – „Turn on Location Services“

1. Payload-Richtlinie
   1. Name of Policy: „Main – Turn on Location Services“
   2. Category: „Main Policy“
   3. Trigger: „Custom“ – „main_locationservices“
   4. Frequency: „Ongoing“
   5. Payload 1: „Script“ – „turnOnLocationServices.sh“
   6. Payload 2: „Maintenance“ – „Update Inventory“
   7. Scope: „Target“ – „All Computers“ oder „All Managed Clients“
2. Bereitstellungsrichtlinie
   1. Name of Policy: „Provision – Turn on Location Services“
   2. Category: „Provisioning“
   3. Trigger: „Custom“ – „provision_locationservices“
   4. Frequency: „Ongoing“
   5. Payload: „Execute Command“ – „jamf policy -trigger main_locationservices“

Scope: „Target“ – „All Computers“ oder „All Managed Clients“

Möglicherweise denken Sie jetzt, dass dieser Prozess viel einfacher sein und weniger Zeit beanspruchen sollte. Tatsächlich wird die Ausarbeitung der obigen Struktur noch länger dauern, je nachdem wieviele Elemente Ihr Bereitstellungsworkflow enthält. Jamf Pro verfügt jedoch über ein äußerst leistungsstarkes API-Toolkit, das es uns mithilfe einiger Skripte und ein wenig Automatisierung ermöglicht, Hunderte von Richtlinien in der Zeit zu erstellen, die wir für die manuelle Erstellung einer einzigen benötigen würden.

Ressourcen hierfür finden Sie unter https://github.com/jamfprofessionalservices/Provisioning-Workflows/tree/master/Automation_Scripts_and_Templates (auf Englisch).

Ich kann Ihnen nur eindringlich raten, APIs und Webhooks zu verwenden, um wiederkehrende Aufgaben zu automatisieren. Scheuen Sie sich nicht davor, APIs zu verwenden oder Skripte zu erstellen. Schauen Sie sich hierzu gerne unsere Dokumentation zu den Grundlagen an: https://developer.jamf.com/apis/jamf-pro-api/index.

Kommen wir zu unserem Beispiel zurück. Prüfen Sie Ihre Arbeit, um sicherzustellen, dass die Payload nur unter „Main Policies“ angezeigt wird und dass für jede andere Richtlinie („Self Service“ oder „Provisioning“) der richtige benutzerdefinierte Auslöser festgelegt ist, sodass die zugehörige Hauptrichtlinie ausgeführt wird. Schauen Sie sich zum besseren Verständnis die obigen Screenshots an.

Jetzt kommen wir zu dem Punkt, an dem die Zeitersparnis einsetzt. Wenn Sie die oben beschriebenen Schritte befolgt haben, müssen Sie jedes Mal, wenn ein Hersteller ein neues Update für seine Software herausgibt, nur noch eine Richtlinie aktualisieren! Die betreffende Hauptrichtlinie wird immer für die Bereitstellung der jeweiligen Payload verwendet. Da sie die einzige Richtlinie mit der bereitzustellenden Payload ist, müssen Sie auch wirklich nur diese eine Richtlinie aktualisieren oder ändern. In früheren Workflows mussten Sie jedes Mal viele verschiedene Richtlinien anpassen, damit alles auf dem neusten Stand war. Jetzt müssen Sie nur noch die Payload der jeweiligen Hauptrichtlinie austauschen, ganz gleich, ob Sie eine neue Adobe Software oder BBedit oder Slack oder einen Browser bereitstellen wollen.

Noch ein letzter Tipp für die Bereitstellung von Anwendungen: Versuchen Sie, die Software mithilfe von Skripten bereitzustellen. Das bedeutet, dass Ihre jeweilige Hauptrichtlinie anstelle einer PKG- oder DMG-Datei ein Skript enthält. Mit diesem Skript wird automatisch beim Hersteller die neuste Version heruntergeladen und sofort auf dem Zielcomputer installiert. Sie müssen also NIE Richtlinien für diese Anwendung aktualisieren. Die Anwendung wird vom Anbieter/Hersteller im Backend aktualisiert und die neue Version wird dank des Skripts von der angegebenen URL abgerufen! Beispiele hierfür finden Sie auf Websites wie https://macapps.link/de oder http://www.getmacapps.com. Je mehr Optionen Sie in diesem Schritt konfigurieren, desto weniger müssen Sie später anpassen. Einmal einrichten und das war‘s!

In Teil 3 werden wir das bisher Gelernte auf die Erstellung eines Bereitstellungsworkflows anwenden.

Sie sind noch kein Jamf Kunde? Dann lernen Sie unsere Best-of-Breed-Lösung für die Verwaltung von Apple Geräten in einer kostenlosen Testversion kennen und wenden Sie die hier gelernten Workflows in der Praxis an.