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.
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.
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.
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.
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.
