SCCM vs DSM (Part 6 Paketierung mit DSM)

In den zwei vorherigen Blogs habe ich die “Paketierung” anhand einer MSI-basierten Anwendung verglichen. Auf das Thema Transforms bin ich noch nicht eingegangen. Die nächsten zwei Blogs sollen die Unterschiede der Paketierungsmöglichkeiten einer Anwendung mit einem herkömmlichen Setup (ohne MSI) beleuchten. Auch in diesem Fall gilt: Die Anforderungen an die Paketierung in beiden Umgebungen sind identisch. Dieses Mal sind die Unterschiede in der Umsetzung jedoch erheblich.  

Als Ausgangspunkt haben wir eine Exe-Datei auf einem Datenträger oder in unserem Fall lokal im Temp Verzeichnis. 

DSM bietet mehrere Möglichkeiten an, eine Legacy-Installation zu automatisieren. Hier haben wir eine Exe vorliegen, die Parameter für eine unbeaufsichtigte Installation unterstützt. Die einfachste Variante dies zu automatisieren ist, in der DSM Konsole innerhalb der Software-Library-Ansicht den Menüpunkt “Anwendungs-Paket erstellen | EXE Package” auszuwählen.

Daraufhin öffnet sich der EXE-Paket-Assistent und fragt zunächst nach dem Namen des neu zu erstellenden Pakets

In einer Vorlage könnten für ein Unternehmen hinterlegte Richtlinien, z.B. an die Dokumentation, voreingestellt werden.  

In diesem Fall verwende ich die Standardvorlage wie von DSM vorgegeben.  

Nach dem wir einen Namen für das Paket eingegeben haben, wechseln wir durch einen Klick auf ‘Weiter’ zur nächsten Assistentenseite.  

Der Assistent fragt nach dem Pfad zur EXE-Datei und bietet die Möglichkeit alle Dateien inkl. Unterverzeichnissen zu kopieren.  

Ferner können Parameter für die Befehlszeile, sowie ein Timeout angegeben werden. 

Die letzte Seite des Assistenten bietet die Möglichkeit eine zugehörige Deinstallation zu konfigurieren. 

Der Befehl soll mit dem Konto des Services durchgeführt werden und es soll maximal 3 Minuten auf das Ausführungsende gewartet werden.  

Nach einem letzten Klick auf ‘Weiter’ werden die für das Setup benötigten Dateien (in unserem Fall nur die Exe) in das im Hintergrund automatisch erstellte Projekt-Verzeichnis kopiert. Der Softwarepaketierer muss sich im Prinzip überhaupt keine Gedanken über die Infrastruktur machen. Er muss lediglich wissen, woher er die Software bekommt und welche Parameter benötigt werden.  

Damit ist der EXE-Paket-Assistent beendet und obwohl das erstellte Paket nun bereits verteilt werden könnte, öffnet sich zunächst die Packaging Workbench und bietet die Möglichkeit, das automatisch erstellte Skript komfortabel bearbeiten zu können.  

“Automatisch erstelltes Skript”

Als nächstes wollen wir Notepad++ noch konfigurieren. Falls keine Konfiguration von einer vorhergehenden Installation noch vorhanden ist, modifizieren wir diese mit Hilfe des ModifyXML Befehls. Ansonsten kopieren wir eine gesamte Konfiguration einfach als komplette Konfiguration runter.  

Das erste “Modify XML” ändert, dass „Remember last Session“ deaktiviert ist. 

“Modify XML 1”

Das zweite “Modify XML” deaktiviert automatische Updates. 

“Modify XML 2”

Des Weiteren können durch ein “Regload” vorgefertigte Änderungen in der Registry vorgenommen werden.  

Die Registry Änderung (in unserem Fall “Standard.nir”) kann in der Workbench unter dem Punkt Registry erstellt werden. Hier sorgt die Standard.nir dafür, dass Notepad++ als nach der Installation als Standard Editor verwendet wird.  

Nun kann eine Datei kopiert werden. Hierbei handelt es sich um ein Plugin für das Notepad++ Programm. Es wird das “Compare Plugin”, mit dem man zwei texte miteinander vergleichen kann, in das “Plugin” Verzeichniss kopiert.  

