Um sich an das automateAppDeployment Toolkit heranzutasten, starte ich mit einer sehr einfachen Verteilung: Ein einzelnes MSI Files, das in den Eigenschaften vollständig beschrieben ist. Dazu verwende ich die aktuelle Beta 9.38 von 7-zip (http://www.7-zip.org).

Da alle Eigenschaften vorhanden sind, besteht die im vorhergehenden Post erwähnte appdefinition.xml Datei hauptsächlich aus dem Filenamen:

Gerade bei Standardsoftware ist die Paketierung und -bereitstellung sehr ermüdend und zeitraubend. Es gibt – wie in vorhergehenden Beiträgen bereits erwähnt –  gute Toolkits wie das PSAppDeployToolkit, um sich die Arbeit etwas zu vereinfachen. Dort herum habe ich ein paar Powershell Script als Proof of Concept gestrickt, die die Integration in den ConfigMgr vereinfachen sollen.

Das Script übernimmt folgende Funktionen:

• Kopieren des PSAppDeployToolkits in einen neuen Ordner nach dem Schema “Hersteller\Softwarename”
• Kopieren der Quelldateien in den “Files” Unterordner
• Eintragen der Headerangaben ui der Software in deploy-application.ps1
• Einfügen der korrekten Installations- und Deinstallationsbefehle in die Deploy-application.ps1
• Erstellen eines Ordners im Devicebereich mit dem Herstellernamen
• Erstellen einer Collection mit dem Softwarename und der Version
• Erstellen eines Ordners im Applicationbereichs mit dem Herstellernamen
• Erstellen einer Anwendung mit den Softwareangaben
• Hinzufügen eines Deployment-Types zu der Anwendung
• Eintragen des Installations- und Deinstallationsbefehlt in den Deployment-Type
• Hinterlegen der korrekten Detectionmethode zu der Anwendung
• Verteilen der Anwendung an eine definierten Distributionpoint Gruppe
• Bereitstellen der Anwendung an die oben angelegte Collection

Dadurch sind alle wesentlichen Schritte für eine Verteilung abgedeckt. Aktuell werden noch keine Abhängigkeiten (Supersedence) zwischen verschiedenen Softwareversionen abgebildet.

Möchte man per Powershell neue Applikationen im ConfigMgr erstellen, so ist dies mittels New-C;Mpplication und Add-CMDeploymentType relativ einfach machbar. Der passende TechNet Artikel (http://technet.microsoft.com/en-us/library/jj870953%28v=sc.20%29.aspx) listet alle verfügbaren Parameter auf. Microsoft hat leider versucht, mit einem Powershell Kommando alle möglichen Deployment Types abzudecken. Gerade im Bereich Scripted Installed (Manual Deployment Type) ist korrekte Zusammenstellung schwierig.

Nachfolgend wird daher ein Beispiel für eine Verteilung einer Anwendung (in diesem Fall aus dem Powershell App Deployment Toolkit), die im Hintergrund ein MSI File installiert. Die Anwendungserkennung soll auf Basis des MSI Produktcodes und der entsprechenden Version erfolgen. Es ist nach meinen Recherchen nicht möglich, per Powershell die eingebauten Detection-Methoden (MSI, File, Directory oder Registry-Werte) zu verwenden. Daher muss diese Funktion mittels einer Powershell Zeile nachgebaut werden.

Zuerst wird eine neue Application erstellt:

Wie in unserem Vierteiler Eingangs erwähnt, hat der System Center Configuration Manager (ConfigMgr) keine eigene Scriptsprache. Als  Ersatz dafür bietet sich Powershell an.

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?

Speziell das PowerShell App Deployment Toolkit (hier: PADT) bietet sich hier als idealen Wrapper an.

Anhand der Verteilung von Flash wird in diesem Artikel das Toolkit vorgestellt.

Flash 14 kann als MSI heruntergeladen werden. Bei der Installation im Rahmen einer zentralen Verteilung sollte die automatische Updatefunktion abgeschaltet werden. Dies kann durch die Anpassung der mms.cfg erfolgen. Ebenso sollte beim ActiveX Installer (nicht mehr notwendig für Windows 8 und höher) und beim Plugin für Firefox der jeweilige Browser geschlossen sein.

D.h. für unser Script werden folgende Punkte eingestellt:

Im dritten Teil werden die unterschiedlichen Möglichkeiten betrachtet, um ein MSI Paket zu erzeugen.

Eine kurz Übersicht über alle Teile:

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?

WiX Toolset

Eine kostenlose Möglichkeit, um eigene MSI Pakete zu erzeugen, ist das WiX Toolset (http://wixtoolset.org/). Dabei handelt es sich um Kommandozeilenprogramme, die speziell für die Integration in einen Build Prozess geschrieben wurden, d.h. nachdem die Anwendung in Visual Studio kompiliert wurde, könnte sie direkt in ein MSI Paket verpackt werden.

In Teil 1 wurden die Möglichkeiten der Softwarepaketierung im System Center Configuration Manager (ConfigMgr) betrachtet. Im zweiten Teil soll es nun um die Verwendung des Originalsetups gehen.

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?

Um das Originalsetup zu verwenden, ist es notwendig, dass die Installation ohne Interaktion des Benutzers durchgeführt werden kann. Es sind somit Silent-Parameter für das Setup notwendig.

Es gibt auf dem Markt nur wenige weit verbreitete Installationspakete:

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:

Hardwareinformationen für IT Asset im Service Manager (SCSM) können am Besten über den ConfigMgr importiert werden. Plug&Play Monitore werden bereits mit ein paar Informationen erkannt. Dabei fehlen Seriennummern und auch ein Produktcode des Monitors.

Dank EDID (extended display identification data) stehen diese Informationen am Client in der Registry bereit. Bereits seit längerem gibt es einen kleinen WMI Provider bei SourceForge (http://sourceforge.net/projects/wmimonitor/), der die Registryinformationen auswertet und als WMI Klassen bereitstellen. Seit ConfigMgr 2012 ist das Einbinden weiterer WMI Klassen in die Hardwareinventur denkbar einfach geworden.

Den Agent gibt es wie üblich in einer 32bit und 64bit Variante und liegt als MSI File vor. Er installiert einen Dienst “User Experience Virtualization service” mit dem internen Namen UevAgentService. Dieser Dienst agiert als Dateisystem Filtertreiber.

Eventlognachrichten landen Windows 7 typisch in ein eigenes Eventlog unter “Applications and Services Logs/Microsoft/User Experience Virtualization/Logging” in Admin und Operational.

Ein eigene Oberfläche hat der UE-V Agent (noch?) nicht. Die Steuerung erfolgt über WMI. Für die WMI Schnittstelle wird zusätzlich ein Powershell Modul installiert, dass über “Import-module Microsoft.UEV.commands” in eine Powershellsitzung importiert werden kann.

In seltenen Fällen kommt es noch vor, dass man eine alte Software auf einem aktuellen Windows 7 installieren muss. Damals haben die Entwickler nicht mit einem neuen Betriebssystem gerechnet oder erwartet, dass man rechtzeitig neue Lizenzen kauft. Teilweise hängt an der Client Software entsprechende Backend-Systeme, die nicht so einfach aktualisierbar sind.