SCCM vs DSM (Part 5b – MSI Paketierung mit DSM)

Alexander Knopp

9

min Lesezeit

In diesem Blog schauen wir uns die Paketierung einer MSI-basierten Installation mit DSM an.

Inhaltsverzeichnis


Überblick

Der vorherige Blog befasste sich mit der „Paketierung“ einer MSI-basierten Anwendung mit SCCM. Die Anforderungen an die Paketierung in einer DSM Umgebung sind identisch, ein Teil der Umsetzung ist ähnlich. So gilt auch hier wieder: Ein Großteil der Aufwände in der Softwareverteilung liegt in der Paketierung. Liegt das Paket zur automatisierten Verteilung bereit, dann kann es – je nach Größe des Unternehmens – zunächst auf verschiedenen Verteilservern bereitgestellt werden. Anschließend wird es in der Regel in den Cache der Clients übertragen und schließlich von dort aus installiert.

Der Unterschied zwischen SCCM und DSM liegt im Wesentlichen in der Paketierung. In diesem Blog schauen wir uns die Paketierung einer MSI-basierten Installation mit DSM an. Als Ausgangspunkt haben wir wieder eine MSI Datei lokal im Temp Verzeichnis…

Um mit DSM eine MSI-basierte Installation automatisieren zu können öffnet man die DSM Konsole und wählt in der Software-Library Ansicht den Menüpunkt „Anwendung erstellen | MSI-Paket“.

MSI-Import-Assistent

Daraufhin öffnet sich der MSI-Import-Assistent und fragt nach dem Ort wo die MSI-Datei liegt.

Der Assistent bietet die Möglichkeit nach der MSI Datei zu suchen oder eine dedizierte auszuwählen. Lässt man die Datei suchen kann auch gleich nach Transforms (MST) oder Patchen (MSP) gesucht werden.

Anzumerken ist hierbei, dass man im Gegensatz zu SCCM den lokalen Speicherort – z.B. C:Temp, Downloads oder Datenträger angibt: Das Paket muss nicht vorher auf einem Share bereitgestellt werden.In meinem Fall sieht das wie folgt aus:

Somit sieht die erste ausgefüllte Seite des Assistenten wie folgt aus:

Hat man eine MSI Datei ausgewählt wird nach einem Klick auf „Weiter“ auf der folgenden Seite die Möglichkeit gegeben, eine Vorlage auszuwählen.

In einer Vorlage könnten für ein Unternehmen z.B. Richtlinien für die Dokumentation voreingestellt werden. In diesem Fall verwende ich die Standardvorlage wie von DSM vorgegeben.

Als nächstes wird gefragt wie die Quellen für die spätere Installation im Netzwerk bereitgestellt werden sollen.

Es besteht die Möglichkeit ein administratives Setup auszuführen, die Daten von der angegebenen Quelle zu verwenden oder die Dateien ins Paketverzeichnis kopieren zu lassen. Die erste und die dritte Option haben im Prinzip das gleiche Ergebnis, nämlich dass die Quelldateien im DSM-Server-Share bereitgestellt und damit später auf allen Depot-Servern zur Verfügung stehen. Ich wähle die untere Variante, damit entspricht das Ergebnis im Prinzip auch der SCCM Vorgehensweise.

Im Anschluss werden die Dateien auf den Share kopiert.

Der Share selbst muss weder ausgewählt noch in irgendeiner Weise vorbereitet werden. Dies erfolgt alles vollkommen automatisiert im Hintergrund.

Zuletzt gibt es noch die Möglichkeit die „Installationseinstellungen aufzuzeichnen“.

Dies ermöglicht eine sehr komfortable Möglichkeit passende MST Dateien zu erzeugen.

Da dies auch nachträglich gemacht werden kann beenden wir den Assistenten an dieser Stelle durch einen Klick auf „Fertigstellen“.

Damit ist der MSI-Import-Assistent beendet und das erstellte Paket könnte nun verteilt werden.
Im Vergleich zu SCCM ist hier allerdings nicht ein unveränderbarer Einzeiler „MsiExec /I …“ erstellt worden, sondern ein typisches DSM Paket.

Packaging Workbench

Dieses DSM Paket kann nun komfortabel mit der DSM PackagingWorkbench bearbeitet werden.

Als Beispiel dafür dient der folgende Screenshot.

