ConfigMgr: Paketierung mit System Center Configuration Manager – Teil 1

In den nächsten Blogartikel möchte ich das Thema Paketierung mit System Center Configuration Manager 2012 R2 (ConfigMgr) genauer betrachten.

Folgende Aufteilung ist vorgesehen:

1. Artikel: Einleitung und Möglichkeiten der Paketierung
2. Artikel: Quellen für Silent Setup Parameter
3. Artikel: Erstellen von MSI Paketen
4. Artikel: Verteilung mit Powershell?

Sieht man von der integrierten App-V Verteilung ab, dann gibt es nur zwei wesentliche Verteilungsmöglichkeiten an Windows Clients im ConfigMgr:

• Verteilung eines MSI Paketes
• Verteilung eines Skriptes (können beliebige ausführbare Dateien sein)

Mitbewerber im Client Management bewerben ihr Produkt gerne damit, dass eine eigene Paketierungsskriptsprache enthalten ist, die (aus ihrer Sicht) im ConfigMgr negativerweise fehlt. Eine eigene Skriptsprache fehlt definitiv im ConfigMgr. Ich habe sie bis jetzt aber noch nie vermisst und sehe proprietäre Scriptsprachen eher als Mittel den Kunden an sein eigenes System zu binden an.

Wie gehen Kunden mit Paketierung mit dem System Center (SC) um?

Generell gibt es zwei Hauptansätze:

1. Vollständige Verwendung von MSI: Ist eine Software vom Hersteller nicht als MSI Paket bereitgestellt, so wird dieses mit einem entsprechenden Tool erstellt (“paketiert”)
2. Verwenden, was der Hersteller der Software bereitstellt: Gibt es die Software als MSI, dann wird diese verwendet, falls nicht, so wird das Setup im Silent Modus auf dem Client ausgeführt. Entsprechende Anpassungen werden automatisiert nach dem Setup oder durch Parameter durchgeführt.

Persönlich bevorzuge ich den zweiten Weg, kann aber auch die MSI Methode nachvollziehen.

Hier eine kurze Gegenüberstellung der Methoden:

Full-MSI:

Pro:

• MSI ermöglicht eine saubere Installation und werden von Windows nativ unterstützt
• MSI Pakete beinhalten automatisch eine Deinstallation
• Sie können sehr einfach in ConfigMgr eingebunden werden
• MSI Pakete ermöglichen eine Reparatur
• Ergebnisse sind in der Windowswelt universell einsetzbar, da so gut wie jede Verteilsoftware diese verwenden kann (inkl. GPOs…)
• MSI Pakete können sauber aktualisiert werden
• Paketierungssoftware kann über Pakete hinweg auf Konflikte hinweisen

Contra:

• Beim Repaketieren verliert man die Intelligenz des Herstellersetups
• Selbsterstellte MSI Pakete müssen aufwändig getestet werden, wenn eine gewachsene und inhomogene Umgebung vorliegt
• Hoher Aufwand beim Repaketieren
• Eventuell teure MSI Paketierungssoftware notwendig

Silent-Setups

Pro:

• Schnelle Erstellung von Paketen
• Nutzung der Intelligenz des Herstellers (der Hersteller installiert die Software auf tausenden von unterschiedlichen Systemen weltweit -> Optimale Testumgebung)
• Testaufwand bei heterogenen Systemen kann verringert werden
• Keine Zusatzsoftware notwendig
• Informationen aus dem Internet zu Silent Installationsparametern und anderen Tipps können direkt verwendet werden

Contra:

• Eigene Anpassungen sind aufwändiger (z.B. per nachgelagerter Batchdatei)
• Abhängig von Anpassungen und Setup steht u.U. kein sauberes Uninstall zur Verfügung
• Da Setup u.U. aus mehreren Teilen besteht, ist eine Wiederverwendung in anderen Systemen nicht so elegant möglich

Grundsätzlich stellt sich immer die Frage, ob umgebungsspezifische Anpassungen in das Paket eingebaut werden soll. Ich bin der Meinung, dass diese eigenen Anpassungen häufig im nachhinein geändert werden müssen (neues Logo der Firma, Feedback von den Benutzern usw.). Daher sollten diese aus dem Basispaket herausgehalten werden. Optimal wäre eine Bereitstellung per Gruppenrichtlinie.

Im nächsten Artikel werde ich genauer auf die Quellen für Silent Setup Parameter eingehen und Möglichkeiten der Anpassung beschreiben.