Über Alexander Knopp

Follow @knoppalexander

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 5b – MSI Paketierung mit DSM)

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…

Weiterlesen

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

Im vorherigen Blog haben wir einen ersten Überblick über die Softwarebibliothek von SCCM und DSM erhalten. Soweit schienen die beiden Lösungen einen nahezu identischen Ansatz zu verfolgen. In diesem Blog werden wir eine erste Anwendung in die Softwarebibliothek hinzufügen.

Ein Großteil der Aufwände in der Softwareverteilung liegt in der Paketierung. Steht das Paket zur automatisierten Verteilung bereit, dann kann es – je nach Größe des Unternehmens – zunächst auf mehreren Verteilservern bereitgestellt werden. Anschließend wird es in den Cache der Clients übertragen und schließlich von dort aus installiert.

Je nach dem in welcher Form eine Anwendung vom Hersteller zur Installation bereitgestellt wird, sind die notwendigen Schritte unterschiedlich. In diesem Blog betrachten wir die Vorgehensweise im Fall einer MSI-basierten Installation.

 

Als Ausgangspunkt haben wir eine MSI Datei auf einem Datenträger oder lokal im Temp Verzeichnis…

Weiterlesen

SCCM vs DSM (Part 4a – Softwarebibliothek)

Wie bereits angekündigt behandelt dieser Blog das Thema Paketierung.

Aus meiner Sicht sind die Unterschiede zwischen SCCM und DSM bei diesem Thema am größten. Darüberhinaus sind sie so wesentlich, dass ich diesem Thema mehrere einzelne Blogs mit jeweils unterschiedlichen Schwerpunkten widmen werde.

Dennoch möchte ich diese Teilserie mit den Gemeinsamkeiten beginnen.

Macht man sich zu dem Thema Softwareverteilung genauere Gedanken wird man schnell dazu kommen, dass man einen Überblick über folgende Dinge benötigt:

  • welche Software hat man bzw. will man verteilen
  • welche Benutzer und Computer sind in der Umgebung vorhanden
  • Welche Benutzer bzw. Computer sollen welche Software (in welcher Version, Konfiguration, Edition) erhalten
  • Wie sieht die Infrastruktur (Standorte, Server, Netzwerkverbindungen, usw.) aus

Beide Lösungen decken alle eben genannten Themen ab. In Teilen tun sie dies sogar in einer ähnlichen Art und Weiße.

Im Folgenden betrachten wir den ersten Punkt:

Verwaltung der zu verteilenden Anwendungen

Weiterlesen

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

Von Software-Sets und (un-)kritischen Änderungen

Jeder, der sich selbst realistisch einschätzt wird wohl zugeben, dass ihm auch schon mal ein Fehler beim Paketieren passiert ist. Was macht man in so einem Fall? Je nach Schweregrad des Fehler kann ein neues Paket erstellt oder auch das bestehende Paket modifiziert werden.

Für Modifikationen an bestehenden Paketen bietet DSM die Möglichkeit der Revisionierung an. Obwohl die Revision X eines Paketes aktiviert ist kann es in der Revision X+1 bearbeitet und getestet werden. Ist die Bearbeitung und das Testen erfolgreich beendet so kann die korrigierte Revision für die Verteilung freigegeben werden.

Um die neue Revision des Paketes für die Verteilung zu aktivieren muss die bestehende Policy aktualisiert werden. Hier kann man entscheiden, ob die neue Revision nur auf PCs zum tragen kommt auf denen das Paket noch nicht installiert wurde (unkritische Änderung) oder auf allen Computern mit der gewünschten Zuweisung erneut ausgerollt wird, d.h. auch auf den PCs, auf denen bereits eine vorherige Revision installiert wurde (kritische Änderung).

Für Einzel-Zuweisungen ist diese Entscheidung relativ leicht zu treffen. Wie behandelt man die Thematik jedoch im Fall von Software-Sets?

Kritisch oder unkritisch – das ist die Frage

Bei Änderungen an Paketen Weiterlesen

Was ist eigentlich Office 365?

Als ich zum ersten Mal von Office 365 hörte, dachte ich, dass wären über den Web-Browser zur Verfügung gestellte Office-Produkte.

Das stimmt aber nur bedingt.

Primär ist Office 365 eine Cloud Lösung für die „Office-Infrastruktur“.

Office365 stellt einzelnen Personen oder Unternehmen die Funktionalität eines Exchange-, eines SharePoint und eines Lync-Servers zur Verfügung.

Im Optimalfall bedeutet das für ein Unternehmen, dass es folgende Komponenten einsparen kann:

  • Hardware für die entsprechenden Server
  • Lizenzkosten für die Server
  • Antiviren und Spam-Schutz Server
  • USVs
  • Backups

Hinzu kommen noch Themen, wie das Einspielen von Updates, neuen Versionen usw. Weiterlesen

Alternative zur E-Mail Kommunikation

In den neunziger Jahren sorgte die E-Mail für einen revolutionären Effizienzschub der Kommunikation in Unternehmen. Ursprünglich wurden E-Mails schwerpunktmäßig als elektronische Briefe eingesetzt, mit der Zeit werden sie unter anderem auch stark für Kurznachrichten und andere Einsatzzwecke verwendet. Nach einer Untersuchung der Universität Cardiff benötigt ein Mensch nach einer Unterbrechung von 5 Sekunden für das Lesen einer E-Mail im Schnitt 64 Sekunden, bis er sich wieder voll auf die unterbrochene Aufgabe konzentrieren kann.

E-Mails sind Meister der Ablenkung

Thomas Jackson, Wissenschaftler an der britischen Universität in Loughborough, hat genau diese Auswirkungen auf das Arbeitsleben untersucht. Ergebnis: Mitarbeiter benötigen im Schnitt 64 Sekunden, um nach dem Lesen einer Mail wieder zurück zur Arbeit zu finden.

Quelle: Die-Welt – Deutsche Firmen entdecken Alternative zur E-Mail (Link)

Junk

Aus diesem Grund verwenden heute immer mehr Unternehmen Facebook, Instant Messenger, SMS, usw. Diese Kommunikationsformen sind hilfreich, wenn es um schnellen Nachrichtenaustausch zwischen verschiedenen Personen geht. Es gibt jedoch weitere Anwendungsgebiete die durch diese Kommunikationsmittel nicht unterstützt werden.

Zeitliche Begrenzung

Oftmals sind Information nur zeitlich begrenzt nützlich. Sind zum Beispiel Wartungsarbeiten an Systemen vorgesehen, dann wird oft eine E-Mail mit einem Weiterlesen