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.
