Anwendungen verteilen mit SCCM (2)

Lesezeit
4 Minuten
Bis jetzt gelesen

Anwendungen verteilen mit SCCM (2)

13.06.2022 - 00:00
Veröffentlicht in:
Geht es um die Verwaltung großer Clientflotten von mehreren Zehntausend Desktops, Laptops und Tablets, kommen Administratoren an System Center Configuration Manager, kurz SCCM, nur schwer vorbei. Auch der Vormarsch von Intune hat an der Relevanz des ersten und ältesten Mitglieds der System-Center-Familie nichts geändert. Wir zeigen, welche Möglichkeiten der Applikationsverwaltung Ihnen im SCCM zur Verfügung stehen. In der zweiten Folge werfen wir einen Blick auf praktische Drittanbieter-Erweiterungen und erklären, warum das passende Applikationsdesign beim Ausrollen von Anwendungen wichtig ist.
Praktische Drittanbieter-Erweiterungen
Neben den werksseitig vorhandenen Bereitstellungstypen existieren vereinzelt gelungene Drittanbieter-Integrationen. So erweitert der "Citrix Connector for SCCM" [3], der vor über zehn Jahren als das inoffizielle "Project Thor" gestartet ist, die Liste der Bereitstellungstypen um "XenApp-/ XenDesktop-Applikation". Damit ist es möglich, eine Anwendung, die über Citrix veröffentlicht ist, an jedes Endgerät auszuliefern, das über einen installierten Citrix Receiver verfügt und bei SCCM registriert ist. Auch die umgekehrte Richtung kann der Connector bedienen. Mit seiner Hilfe können im SCCM Sammlungen, Bereitstellungen und Grenzen aus der Topologie der Citrix-Landschaft erzeugt werden, sodass die komplette Citrix-Veröffentlichung einer Applikation aus dem SCCM heraus erfolgen kann.

Leider ist es nicht möglich, Anwendungen auf diese Art zu verteilen, die mithilfe nativer Microsoft Remote Desktop Services als Remote-Apps veröffentlicht wurden. Auf Endgeräten, die einen Doppelklick auf RDP-Verbindungsdateien korrekt verarbeiten, können Sie solche per RD Web Access erzeugte Dateien mit einem Kopierskript oder auch als MSI-Paket bringen. Um letztere zu erzeugen, gibt es ein kleines kostenloses Tool von Kim Knight [4].

In jedem Fall lohnt es sich zu untersuchen, ob es möglich ist, verwaltete Geräte mit über RDS oder Citrix veröffentlichten Applikationen zu bestücken, falls diese Technologien bereits im Einsatz sind.

Applikationsdesign mit mehreren Bereitstellungstypen
Am einfachsten lässt sich die Logik der Applikationsbereitstellung veranschaulichen, wenn Sie eine Applikation wie paint.net ausrollen möchten, die in zwei getrennten Paketen für 32 und 64 Bit existiert. Im Gegensatz zu manch anderen Programmen ist hier die 32-Bit-Version nicht auf 64-Bit-Systemen ausführbar.

Haben Sie also beide Varianten auf den Endgeräten im Einsatz, wird eine Anwendung mit zwei Bereitstellungstypen benötigt. Beide sind vom Typ "MSI" und verweisen auf die jeweiligen MSI-Pakete des Herstellers. Bei "Anforderungen" sind die jeweils vorhandenen Betriebssysteme (32 Bit oder 64 Bit) angegeben. Da die Anforderungen für beide Bereitstellungstypen sich gegenseitig ausschließen, ist die Priorität der Bereitstellungstypen innerhalb der Anwendung unerheblich.

Bild 2: Die 32-Bit-Version von Paint.net muss auf 32-Bit-Windows installiert werden.

Eine andere Aufteilung auf Bereitstellungstypen ließe sich zum Beispiel mit Outlook in einem Szenario mit gemischten Plattformen und Bring Your Own Device implementieren. Kommt herkömmliche Volumenlizenzierung für Office zum Einsatz, würden wir auf Windows-Geräten, die Mitglied im Active Directory sind und somit ganz klar der Firma gehören, das Programm fest installieren. macOS-Laptops und private mobile Endgeräte sollten lediglich eine Verknüpfung zu Outlook Web Access erhalten, während die firmeneigenen mobilen Endgeräte durchaus die Outlook-App aufgespielt bekommen. In diesem Fall hätte die betreffende Anwendung fünf Bereitstellungstypen:

  • Gescriptete Office-Installation für Windows-Geräte im AD.
  • iOS-App aus dem App Store für iOS-Endgeräte ab Version 10 und im Besitz der Firma.
  • Android-App aus Google Play für Android- beziehungsweise Android-for-Business-Endgeräte und im Besitz der Firma.
  • macOS-Applikation, die eine Verknüpfung zur OWA-URL ausliefert.
  • Webapplikation, die eine Verknüpfung zur OWA-URL ausliefert.
Die Webapplikation muss in der Priorität ganz unten stehen, denn SCCM liefert immer den ersten Bereitstellungstyp aus, bei dem alle Bedingungen passen.

Bild 3: Eine Anwendung kann aus vielen Bereitstellungstypen bestehen.

