Plist, macOS und Intune am Beispiel TeamViewer und ZScaler

Wie gut funktioniert das wirklich und wann funktioniert das nicht.

Bei einem Kunden hatten wir neulich die Anforderungen verschiedene Apps auf macOS zu verteilen, unter anderem TeamViewer (natürlich in den Varianten Host und FullClient), sowie ZScaler,

Warum nicht Scripte sondern Plist

Wenn man die Suchmaschine seine Vertrauens anschmeißt kommt man sicherlich auf das Script Repository, beim dem die Apps via macOS Script verteilt werden können.

shell-intune-samples/macOS at master · microsoft/shell-intune-samples (github.com)

Das wirklich ein ausgezeichnetes Repository bei dem ich mir regelmäßig inspirationen oder ganze Scripte hole, um diverse Probleme bei Kunden zu lösen.
Dennoch sind die Scripte nicht immer die perfekte Wahl. Ein paar Punkte, warum ich in dem Fall nicht das Script sondern die normale App Verteilung mit Plist genutzt habe.

• So wie die Scripte dort gebaut sind, laufen sie entweder einmal, oder einfach in regelmäßigen Abständen. Damit würde die App entwender nur einmal installiert werden, oder jedes mal neu
  (Wenn ein Nutzer die App entfernt wird sie nicht mehr neu installiert, oder sie wird jedes mal hart neu installiert und unterbricht ggf. den Nutzer in seiner Arbeit)
• Um die zu Warten sind Kenntnisse in Scripting notwendig. Da das an den Kunden komplett übergehen soll, war der Wunsch nach einer eher “Klickfähigen” Lösung groß
• Die Scripte greifen auf das CDN der Hersteller zu. Wenn diese dort was anpassen, funktionieren die Scripte nicht mehr (ja, kann man anpassen, dann hat das Hosting-Problem halt jemand anders)

Deployment via PKG / DMG und Plist via Intune

Hier unsere Erfahrungen mit Plist, wann sie gut funktionierten und welche Limitierungen es gibt.

Wir haben die Apps als PKG vom Hersteller runtergeladen. Dort gibts für Kunden einen separaten Download bereich.
Anschließend, die App in Intune hochladen, Erkennungsregeln bauen und auf eine Gruppe verteilen.

Anschließend raus aus dem Bereich Apps, rein in den Bereich Geräte. Dort jeweils ein neues Konfigurationsprofil “Preference file” erstellen.
Wichtig ist dabei die sog. Domain richtig auszuwählen. Entwender hat der Hersteller es sauber dokumentiert (Danke an Teamviewer und ZScaler für die Dokus an der Stelle).

Anleitung von ZScaler: Deploying Zscaler Client Connector with Microsoft Intune for macOS | Zscaler
Anleitung von Teamviewer: Das Ausrollverfahren auf MacOS – TeamViewer Support

Mit den Plists lässt sich in beiden Fällen eine “fast” silent installation ermöglichen und die Nutzer müssen nichts mehr manuell installieren.

Beim ZScaler gibts den Parmeter “externalRedirect”. Damit wird erreicht, dass die Anmeldung via Browser passiert. Wenn SSO korrekt konfiguriert ist, muss der Nutzer so keine Anmeldedaten mehr eingeben.

Im Falle ZScaler sollte noch das Root Zertifikat als trusted verteilt werden. Dann kommt auch keine Zertifikatswarnung mehr 😉

stay tuned

Simon