Lebenszyklus einer komplexen Applikation
Einfache Applikationspakete an Endgeräte auszubringen, kann in einer komplexen IT-Landschaft bereits eine facettenreiche Aufgabe sein. Doch kaum eine Anwendung wird "einfach nur installiert". Vielmehr unterliegen geschäftliche Applikationen einem deutlich komplexeren Lebenszyklus:

• Anwendungen setzen andere Anwendungen oder Bibliotheken voraus, mit denen sie interagieren.
• Anwendungen werden aktualisiert – entweder in einem regelmäßigen Turnus oder bei Erscheinen neuer Hauptversionen. Manchmal betrifft eine solche Aktualisierung auch Anwendungen, von denen andere Anwendungen abhängen.
• Manchmal müssen Anwendungen durch andere Software abgelöst werden, oder eine neue Hauptversion des gleichen Produktes ist so beschaffen, dass die Vorversion nicht aktualisiert, sondern deinstalliert werden muss.
• Schließlich gibt es Fälle, in denen eine Anwendung zwingend deinstalliert werden muss, wenn sie nicht mehr benötigt wird – etwa weil eine begrenzte Anzahl von Lizenzen erworben wurde und jede Installation eine Lizenz vom zentralen Lizenzserver aufbraucht.

All diese Fälle lassen sich im Anwendungskosmos des SCCM abbilden. Manchmal muss der Anwendungsadministrator dafür aber etwas Kreativität an den Tag legen.

Abhängigkeiten zwischen Anwendungen sind im SCCM eigentlich Abhängigkeiten zwischen Bereitstellungstypen. So kann etwa die 32-Bit-Version einer Anwendung von einer 32-Bit-Version der SQLite-Bibliothek abhängen und deren 64-Bit-Version entsprechend auch SQLite in 64-Bit voraussetzen. Es lassen sich auch mehrere Abhängigkeiten definieren, die alle gegeben sein müssen, bevor die eigentliche Anwendung installierbar ist. Jede Abhängigkeit kann aus mehreren Bereitstellungstypen bestehen, wovon mindestens einer vorhanden sein muss. Vorsicht ist hier beim Setzen des Hakens "Bei Bedarf automatisch installieren" geboten, besonders wenn die dann zu installierende Abhängigkeit einen Neustart erfordert.

Für das Aktualisieren einer Applikation ohne vorherige Deinstallation gibt es zwei Herangehensweisen:

• Ablösung durch eine neue Version, wie oben beschrieben: Dies hat den Nachteil, dass bei häufig aktualisierten Anwendungen viele Anwendungen (eine pro Version) entstehen.
• Aktualisierung der Paketquelle: Wenn gesichert ist, dass der neue Installer die vorhandene Anwendung sauber aktualisiert, kann man die Paketquelle eines bestehenden Bereitstellungstyps ersetzen und mit dem Befehl "Inhalt aktualisieren" neu verteilen.

Bei allen Vorgängen, die eine Deinstallation beinhalten – sei es im Rahmen der Ablösung oder bei erzwungener Deinstallation – müssen drei Bedingungen erfüllt sein:

• Der Deinstallationsvorgang muss in allen Bereitstellungstypen, die dies unterstützen, definiert sein.
• Geräte oder Benutzer, für die die Anwendung deinstalliert werden soll, müssen in Sammlungen enthalten sein, an die die betroffene Anwendung mit der Aktion "deinstallieren" bereitgestellt wird.
• Die betroffenen Geräte oder Benutzer dürfen sich nicht in Sammlungen befinden, an die die Anwendung mit der Aktion "installieren" bereitgestellt wird.