Für den Fall, dass die 22 mitgelieferten Typen an globalen Bedingungen nicht ausreichen, um die Bereitstellungstypen voneinander abzugrenzen, können Sie auch eigene Bedingungen kreieren. Dies ist sowohl im Bereitstellungstyp (Anforderung "Benutzerdefiniert") als auch in der Anwendungsverwaltung unter "Globale Bedingungen" möglich. Solche komplexeren Bedingungen sind Windows-Clients vorbehalten und können eine Registry-, Active Directory-, WMI-, SQL- oder andere Skriptabfragen beinhalten.

Benutzer, Computer oder beides
Die ideale SCCM-Applikation kommt seit vielen Versionen als MSI-Paket daher und findet ihren Weg mittels des nativen Windows-Installers auf ein Windows-Endgerät. In den wenigsten Fällen ist es mit vertretbarem Aufwand möglich, das Installationspaket so anzupassen, dass die installierte Applikation tatsächlich nur im Kontext eines Users existiert.

Gerade wenn Treiber oder Dienste zum Lieferumfang gehören, ist es klar, dass die Anwendung eigentlich auf einem System installiert wird, auch wenn theoretisch ein Benutzer ihr Ziel ist. Das kann SCCM abbilden. Sie können jede Anwendung sowohl an Computer- als auch an Benutzersammlungen bereitstellen. Dabei gilt es folgendes zu beachten:

  • Benutzerobjekte werden nicht von Computern eingesammelt, sondern aus dem Active Directory mittels "Benutzer-Ermittlung" und gegebenenfalls "Gruppen-Ermittlung" eingelesen.
  • Eine Anwendung, die an Benutzer bereitgestellt war, wird nicht deinstalliert, wenn sich der berechtigte Benutzer wieder abmeldet. Sie verbleibt auf dem Gerät und kann unter Umständen auch von anderen Benutzern aufgerufen werden.
  • Einige Applikationen benötigen lange für die Installation. Manchmal ist ein Neustart oder Abmeldung des bereits angemeldeten Benutzers erforderlich. Da die Installation einer für Benutzer bereitgestellten Anwendung erst mit der Anmeldung eines berechtigten Benutzers startet, könnte dies die Benutzererfahrung beeinträchtigen. Abhilfe schafft hier der Mechanismus "Benutzer-/Geräte-Affinität [5]. Damit lässt sich jedem Benutzer ein "Primäres Gerät" zuweisen. Wird eine Anwendung an diesen User im Modus "erforderlich" bereitgestellt und ist der Haken "Software vorab auf dem primären Gerät installieren" gesetzt, wird die Anwendung unabhängig von der Benutzer-Anmeldung installiert und steht bereits zur Verfügung, wenn der User sich anmeldet. Versehen Sie alle Bereitstellungstypen zusätzlich mit der Anforderung "Primäres Gerät = Wahr", ist die Installation dieser Anwendung auf die primären Geräte der berechtigten Nutzer begrenzt.
  • Eine andere Maßnahme, um der unkontrollierten Verbreitung von Applikationen durch Arbeitsplatzwechsel Einhalt zu gebieten, ist der Genehmigungsworkflow. Im Software-Center kann der Nutzer statt auf "Installieren" zunächst nur auf "Genehmigung anfordern" klicken. Die Genehmigung muss dann von einem SCCM-Anwendungsadministrator erteilt werden.
Bei den SCCM-Versionen bis einschließlich 1806 und den Long-Time-Releases war es für die Bereitstellung an Benutzer notwendig, dass der Softwarekatalog vollständig konfiguriert und über Clientrichtlinien im Software Center veröffentlicht wurde. Bei den späteren Versionen des Current-Branch-Kanals erscheinen die an Benutzer bereitgestellten Applikationen regulär im Software Center und der Softwarekatalog ist in der aktuellen Version 1910 gar nicht mehr enthalten.

Damit der Übergang vom Softwarekatalog zum Software Center reibungslos funktioniert, ist es notwendig, dass Sie den SCCM-Client auf allen Endgeräten möglichst zeitnah aktualisieren.

Im ersten Teil des Workshops gehen wir besonders auf die verschiedenen Arten der Anwendungsbereitstellung ein. In der zweiten Folge werfen wir einen Blick auf praktische Drittanbieter-Erweiterungen und erklären, warum das passende Applikationsdesign beim Ausrollen von Anwendungen wichtig ist. Im dritten Teil des Workshops schildern wir, wie sich auch komplexe Applikationen über ihren gesamten Lebenszyklus hinweg verwalten lassen.


dr/ln/Evgenij Smirnov

Ähnliche Beiträge

Im Test: Heimdal Patch & Asset Management

Ein zeitgemäßes Patchmanagement darf sich angesichts der vielfältigen Bedrohungen nicht allein auf die Microsoft-Produkte konzentrieren, sondern muss sich auch verbreiteten Drittanbieteranwendungen widmen. Der dänische Anbieter Heimdal Security geht noch einen Schritt weiter und hat eine ganze Suite zum Schutz vor Cyberbedrohungen im Programm. Mit dem Fokus auf das Patchen haben wir uns das cloudbasierte Angebot genauer angesehen.

Device-Management mit Microsoft Intune und Office 365 - Zwei Wege, ein Ziel

Um Geräte im Netzwerk oder mobile Geräte, die auf das Netzwerk zugreifen, zu verwalten, bietet sich für Unternehmen entweder Office 365 Mobile Device Management oder Microsoft Intune an. Ein Unterschied zwischen den beiden Lösungen besteht vor allem im Preis. Während das Device-Management zu vielen Abonnements in Office 365 gehört, muss Microsoft Intune gesondert abonniert werden. In diesem Beitrag stellen wir beide Ansätze vor.