Außerdem kann ein Copy eingerichtet werden, dass eine vorgefertigte XML-Configdatei in das vorgesehen Verzeichnis kopiert. Dies ist notwendig, wenn diese Config nicht oder falsch erstellt wurde. Dafür kann man mit einer einfachen “IF Exist” Abfrage prüfen ob die config.xml vorhanden ist und davon abhängig der Vorgang bestimmen.  

Nach Anpassung des Installationspakets sieht das Script nun wie folgt aus: 

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.

 

SCCM vs DSM (Part 3 – globale Verfügbarkeit)

Wenn man mit Microsoft oder zumindest Microsoft Partnern im Zusammenhang mit Softwareverteilung streitet werden verschiedenste Gründe genannt die angeblich für SCCM sprechen. Ein solcher streitbarer Grund ist die angeblich bessere globale Verfügbarkeit.

Unbestritten ist Microsoft nicht nur größer, sondern auch umfassender und global besser aufgestellt als HeatSoftware. Das gilt sicherlich auch für das Partner-Ökosystem. Microsoft Partner gibt es in mehr Ländern als HeatSoftware Partner.

Allerdings ist nicht jeder Microsoft-Partner gleichzeitig ein SCCM Partner. Hingegen ist ein sehr großer Teil der HeatSoftware Partner auch Softwareverteilungsspezialist. Das bedeutet, dass wenn man schaut wo HeatSoftware Partner hat, dann weiß man in etwa wo es DSM Berater gibt. Das gleich kann über SCCM Consultants nicht gesagt werden.

Unternehmen die im Sinne der Softwareverteilung global agieren können vermutlich in zwei Kategorien einteilt werden.  Die, die alles zentral steuern und automatisieren und die, die dezentral agieren. Der Wunsch bzw. Bedarf an global verfügbaren Beratungshäusern dürften insbesondere in der zweiten Kategorie der Unternehmen vorhanden sein. Allerdings muss hier genauer hingeschaut werden. Welcher Bedarf liegt in diesen Fällen eigentlich vor? Geht es um einen Bedarf an Infrastrukturberatung oder geht es eher um Paketierungsunterstützung?

Weiterlesen

SCCM vs DSM (Part 2 – Zukunftssicherheit)

Vor Kurzem war ich in einem Kundenprojekt und man diskutierte über einen Wechsel von DSM zu SCCM. Obwohl die technische Ebene starke Bedenken äußerte wurde auf Wunsch der (neuen) IT-Leitung in einer Arbeitsgruppe über eine Woche über ein Für und Wider eines Umstiegs auf SCCM gesprochen.

Der Kunde setzt DSM bereits seit der Version 5.0 ein, automatisiert deutlich mehr als 15.000 Clients mit weit über 1.000 Projekten.

Obwohl man recht schnell eine Menge technischer Argument für DSM gefunden hatte gab es unzählige Diskussionsrunden und “Bestrebungen” eine Migration auf SCCM zu verargumentieren.

Eins dieser Argumente war “Zukunftssicherheit”.

Zitat “… wechseln wir auf SCCM oder gehen wir irgendwann mit DSM unter…”

Weiterlesen

SCCM vs DSM (Part 1 – Produktname)

In letzter Zeit drängt Microsoft mit SCCM  immer vehementer in den Software-Verteilungsmarkt hinein. Für mich als “NetInstall-er” der ersten Stunde ist SCCM ein alter Bekannter, der aber nie eine ernsthafte Konkurrenz darstellte. Das scheint sich in letzter Zeit etwas zu wandeln.

Um es vorab auf den Punkt zu bringen:

Das liegt weniger daran, dass der technische Abstand kleiner geworden ist, sondern viel mehr daran, dass die Entscheidungen immer weniger auf technischer sondern mehr auf “strategischer” Ebene getroffen werden.
Als jemand der bereits seit 1996 in der Softwareverteilung unterwegs ist habe ich mir nun vorgenommen eine Blog Serie mit dem Thema Vergleich von SCCM mit NetInstall / enteo / DSM (und sonstigen Wettbewerbern) zu starten.

Und somit kommen wir gleich zum ersten Teil dieser Blog-Serie.

Weiterlesen