Die Bereitstellung von GhostScript 9.15 ist sehr einfach, da es auf dem NSIS Installer basiert.
Die Installationsfiles können unter http://ghostscript.com/download/gsdnld.html heruntergeladen werden.

Die appDefinition.xml für die 32-bit Variante:

Anbei eine deutlich fehlerbereinigte und verbesserte Version der Automatic App Deployment Scripte.

Changelog:

0.1    – 2015-01-08

• erstes Alpharelease

0.2    – 2015-01-12

• Verbesserung der Ersetzungsfunktion im PS AppDeploy Handling

0.3    – 2015-01-25

•  interne Neustrukturierung

•  Parameterübergabe per Objekt

•  Doppelte Funktionen zusammengeführt

•  Besseres Handling von Paketen in x86 und x64 Format

•  Testgruppe kann angegeben werden, die zu der neuen Collection hinzugefügt wird (Include Collection)

•  Beide Module zu einem zusammengeführt

•  XML Format angepasst (Redundanzen entfernt)

Anbei eine leicht verbesserte Version der Automatic App Deployment Scripte. Folgendes habe ich geändert:

• ReplaceLine Funktion ausgetauscht, da die RegEx Replace Variante “$_” selber auswertet und ich keine Möglichkeit gefunden habe, dies abzuschalten

• Verbesserung der 32/64bit Erkennung bei NSIS Installern.

  automateAppDeployment (Version 0.3) (3226 downloads )

Auch wenn man viele Aufrufe automatisieren kann, so gibt es trotzdem Softwareinstallationen, die speziell angepasst werden müssen. Auch dies ist durch meine Powershellscripte abbildbar. Als ein Beispiel führe ich hier die Installation von Irfanview 4.38 (http://www.irfanview.com/main_download_engl.htm) auf.
Die Header in der EXE sind korrekt gefüllt, daher brauchen wir in der Info Sektion keine weiteren Angaben machen. Als Setuptype ist als Dummy InnoSetup hinterlegt. Die Angabe ist irrelevant, da wir alle drei Bereiche überschreiben:

Im letzten Post habe ich gezeigt, wie mit meinen Powershell Scripten ein einfaches MSI File bereitgestellt werden kann. Jetzt verteilen wir eine EXE, die mit NSIS paketiert ist.

Die VLC Version kann unter http://www.videolan.org/vlc/download-windows.html heruntergeladen werden und wird gemeinsam mit der appdefinition.xml in einen neuen Ordner abgelegt.
Leider sind im Header der Datei keine auswertbaren Informationen hinterlegt, daher werden die Angaben manuell im Block info eingetragen.

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:

Generell baue ich eine Configuration Manager Umgebung so auf, dass ich pro zu verteilender Software eine eigene Collection einrichte. Diese wird unterhalb eines Ordner _Software und darunter in einem Ordner mit dem Namen des Herstellers abgelegt. In diese Device Collection kommen dann die Clients, die die Software erhalten sollen.

So erhält man die maximale Flexibilität, auch wenn man am Anfang wahrscheinlich das meiste an die gleiche Gruppe von Clients verteilt.

Um diesen Ablauf zu vereinfachen, habe ich ein kleines Powershell Script geschrieben, dass die Ordner und die Collection entsprechend anlegt.

Der Aufruf erfolgt mittels:

Im Bereich Softwareverteilung gibt es mehrere Möglichkeiten eine Software auszuführen und zu verteilen:

• Im Deploymenttype im Bereich User Experience steht Installation behavior auf:
  • Install for System
  • Install for User
  • Install for system if resource is device; otherwise install for user
• Zielcollection ist vom Typ:
  • Device Collection
  • User Collection