Ohne hier in die Tiefe zu gehen, sieht man meines Erachtens allein schon mit der Betrachtung des Dialogs, welche Möglichkeiten in einfachster Weise zur Verfügung gestellt werden. Dieses Thema wird in einem der folgenden Artikel erläutert.

Fazit

Im Gegensatz zu SCCM wurde mit DSM nicht eine Anwendung und ein Deployment-Typ erstellt, sondern einfach ein DSM Projekt welches nun direkt auf den Clients ausgeführt werden könnte.
Man muss mit DSM auf dem Server im Vorfeld kein Verzeichnis erstellen und mit Daten befüllen, dies erfolgt mit DSM vollkommen automatisch. Die “Commandline” wurde im Prinzip wie bei SCCM automatisch erstellt. Es musste kein Deploymenttyp erstellt werden – DSM weiß schon selbst was es installiert hat?
Der aktuelle Blog soll zunächst einfach nur die Schritte zur Erstellung eines EXE-Pakets zeigen. Im Sinne eines Vergleichs zwischen der DSM Paketierung und SCCM Paketierung kann ich an dieser Stelle lediglich sagen, dass dies der “leistungsstärkste” Teil der Paketierung mit DSM ist.

In den folgenden Artikeln werde ich auf  die Paketierung eingehen. Das ist ein umfangreiches Thema. In diesem ersten Teil wurde ein Teil der Softwarebibliothek von SCCM mit der von DSM verglichen. Wie bereits eingangs erwähnt, hat dieser Blog zunächst die Gemeinsamkeiten gezeigt. Aus diesem Grund vergebe ich noch keine Punkte. Vielmehr wird im übernächsten Blog das Thema Softwarebibliothek / Verwaltung noch einmal tiefergehend beleuchtet und erst dann mit Punkten bewertet. Um dies nachvollziehbarer beschreiben zu können, werde ich aber zunächst noch einen Blog schreiben, der unter anderem versuchen wird, Gemeinsamkeiten zu zeigen, aber zwangsläufig bereits erste Unterschiede aufzeigen wird. So wird im nächsten Blog ein erstes MSI Paket in beiden Umgebungen hinzugefügt. Nachdem dies erfolgt ist, wird der zweite Teil zum Thema Softwarebibliothek erscheinen.

Hier finden Sie unsere Antworten

Ähnliche Beiträge

Softwareverwaltung optimieren nach der DSM Migration mit IDERI pace

Erfahren Sie, wie IDERI pace die Softwareverwaltung nach der DSM Migration in Sachen Sicherheit, Kontrolle und Effizienz optimiert.

Vielfältige Potenziale: Umzug von Ivanti DSM zu VMware Workspace One

Erhalten Sie alle Informationen zum Umzug von Ivanti DSM zu VMware Workspace One und die Potenziale dieser Softwaremigration.

DSM 7 – Dynamische Gruppen Automatisch befühlen + Option für die Manuelle zuordnung

Das Befüllen von dynamischen Gruppen, z.B. anhand des PC Namens ist in der Regel nicht sehr schwer und sollte leicht umzusetzen sein.

Server 2008 R2 Features und Rollen hinzufügen Script

Ein MS Server Betriebssystem mit DSM 7 auszurollen stellt kaum ein Problem dar.

DSM 7.2.1 released

Das Update beseitigt einige Fehler und bringt noch ein paar Neuerungen. Hier seinen mal nur ein paar genannt.

DSM 7.0.2 – Probleme beim Erstellen von Boot Environments

Als wir neulich bei einem Kunden waren, bei dem wir eine komplett neue Umgebung unter DSM 7.0.2 erstellen sollten, stießen wir auf erhebliche Probleme beim Vers

DSM 7.0 – Mehrere Policy-Ziele bereits beim „Paket zuweisen“

Seit DSM Version 7.1 kann man beim Zuweisen eines Pakets mehrere Policy-Ziele auswählen.

DSM 7 – Undokumentierte Scriptbefehle freischalten

In DSM7 gibt es einige Befehle mehr, als man in der Packaging Workbench sehen kann.

Durch Klicken auf „Alle Cookies akzeptieren“ stimmen Sie der Speicherung von Cookies auf Ihrem Gerät zu, um die Navigation auf der Website zu verbessern, die Nutzung der Website zu analysieren und unsere Marketingbemühungen zu unterstützen. Weitere Informationen finden Sie in unserer Datenschutzerklärung.