Das müssen Sie sowohl beim Design der Sammlungen als auch der Bereitstellungen berücksichtigen. Haben Sie Prozesse implementiert, die ein Gerät oder einen Benutzer zuverlässig aus einer Installations- in eine Deinstallationssammlung verschieben, können Sie mit statischen Sammlungen arbeiten. Sind Ihre Sammlungen hingegen dynamisch definiert, müssen Sie für zusätzliche Kennzeichnung Ihrer Geräte sorgen, damit sie für die Deinstallation von bestimmten Anwendungen vorgemerkt werden. Das können zum Beispiel Mitgliedschaften in AD-Gruppen sein. Sie können auch die Installationssammlung für jede Anwendung aus ihrer jeweiligen Deinstallationssammlung ausschließen. Damit führt das Entfernen eines Computers oder Benutzers aus der Installationssammlung dazu, dass er automatisch in der Deinstallationssammlung landet.

Keine Angst vor Dopplungen der Quellen
Eine Bereitstellungstopologie für eine komplexe IT-Landschaft kann viele Anwendungen mit noch mehr Bereitstellungstypen beinhalten, die möglicherweise auf die gleichen Installationsquellen zurückgreifen. Die Sorge, dass dies Ihre Verteilungspunkte über Gebühr aufblähen könnte, ist unbegründet. SCCM führt zu jeder Datei eine Prüfsumme mit und speichert die tatsächlichen Inhalte nur einmal. Zusätzliche Kopien bekommen lediglich einen Verweis auf den Inhalt.

Es gibt allerdings einen häufigen Designfehler bei der Platzierung von Inhalten der SCCM-Anwendungen. Er liegt darin begründet, dass die Installationsquellen bei Bereitstellungstypen stets als Ordner referenziert werden, selbst wenn nur eine einzige Datei aus diesem Ordner, wie etwa ein MSI-Paket, für die Installation nötig ist. Würden Sie also im obigen paint.net-Beispiel die x86- und die x64-Datei im gleichen Ordner platzieren, würden stets beide Pakete auf das Endgerät herunterladen, obgleich eines davon unter keinen Umständen dort installierbar wäre. Geschieht dies mit einem größeren Paket wie Microsoft Office oder der Adobe Creative Suite, ist die Platz- und Bandbreitenverschwendung selbst im LAN nicht unerheblich. In WAN-Szenarien sorgt diese Art von Fehlkonfigurationen für deutliche Verzögerungen im Deployment.

Bereitstellen, messen und einschränken
Wie oben beschrieben, werden Anwendungen meist durch eine Installation auf Geräten bereitgestellt, selbst wenn es das erklärte Ziel ist, sie zum Benutzer zu bringen. Oft ist die Tatsache unkritisch, dass sich Anwendungen auf Endgeräten befinden, die von anderen als den ursprünglich vorgesehenen Benutzern gestartet werden können. Manchmal muss aber gewährleistet sein, dass Applikationen nur von berechtigten Nutzern aufgerufen oder bei Bedarf zeitnah wieder entfernt werden.

Für die Einschränkung der Anwendungsnutzung, zumindest auf Windows-Endgeräten in AD-Umgebungen, verwenden Sie am besten AppLocker-Richtlinien. Definieren Sie pro Anwendung eine Gruppe, binden Sie die Installationssammlung für die Anwendung und die AppLocker-Richtlinie, die ihre Nutzung erlaubt, an diese Gruppe und Sie erhalten bereits das Gewünschte. Sie brauchen natürlich eine zweite AppLocker-Richtlinie, die den Nicht-Mitgliedern der Gruppe das Starten der Anwendung verweigert. Um festzustellen, wie die installierten Anwendungen tatsächlich zum Einsatz kommen, bietet SCCM das Feature "Software-Messung" [6] an.

Fazit
Mit dem SCCM beziehungsweise ECM verfügt der Anwendungsverwalter über nahezu unbegrenzte Möglichkeiten, Applikationen zu den Endbenutzern zu bringen. Diese reichen über Betriebssystem- und Organisationsgrenzen hinaus. Mit zusätzlichen Integrationen können auch andere Arten von Anwendungen bereitgestellt werden. Da das Datenmodell von SCCM über viele Dimensionen, Querverbindungen und Abhängigkeiten verfügt, sind ausführliche Tests vor einem Massen-Rollout unabdingbar.



dr/ln/Evgenij Smirnov

[6] https://docs.microsoft.com/de-de/configmgr/apps/deploy-use/monitor-app-usage-with-software-metering