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.

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:

• Flexera Software InstallShield: Der Standard für kommerzielle Software speziell bei größeren Paketen. Im Allgemeinen ist InstallShield ein Wrapper um ein MSI Paket, so daß auch häufig direkt die MSI Datei verwendet werden kann
• Nullsoft Scriptable Install System (NSIS): Ursprünglich u.a. entwickelt um WinAMP zu paketieren, ist die Skriptsprache zur Erstellung von Installationspaketen mittlerweile Open Source und gerade im Freeware Bereich weit verbreitet.
• Inno Setup: Ebenfalls ein sehr verbreitetes Tool, um Software zu paketieren.

Im Allgemeinen kann man, wenn man nur eine EXE Datei vorliegen hat, mit sehr hoher Wahrscheinlichkeit davon ausgehen, dass es sich entweder um ein NSIS oder ein Inno Setup Paket handelt. Beide Pakete verwenden einen Kompressionsmechanismus. Ein erster Schritt sollte es somit sein, die Datei als Archive in 7Zip zu öffnen und zu kontrollieren, welche Unterordner vorhanden sind.

Ein Unterverzeichnis mit $PLUGINSDIR ist ein Hinweis für ein NSIS Installer Programm. In diesem Ordner werden Erweiterungen für das Setup hinterlegt.

Alternativ kann man die üblichen Parameter für Silent Setup ausprobieren:

Parameter für Inno Setup:

/VERYSILENT /NOCANCEL /NORESTART /SUPPRESSMSGBOXES /SP- /LOG="%systemroot%\programmname.log"

Parameter für NSIS (Achtung! Case Sensitive!):

/S

Ein Silentsetup bedeutet aber noch nicht, dass das Setup die Installation so durchführt, wie es in der Umgebung erwünscht ist. Dies bezieht sich z. B. darauf, welche Komponenten installiert und wo diese abgelegt werden.

Was möglich ist, ist vom Ersteller des Paketes abhängig. Daraus ergibt sich folgende Informationsquellen:

• FAQ Webseite oder der Support des Herstellers
• IT Ninja: die alte Seite appdeploy.com hatte sehr gute Tipps zur Installation und Anpassung von vielen Paketen. Die Informationen sind immer noch vorhanden, aber meiner Meinung nach deutlich unübersichtlicher. Trotzdem aus meiner Sicht immer noch eine gute Informationsquelle
• WPKG: Eine Open Source softwareverteilungslösung, die netterweise ein Wiki bereithält, in dem eigene XML Beschreibungssprache, die soweit selbsterklärend ist, dass sie als Quelle für die Parameter herhalten kann
• Nach dem Programmname mit silent Parameter auf Bing googlen.

Einige typischen Fragen zu System Center Update Publisher (SCUP) und Update Services in System Center Configuration Manager (ConfigMgr). Das Produkt gibt es schon länger, aber trotzdem tauchen immer wieder Fragen auf.

Wofür gibt es den SCUP?

Der System Center Update Publisher ermöglicht es, dass Nicht-Microsoft Updates über den WSUS und somit den ConfigMgr verteilt werden können. Diese Updates sind in der WSUS Konsole im Normalfall nicht sichtbar und sollten über den ConfigMgr verwaltet werden.

Welche Updatekataloge gibt es?

Updatekataloge werden von bestimmten Herstellern angeboten und ermöglichen es schnell bestimmte Fremdprodukte zu patchen. Darunter fallen:

Direkt in der Oberfläche integrierbar:

• Adobe für Flash, Acrobat Reader und Acrobat
• HP Proliant mit Firmware Update Paketen und Treiber Update Paketen
• HP Clients mit diversen Treibern, Firmware und sonstiger Software zu HP Workstations und Notebooks
• Dell Server und Dell Clients

Drittanbieter bieten eigene kostenpflichtige Kataloge für weitere Software an.

Wo findet man die aktuelle Version des SCUP?

Die aktuellste Version ist SCUP 2011. Sie kann von Microsoft unter http://www.microsoft.com/en-us/download/details.aspx?id=11940 heruntergeladen werden.

Die Software sollte grundsätzlich mit Administratorrechten ausgeführt werden!

Welche Voraussetzungen müssen erfüllt sein?

Damit ein Client ein Nicht-Microsoft Update installiert, muss er diesem vertrauen. Der Windows Update Dienst vertraut grundsätzlich erst einmal nur Update, die von Microsoft signiert wurden.

Daher sind folgende Anpassungen notwendig:

1. Im SCUP muss in den Optionen ein Zertifikat hinterlegt bzw. generiert werden.
2. Der Public Key des Zertifikats muss exportiert werden und z.B. per Gruppenrichtlinie in den Trusted Publishern und (im Fall eines selbstsignierten Zertifikats) in die Trusted Root Certificates aufgenommen werden
3. Per Gruppenrichlinie müssen Intranet Updates erlaubt werden:  “Allow signed updates from an intranet Microsoft update service location” unter “Computer Configuration -> Policies -> Administrative Templates -> Windows Components -> Windows Update”

Ich erhalte die Fehlermeldung 0x800b0109 im WindowsUpdate.log

Updates wurden erfolgreich im ConfigMgr integriert und an die Clients verteilt. Eine Installation schlägt aber fehl. Im Windows Update Log ist folgende Meldung zu sehen:

WARNING: Digital Signatures on file C:\Windows\SoftwareDistribution\Download\e159f74f5d0131816acee05d4d39b19392fb9bea are not trusted: Error 0x800b0109

Dies ist ein eindeutiger Hinweis, dass die Voraussetzungen nicht erfüllt wurden, da das Update zwar heruntergeladen wurde, aber nicht überprüft werden kann.

Bitte folgende Punkte auf dem Client überprüfen:

• Befindet sich das WSUS Zertifikat in den Trusted Publishern UND in den Trusted Root Store (falls es ein selbstsigniertes Zertifikat ist)
• Wenn das Zertifikat auf dem Client geöffnet wird, ist es dann vertrauenswürdig?
• Wurden die Intranet Update per Gruppenrichtlinie erlaubt? D.h. ist folgender Key in der Registry vorhanden und auf 1 gesetzt:

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate]

“AcceptTrustedPublisherCerts”=dword:00000001

Ist alles korrekt eingestellt, so sieht das Windows Update Log folgendermaßen aus:

2014-05-12         11:37:54:156      1576      14bc      Misc      Validating signature for C:\Windows\SoftwareDistribution\Download\e159f74f5d0131816acee05d4d39b19392fb9bea with dwProvFlags 0x00000080:

2014-05-12         11:37:56:471      1576      14bc      Misc      Microsoft signed: No

2014-05-12         11:37:56:472      1576      14bc      Misc      Trusted Publisher: Yes

Verteilung von HP Firmware und HP Treiber funktioniert nicht

Die Erkennung, ob ein Firmware- oder Treiberpaket notwendig ist, ist von HP relativ rudimentär umgesetzt. Dabei wird nur überprüft, ob ein Datumsstempel in der Registry kleiner als ein Wert im Paket ist. Wurde somit der Server nicht schon Initial mit einem Firmwarepaket installiert, so fehlt dieser Registry Wert und die Software wird nie angeboten.

Um dies zu umgehen, kann man über einen beliebigen Weg (GPO, Softwareverteilung, usw.) folgende Registry Keys auf dem Server hinterlegen:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Hewlett-Packard\PUCBundles]

“proliantfw”=”2011.02.0.5″

“ws2012r2-x64″=”2011.02.0.5″

Dies setzt die beiden Schlüssel auf einem Windows 2012 R2 Server auf einen alten Datumswert zurück (aktuell ist 01-2014). Beim nächsten Patchscan wird die Software dann angeboten.

Verwendet man im ConfigMgr die MDT Tasksequenzen zur Verteilung von Betriebssystemen, so verhält man neben den anderen Verbesserungen auch zusätzliche Validierungsschritte.

Diese Schritte sorgen z.B. dafür, dass eine fehlerhaft verteilte Clientinstallation nicht auch die Server betrifft wie es z.B. an der Emory University vor kurzem passiert ist.

Gleichzeitig kann der Fehler ebenfalls auftreten, wenn man ein Server neu installieren will und dabei vergisst, das die Task Sequenz noch auf Clients eingestellt ist.

die Task Sequenz bricht dann sehr schnell mit einem Fehler 9801 ab. Im smsts.log kann man dann folgende Zeilen nachlesen:

<![LOG[TargetOS is the current SystemDrive]LOG]!><time=”18:11:10.191-60″ date=”03-04-2014″ component=”InstallSoftware” context=”” type=”1″ thread=”6240″ file=”runcommandline.cpp:34″>

<![LOG[ERROR - Attempting to deploy a client operating system to a machine running a server operating system.]LOG]!><time=”18:11:10.191-60″ date=”03-04-2014″ component=”InstallSoftware” context=”” type=”1″ thread=”6240″ file=”runcommandline.cpp:34″>

<![LOG[FAILURE ( 9801 ): ERROR - Attempting to deploy a client operating system to a machine running a server operating system.]LOG]!><time=”18:11:10.191-60″ date=”03-04-2014″ component=”InstallSoftware” context=”” type=”1″ thread=”6240″ file=”runcommandline.cpp:34″>

<![LOG[Command line returned 9801]LOG]!><time=”18:11:10.191-60″ date=”03-04-2014″ component=”InstallSoftware” context=”” type=”1″ thread=”6240″ file=”runcommandline.cpp:565″>

<![LOG[Process completed with exit code 9801]LOG]!><time=”18:11:10.197-60″ date=”03-04-2014″ component=”TSManager” context=”” type=”1″ thread=”7612″ file=”commandline.cpp:1123″>

Die Meldung ist eindeutig und kann in der Task Sequenz entsprechend umgestellt werden:

ln der Pre-Phase bei neuen Computern (d.h. Tasksequenz wurde über einen USB-Stick/CD-Rom oder über PXE gestartet) existiert der entsprechende Validierungschritt:

Hier kann man die Überprüfung des Betriebssystems komplett abschalten (nicht empfohlen) oder dem jeweiligem Zielsystem entsprechend anpassen.

Auch für das Update von bestehenden Systemen (Deployment der Task Sequenz) existiert an späterer Stelle ein entsprechender Task, der angepasst werden muss:

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.

Natürlich hindert niemand einen daran, die Software auch außerhalb eines Build Prozesses einzusetzen. Im Gegensatz zu grafischen Tools, muss hier ein XML File manuell erzeugt werden.

Ein Auszug aus dem Tutorial (http://wix.tramontana.co.hu/tutorial/getting-started) sieht so aus:

[...]
    <Directory Id='TARGETDIR' Name='SourceDir'>
      <Directory Id='ProgramFilesFolder' Name='PFiles'>
        <Directory Id='Acme' Name='Acme'>
          <Directory Id='INSTALLDIR' Name='Foobar 1.0'>

            <Component Id='MainExecutable' Guid='YOURGUID-83F1-4F22-985B-FDB3C8ABD471'>
              <File Id='FoobarEXE' Name='FoobarAppl10.exe' DiskId='1' Source='FoobarAppl10.exe' KeyPath='yes'>
                <Shortcut Id="startmenuFoobar10" Directory="ProgramMenuDir" Name="Foobar 1.0" WorkingDirectory='INSTALLDIR' Icon="Foobar10.exe" IconIndex="0" Advertise="yes" />
                <Shortcut Id="desktopFoobar10" Directory="DesktopFolder" Name="Foobar 1.0" WorkingDirectory='INSTALLDIR' Icon="Foobar10.exe" IconIndex="0" Advertise="yes" />
              </File>
            </Component>
[...]

Dabei wird die Directorystruktur definiert und ein Datei namens foobarAppl10.exe abgelegt. Gleichzeitig werden Verknüpfungen im Startmenü und auf dem Desktop definiert.

Hangelt man sich an diesen Beispielen entlang, so kann man schnell einfache Software in MSI Pakete integrieren.

MSI Wrapper 5

Hat man bereits ein fertiges Setup und möchte es nur in ein MSI Paket verpacken, so kann man zu dem kostenlosen MSI Wrapper (http://www.exemsi.com/) greifen. Möchte man auf einen Kommentar im Uninstall Eintrag verzichten oder auch diesen in einen Buildprozess integrieren, so steht auch eine Professionelle (und kostenpflichtige) Version zur Verfügung.

Es werden in der Online Dokumentation bereits die Parameter für Inno Setup und NSIS aufgeführt (http://www.exemsi.com/documentation/installer-frameworks). Das kostenlose Programm ist Wizard gesteuert und einfach zu bedienen. Bei der richtigen Verwendung können sogar alte MSI Wrapper Installationen durch neuere Version upgegradet werden.

Problematisch ist diese Vorgehensweise wenn in der zu wrappenden EXE MSI Pakte versteckt sind, da der Wrapper im Prinzip die EXE entpackt und mit Silent-Paremtern ausführt. Wenn diese EXE erneut ein MSI Paket installieren will, läuft bereits im äußeren Installer eine MSI Installation und es kommt zu einer entsprechenden Fehlermeldung.

Flexera InstallShield

Das am meisten eingesetzte kommerzielle Programm zum Erstellen von MSI Paketen ist aus meiner Sicht Flexera InstallShield. Zu finden ist diese Software unter http://www.flexerasoftware.com/products/software-installation/installshield-software-installer/.

Caphyon Advanced Installer

Als etwas kostengünstigere kostenpflichtige Variante bietet sich der Advanced Installer von Caphyon (http://www.advancedinstaller.com/) an.

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:

• Benachrichtigung des Benutzers, dass Firefox geschlossen werden muss
• Möglichkeit, dass der Benutzer die Installation verzögern kann
• Installation eines MSI Files mit Parametern
• Kopieren eines mms.cfg Files in das entsprechende Verzeichnis unter Windows

Die Ordnerstruktur beim PADT ist immer gleich:

Im Ordner AppDeployToolkit brauchen keine Powershelldateien geändert werden, da er Hilfsdateien für das Toolkit enthält. trotzdem kann es Sinn machen, die AppDeployToolkitConfig.xml anzupassen. Sie enthält Hinweistexte in diversen Sprachen, die an eigene Bedürfnisse angepasst werden können. Ebenso können die PNG und die ICO Datei durch eigene Logos ausgetauscht werden.

In den Ordner Files kommen unsere heruntergeladene “install_flash_player_14_plugin.msi” Datei. Unter SupportFiles wird unsere angepasste mms.cfg abgelegt.

Für die eigentliche Verteilung muss nur die Deploy-Application.ps1 angepasst werden.

Darin sollte zuerst der Variablenblock angepasst werden:


$appVendor = "Adobe"
$appName = "Flash Player - Firefox Plugin"
$appVersion = "14.0.0.125"
$appArch = ""
$appLang = "DE"
$appRevision = "01"
$appScriptVersion = "1.0.0"
$appScriptDate = "07/06/2014"
$appScriptAuthor = "Markus Baeker"


Danach werden die einzelnen Installationsblöcke angepasst:

• Pre-Installation: Hinweise und Checks vor der eigentlichen Installation
• Installation: Schritte für die eigentliche Installation
• Post-Installation: z.B. Benachrichtigung, dass die Installation erfolgreich war
• Uninstall: Was muss zur Deinstallation alles aufgeräumt werden.

Für unser einfaches Bespiel führen wir folgendes durch:

Pre-Installation

In der Pre-Installation Phase werden wir den Benutzer auf die Installation hinweisen und ihn bitten, Firefox zu schließen. Zusätzlich wird der verfügbare Speicherplatz überprüft:

Show-InstallationWelcome -CloseApps "firefox" -AllowDefer -DeferTimes 3 -CheckDiskSpace -PersistPrompt -BlockExecution -RequiredDiskSpace 10

• AllowDefer und DeferTimes: ermöglicht dem Benutzer bis zu drei Mal die Installation zu verschieben. Der Wiederholzeitpunkt hängt beim ConfigMgr 2012 Application Model von der Client Einstellung “Software deployment\schedule re-evaluation for deployments” ab.
• CheckDiskSpace und RequiredDiskSpace: überprüft, ob für die Installation genügend (hier 10MB) Platz verfügbar ist. Wird RequiredDiskSpace nicht angegeben, so ermittelt das Script den notwendigen Plattenplatz anhand der Größe des Quellordners
• PersistPrompt: Der Dialog wird in der Mitte des Bildschirms gehalten, so dass der Benutzer sich für eine Option entscheiden muss
• BlockExecution: während der Installation wird ein Starten von Firefox verhindert

Installation

Die Hauptarbeit erfolgt im Installationsabschnitt. Hier werden folgende Einstellungen durchgeführt:

# Perform installation tasks here
Execute-MSI -Action Install -Path "install_flash_player_14_plugin.msi"

#Copy MMS
Copy-File -Path "$dirSupportFiles\mms.cfg" -Destination "$envWindir\SysWOW64\Macromed\Flash\mms.cfg"

#stop update service if running...
Get-Service AdobeFlashPlayerUpdateSvc | Stop-Service

#disable service
Get-Service AdobeFlashPlayerUpdateSvc | Set-Service -StartupType Disabled

Anmerkung dazu:

• Execute-MSI: das MSI File wird automatisch im Ordner Files gesucht und ausgeführt. Es werden keine eigenen Parameter übergeben, sondern die Defaultparameter aus AppDeployToolkitConfig.xml genutzt.
• Zusätzlich wird per Copy-File die angepasste mms.cfg kopiert. (Achtung: Zur Vereinfachung des Beispiels wird davon ausgegangen, dass das Script auf einem x64 System ausgeführt wird, da statisch nach SysWOW64 kopiert wird.)
• Der Flash Update Service wird angehalten (Standard Powershell Befehl)
• Der Flash Update Service wird deaktiviert.

Die mms.cfg sieht in diesem Beispiel so aus:

LocalStorageLimit = 1
AssetCacheSize = 0
ThirdPartyStorage = 0
AssetCacheSize = 0
AutoUpdateInterval = 1
AutoUpdateDisable = 1
DisableProductDownload = 1
SilentAutoUpdateEnable = 0
LegacyDomainMatching = 0
LocalFileLegacyAction = 0


Post-Installation

Die Post-Installation Phase wird leergelassen, da wie erfolgreiche Installation über die Sprechblase angezeigt wird.

Uninstallation

Für die Deinstallation wird wie folgt angepasst:

# Show Welcome Message, close Internet Explorer if required with a 60 second countdown before automatically closing
Show-InstallationWelcome -CloseApps "firefox" -CloseAppsCountdown "60"

# Show Progress Message (with the default message)
Show-InstallationProgress

# Perform uninstallation tasks here
Execute-MSI -Action Uninstall -Path "install_flash_player_14_plugin.msi"

Aufruf

Die Einbindung in den ConfigMgr wird in der beiliegenden Dokumentation (PSAppDeploymentToolkitAdminGuide.docx) genauer beschrieben.

Hier nur zwei Aufrufe:

• Deploy-Application.EXE: Ohne Parameter wird standardmäßig die Installation im Interaktiven Modus durchgeführt
• Deploy-Application.EXE -DeploymentType Uninstall: Deinstallation im Interaktiven Modus
• Deploy-Application.EXE -DeploymentType Uninstall -DeployMode Silent: Deinstallation im Silent Modus, dies bedeutet auch, dass die angegebenen Programme ohne Rückfrage geschlossen werden!

Aktuell wird auf Connect die Beta des System Center 2012 Configuration Manager Servicing Extension angeboten:

http://go.microsoft.com/fwlink/?LinkId=398485

Diese Erweiterung für die ConfigMgr Konsole klingt sich in die Konsole unter Administration\Overview als Site Servicing Blatt ein. Sie muss somit nicht auf dem Site Server installiert werden (im Gegensatz zu InTune Erweiterungen).

Ziel der Software ist es auf neue Produktversionen (Cumulative Updates, Service Packs u.ä.) hinzuweisen. Zusätzlich werden auf der Einstiegsseite die aktuellen Blogposts vom ConfigMgr Team und dem ConfigMgr Support Team eingeblendet:

Die Informationen werden dabei im Kontext der Konsole (also auf dem Rechner, auf dem die Konsole gestartet wird) beim Zugriff auf den Bereich aus dem Internet heruntergeladen. Dabei wird ein CAB Datei geholt, in der aktuell drei XML Dateien vorhanden:

• CurrentExtension.xml: Hinweis auf die aktuellste Version der Extension inkl. eines Downloadlinks
• RssFeeds.xml: Liste mit den beiden ausgewerteten RSS Feeds
• Updates.xml: Liste aller verfügbarer ConfigMgr Updates

Die Datei ist unter folgendem Link zu finden: http://go.microsoft.com/fwlink/?LinkId=386333

Klappt man den Bereich auf, so gibt es folgende weitere Möglichkeiten:

• Site Updates
• Site Versions:
• Client Targeting
• Blogs

Site Updates

Site Updates listet die Verfügbaren Updates und Hotfixe genauer auf. Dabei lässt sich auch der Filter entsprechend anpassen, dass auch ältere (anstatt der aktuell installierten) Versionen dargestellt werden können:

Natürlich gibt es jeweils den direkten Link zum Download des Updates.

Site Version

Existieren mehrere Sites in der Hierarchie, so werden hier die Versionen aller angeschlossener Sites angezeigt.

Client Targeting

Updates der Site bedeuten im Allgemeinen auch, dass die Clients aktualisiert werden. Verwendet man hierbei nicht den von mir bevorzugten Weg über den SCUP, so benötigt man dynamische Queries, die Clients beinhaltet, die noch nicht aktualisiert wurden. Dazu kann man unter Client Targeting eine gewünschte Zielversion aussuchen und erhalt dann die Auswahl, ob man eine Query mit allen Clients unterhalb dieser Version oder gleich bzw. über dieser Version haben möchte:

Die Query landet dann unter Monitoring\Overview\Queries und kann in einer Collection unter Membership Rules -> Query Rules -> Import Query Statement übernommen werden:

Zukünftig sollen hier u.U. auch weitere nützliche Abfragen hinterlegt werden.

Blogs

Hier werden die aktuellen Blog Einträge auf den oben genannten Seiten angezeigt. Dabei können Einträge als gelesen markiert werden, so dass man eine schnelle Übersicht über neue Einträge erhält.

Die meisten werden diese Blogs bereits in ihrem RSS Reader hinterlegt haben, so dass der Zusatznutzen dieser Liste eher begrenzt ist.

Fazit

Insgesamt eine nette kleine Erweiterung, die einem den Überblick über neue Updates im ConfigMgr Bereich vereinfacht und gerade bei größeren Installationen einen schnellen Einblick in die installierten Versionen liefert.

Ein wesentlicher Bestandteil vom System Center Configuration Manager 2012 R2 (ConfigMgr) ist die Software Update Verteilung. Sie basiert im Hintergrund auf den Updatedefinitionen von WSUS, aber erweitert die Steuerung und Anpassbarkeit extrem.

Daraus ergibt sich zwangsweise, dass viele von den Möglichkeiten zuerst überrascht sind und sich zum einfachen Konzept des WSUS zurücksehnen.

Daher sollen in diesem Blogpost und in nachfolgenden Post verschiedene Strategien zur Softwareupdateverteilung vorgestellt werden.

Seit ConfigMgr 2012 gibt es die Automatic Deployment Rules, die vom Aufwand wieder an die Einfachheit des WSUS herankommen.

Daher kann man die Strategien auf zwei Achsen anordnen:

• Flexibilität: Wie stark kann ich die zu verteilenden Updates filtern und testen.
• Aufwand: Wie viele Schritt müssen bis zur Verteilung getan werden.

Strategie 1: Verteilung WSUS-like

Die erste Strategie setze ich bei vielen Mittelstandskunden um. Bei ihnen ist der ConfigMgr nur eines der vielen Produkte, die täglich betreut werden müssen. Daher ist das oberste Ziel, dass der Aufwand minimiert wird.

Daher wird hier stark auf die Automatic Deployment Rules gesetzt. Dazu gibt es zwei Collections:

• Test Clients: Eine Auswahl von repräsentativen Clients, die die Updates sofort bekommen.
• Produktive Clients: Alle anderen Clients, die die Updates verzögert bekommen.

Die Automatic Deployment Rule (Software Library\Overview\Software Updates) der Test Clients hat als Besonderheit, das beim automatischen Überprüfen keine neue Software Update Gruppe angelegt wird. Die Software Update Gruppe steuert unter anderem, wann ein Update installiert wird (optional oder erzwungen). Da die Updates hier sofort installiert werden sollen, reicht uns eine Gruppe.

Als Auswahlregeln kann die nachfolgende Einstellung als Basis gewählt werden:

Die Auswahl beinhaltet nur Updates, die auch benötigt werden (required >0). Ebenso nur Updates, die von Microsoft kommen, noch nicht durch ein neueres Updates ersetzt wurde und bei denen es sich um ein Security Updates (hat eine MSyy-xxx Nummer, also ein MS in der Bulletin ID).

Zur Überprüfung der Auswahl bietet sich der Preview Button an.

Da wir die Updates für die Testclients direkt freigeben, hängen wir den Evaluation Schedule an den WSUS Sync Zeitpunkt. Bei Deployment Schedule wählen wir bei beiden Zeitfenstern “As soon as possible”.

Neustart unterdrücke ich in den meisten Fällen auf der “User Experience” Seite.

Die Updates kommen in ein Deployment Package mit dem Namen “Microsoft Updates”. Dieses Paket wird von allen Microsoft Updates Verteilungen genutzt. Das verhindert, dass das Update mehrfach heruntergeladen werden muss.

Für die Produktiven Clients gehen wir ähnlich vor. Dabei gibt es folgende Abweichungen:

• General: Create a new Software Update Group: Notwendig, da wir pro Patch-Day neue Zeitfenster definieren wollen
• Evaluation Schedule: Every 2 weeks on Wednesday: angelehnt an den Microsoft Patchday, aber häufiger pro Monat, da u.U. neue Clients hinzukommen, denen noch Updates fehlen, die aber bereits auf allen anderen Clients installiert sind. (Dies ist notwendig, da wir im Gegensatz zu den anderen Strategien hier mit keiner Baseline von Softwareupdates arbeiten)
• Deployment Schedule: Software available time: 1 week (ermöglicht, dass die Testclients mögliche Fehler bereits erkannt haben), Installation deadline: 1 week (erzwingt die Installation eine Woche nach der Available time, d.h. Updates werden ca. zwei Wochen nach der Veröffentlichung auf den Clients erzwungen)

Erstellt man eigene Management Packs (MP) für den Operations Manager (OpsMgr) oder den Service Manager (SCSM), so kommt es regelmäßig vor, dass er beim Öffnen eine bestimmte Version eines abhängigen MPs haben möchte. Wurde das neue Management Pack in einer Umgebung erstellt, die ein aktuelles Update Rollup eingespielt hat, so wird u.U. genau dieser benötigt.

Daher habe ich mir für meine tägliche Arbeit in einer Ordnerstruktur mit diversen Management Packs aufgebaut. Als Ordnername wird die Versionsnummer verwendet. Möchte das Authoring Studio somit die Version 1.0.1, kann ich in den Ordner wechseln und sehe direkt alle MPs mit dieser Version bzw. aufgrund des Filters im Dialog direkt das benötigte File.

Gerade bei den vielen MPs von Microsoft ist es schwer, diese Struktur manuell zu pflegen. Erschwerend kommt hinzu, dass man an der .mp Datei nicht direkt sieht, welche Version es ist. (Kleiner Tipp am Rande: Dateiendung .dll anfügen und dann ist im Eigenschaftendialog die Versionsnummer sichtbar).

Daher habe ich mir das nachfolgende Powershell geschrieben, dass signierte MP-Files, unsignierte XML-Files und Managementpack Bundles (.mpb) in entsprechende Ordner einsortiert.

Bei mpb Files verwende ich ein Workaround, da ich das erste File (Index 0) extrahiere und auf Basis davon die Einsortierung vornehme.

$sourcePath="E:\_Tools\OpsMgr\MP Library"
$targetPath=$sourcePath
$filter=$sourcepath+"\*"
get-childitem $filter -include *.mp | foreach-object {
$name=$_
$version=[System.Diagnostics.FileVersionInfo]::GetVersionInfo($_).FileVersion
new-item -path . -name $version -itemtype Directory
$source=$name
$target=$targetPath+"\"+$version
"Moving from $source to $target"
move-item -path $source -destination $target
}

get-childitem $filter -include *.xml | foreach-object {
$name=$_
$version=(select-xml -path $name -XPath "/ManagementPack/Manifest/Identity/Version").Node.InnerXML
new-item -path . -name $version -itemtype Directory
$source=$name
$target=$targetPath+"\"+$version
"Moving from $source to $target"
move-item -path $source -destination $target
}

get-childitem $filter -include *.mpb | foreach-object {

import-module pscx
$name=$_
$version=""
"Extracting XML from $name"
expand-archive $name -Index 0
$xml=[System.IO.Path]::GetFileNameWithoutExtension($name)+".xml"
"Using $xml"
$version=(select-xml -path $xml -XPath "/ManagementPack/Manifest/Identity/Version").Node.InnerXML
remove-item $xml
new-item -path . -name $version -itemtype Directory
$source=$name
$target=$targetPath+"\"+$version
"Moving from $source to $target"
move-item -path $source -destination $target
}

Das dritte kumulative Update für den System Center 2012 R2 Configuration Manager (ConfigMgr) ist seit gestern verfügbar.

Wie üblich sind einige Probleme korrigiert worden.  Nennenswert sind aus meiner Sicht folgende Punkte:

• Unknown x64 UEFI Computer werden fehlerhafter Weise auf x86 Unknown Computer gemappt
• SMS Agent Host kann während einer Task Sequenz unerwartet abstürzen
• Änderungen an den Eigenschaften eines Distribution Points können dazu führen, dass im IIS Log kein Datum und Uhrzeit mehr protokolliert wird

Ungewöhnlicher Weise gibt es in diesem CU 3 eine neue Funktionalität:

Bis jetzt habe ich Kunden immer davon abgeraten an Remotestandorten Management Points (MP) einzusetzen, da diese nicht standortbezogen sind. Ein Client bekommt somit eine Liste aller MPs in der Site und geht diese alphabetisch durch, bis er einen erreichbaren gefunden hat. Workarounds mit Firewallsperrungen, um den Client nur auf seinen am Standort vorhandenen MP zu lassen, sehe ich nicht wirklich als elegant an.

Einen ersten Schritt Richtung Site Awareness macht jetzt das CU3, denn es führt auf dem Client  einen Registry Key, mit dem definiert wird, auf welche Management Points der Client zugreifen darf. Es handelt sich dabei um einen eher ungewöhnlichen REG_MULTI_SZ Key, der mittlerweile direkt über regedit erzeigt werden kann:

Alternativ ist dies auch über reg.exe möglich:

reg.exe ADD "HKEY_LOCAL_MACHINE\Software\Microsoft\CCM" /v AllowedMPs /t REG_MULTI_SZ /d "MP1\0MP2\0MP3\0"

In seinem Sitesetup sollte man trotzdem bedenken, dass ein MP immer auf die Sitedatenbank zugreifen muss. Alternativ ist hier ein Replikat der Sitedatenbank an dem entfernten Standort möglich.

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

In der folgenden Matrix wird aufgelistet, unter welchen Rechten dann die Installation läuft:

Wird die Installation unter dem Angemeldeten Benutzer ausgeführt, so erhält dieser keine zusätzlichen Rechte. Braucht die Installation Administrative Rechte, die der Benutzer nicht hat, so schlägt die Installation fehl.

Im Deploymenttyp sollte man bei klassischen Anwendungen daher das Installationsverhalten auf “Install for System” stellen.

Einstellungen die im Userkontext erfolgen müssen wie z.B. Anpassen von Current User Registry Werte oder Modern UI Apps sollten im Modus “Install for User” stehen.

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:

.\createSWCollection.ps1 -vendor "Adobe" -software "Flash Player 14" -site MBK -siteserver cm01

Loading ConfigMgr Module  D:\Program files\ConfigMgr\bin\ConfigurationManager.psd1
Collection Flash Player 14 successfull created. ID:MBK00011

Das gesamte Script hat einige nützliche Funktionen, die ich auch in anderen Powershellscripte verwende:

[CmdletBinding()]
param(
[Parameter(Mandatory=$true)]
[string]$Vendor,
[Parameter(Mandatory=$true)]
[string]$Software,
[Parameter(Mandatory=$true)]
[string]$Site,
[Parameter(Mandatory=$true)]
[string]$Siteserver,
[Parameter(Mandatory=$false)]
[string]$rootFolder="_Software"
)


 #Load the ConfigurationManager Module

 #from http://www.dexterposh.com/2014/06/powershell-sccm-2012-getting-started.html
try
{
    $ConfigMgrModule = "$($env:SMS_ADMIN_UI_PATH | Split-Path -Parent)\ConfigurationManager.psd1"
    if (!(Test-Path $ConfigMgrModule)) {
        throw 'Configuration Manager module not found in admin console path'
    }
    write-host "Loading ConfigMgr Module " $ConfigMgrModule
    Import-Module $ConfigMgrModule
    $BeforeLocation = (Get-Location).Path
} catch 
{
   Write-Error $_.Exception.Message        
}

cd $site":"

$updateCollectionMin=30
$limitingCollection="All Systems"


$namespace="root\SMS\Site_$site"
$PSDefaultParameterValues =@{
    "get-cimclass:namespace"="Root\SMS\site_$site";
    "get-cimclass:computername"=$siteserver;
    "get-cimInstance:computername"=$siteserver;
    "get-ciminstance:namespace"="Root\SMS\site_$site";
    "get-wmiobject:namespace"="Root\SMS\site_$site";
    "get-WMIObject:computername"=$siteserver}

 $rootDeviceFolder=Get-CimInstance -ClassName SMS_ObjectContainerNode -Filter "ObjectType=5000 and ParentContainerNodeid=0"
 
 function getFolder([String]$name,[int]$parentID,[bool]$deviceFolder=$true) {
   if ($deviceFolder) {
       $objectTyp=5000
    } else {
     $objectTyp=6000
    }
    Get-CimInstance -ClassName SMS_ObjectContainerNode -Filter "ObjectType=$objectTyp and ParentContainerNodeid=$parentID and Name='$name'"
 }
 

 function createFolder([String]$name,[int]$parentID,[bool]$deviceFolder=$true)
 {
    if ($deviceFolder) {
       $objectTyp=5000
    } else {
     $objectTyp=6000
    }
    $rt=getfolder $name $parentID $deviceFolder
    if (-not $rt) {
        $rt=New-CimInstance -ClassName SMS_ObjectContainerNode -Property @{Name=$name;ObjectType=$objectTyp;ParentContainerNodeid=$parentID;SourceSite=$site} -Namespace $namespace -ComputerName $siteserver 
        Write-Host "Folder $name successfull created."
    }
    else
    {
        write-verbose "Folder $name already exists."
    }
    $rt
 }

 function createFolderPath([String]$folderPath,[int]$parentID,[bool]$deviceFolder=$true)
 {
    if ($deviceFolder) {
       $objectTyp=5000
    } else {
     $objectTyp=6000
    }
    $folders=$folderPath.split('\')
    $parentID=0
    $folders | ForEach-Object {
       $folder=$_
       $rt=createFolder $folder $parentID $true
       $parentID=$rt.ContainerNodeID
    }
    $rt
 }
 
 #$rootDeviceFolder


 $folderpath=$rootFolder+"\$vendor"
 $targetFolder=createFolderPath $folderpath 0 $true

 $collection=Get-CMDeviceCollection -name $software
 if (-not $collection) {
    $collection=New-CMDeviceCollection -Name $software -Comment "Software Deployment Target for $software" -LimitingCollectionName $limitingCollection  -RefreshType Periodic -RefreshSchedule (New-CMSchedule -Start (get-date) -RecurInterval Minutes -RecurCount $updateCollectionMin) 
    write-host ("Collection $software successfull created. ID:"+$collection.CollectionID)

 }
else
{
    write-verbose ("Collection $software already exists. ID:"+$collection.CollectionID)
}
Move-CMObject -FolderPath ($site+":\DeviceCollection\"+$folderpath) -InputObject $collection

cd $BeforeLocation

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.

Natürlich können die Scripte dies nicht ohne Basisinformationen durchführen. Daher existiert dazu eine appdefinition.xml Datei, in der die notwendigen Informationen hinterlegt sind.

Ich habe dabei versucht, alle Informationen, die automatisch ausgelesen werden können, nicht in der Datei zu hinterlegen. So wird bei einem MSI File dieses ausgelesen und daraus der Hersteller, der Softwarename und die Versionsnummer ermittelt. Genauso wird dabei der Productcode für die Detectionmethode ermittelt.

Es handelt sich bei diesen Scripten um ALPHA-Code, d.h. ich warne davor, die Scripte ohne ausführliche Tests in einer produktiven Umgebung einzusetzen!

Verwendung für die Mutigen:

1. Auspacken des angehängten Zip-Files in einem Ordner auf dem Siteserver
2. Auspacken einer aktuellen Version des PSAppDeployment Toolkits in einen separaten Ordner
3. Anpassen der Konstanten in der main.ps1 Datei an die eigenen Sitenamen und Ordnerstrukturen
4. eine passende appdefinition.xml Datei aus einem der nachfolgenden Posts herunterladen und zusammen mit den Quelldateien in einem extra Quellordner ablegen
5. Ausführen der main.ps1 in einer administrativen Powershell mit dem einzigen Parameter appDefinition:  “.\main.ps1 -appDefinition .\IrfanViewPlugins\appdefinition.xml”

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://www7-zip.org).

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

Achtung: Benötigt mindestens Version 0.3 der Scripte!

<appdefinition>
<file>7z938-x64.msi</file>
<hash type="SHA256">7C8E873991C82AD9CFCDBDF45254EA6101E9A645E12977DCD518979E50FDEDF3</hash>
<info>
	<setupType>MSI</setupType>
	<isX86>false</isX86>
	<hasUninstall>true</hasUninstall>
</info>
<install/>
<uninstall/>
<detection/>
</appdefinition>

Der Hashwert wird momentan noch nicht überprüft und könnte daher weggelassen werden. Zusätzlich zum primären File wird noch die Setupvariante vom Typ MSI mitgegeben. Die Blöcke install, uninstall und detection werden aufgrund des Setuptyps und des MSI Files automatisch ausgefüllt.
Legt man die Datei 7z938-x64.msi und die appdefinition.xml in den selben ansonsten leeren Ordner und führt die main.ps1 mit der Pfadangabe zu der XML Datei aus, so wird die komplette Software angelegt und die Ausgabe sieht so aus:

Will man jetzt die Version 9.39 verteilen, so würde es ausreichen, den Download in einen neuen Ordner anzulegen, die appdefinition.xml zu kopieren und den Filenamen auszutauschen. Den Rest würden die Powershellscripte erledigen!

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.

Durch die Angabe, dass es sich um ein NSIS File handelt, werden automatisch die korrekten Silent-Parameter (“/S”) und Detections (Uninstall String anhand des Softwarenamens und der Versionsnummer ermitteln) in das PSDeploymentToolkit eingetragen.
Auch in diesem Beispiel wird klar, das nur minimale Angaben erforderlich sind.

Achtung: Benötigt mindesten Version 0.3 der Scripte!

<appdefinition>
<file>vlc-2.1.5-win32.exe</file>
<hash type="SHA256">6C166362AD87722A31EDA088E41BE5AF15E55DA0699CEC09DD456762517B9B84</hash>
<info>
	<company>VideoLAN</company>
	<productName>VLC media player</productName>
	<productVersion>2.1.5</productVersion>
	<setupType>NSIS</setupType>
	<isX86>true</isX86>
	<hasUninstall>true</hasUninstall>
</info>
<install/>
<uninstall/>
<detection/>
</appdefinition>

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:

• Der Installationsprozess wird mit den in der FAQ (http://www.irfanview.com/faq.htm#Q72) dokumentierten Parametern angepasst
• Die Deinstallation holt sich den Pfad zur uninstall-EXE aus der Registry (abhängig davon, ob es sich um ein 64bit System handelt) und deinstalliert IrfanView mit dem /silent Parameter
• Die Detection nutzt den gleichen Uninstall-Pfad zur Erkennung, ob es installiert ist oder nicht.

An diesem Beispiel erkennt man, dass auch individuelle Installationspakete abgedeckt werden können. Da die Bereich, die gleich bleiben, nicht in der appdefinition.xml hinterlegt sind, bleibt auch die Gesamtbeschreibung der Paketierung übersichtlich.

Achtung: Diese Version benötigt mindestens Version 0.3 der Scripte!

<appdefinition>
<file>iview438_setup.exe</file>
<hash type="SHA-256">0cf69ff91696589ae6ff8809845c9a8b5d2b1ebd952ccc5402c75037bcd11818</hash>
<info>
<setupType>InnoSetup</setupType>
<isX86>true</isX86>
<hasUninstall>true</hasUninstall>
</info>
<install>
Show-InstallationProgress -StatusMessage 'Installing IrfanView. This may take some time. Please wait...'
Execute-Process -Path "iview438_setup.exe" -Parameters "/silent /desktop=0 /thumbs=0 /group=1 /allusers=1 /assoc=0" -WindowStyle Hidden
</install>
<uninstall>
if ($is64Bit) {
	$regPath="HKLM:\Software\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*"
}
else
{
	$regPath="HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall\*"
}
$uninstallApp=(Get-ItemProperty $regPath | where {$_.DisplayName -like "*IrfanView*" -and $_.DisplayVersion -eq "4.38"}).UninstallString.replace("`"","")
Execute-Process -Path "$uninstallApp" -Parameters "/silent" -WindowStyle Hidden
</uninstall>
<detection>
if ([IntPtr]::Size -eq 8) {
	$regPath="HKLM:\Software\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*"
}
else
{
	$regPath="HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall\*"
}
(Get-ItemProperty $regPath | where {$_.DisplayName -like "*IrfanView*" -and $_.DisplayVersion -eq "4.38"})
</detection>
</appdefinition>

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.

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)

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:

<appdefinition>
<file>gs915w32.exe</file>
<hash type="SHA256">EC4B9C5514EC2C795C488BE678933E51AF48BE285EFC8F5B4D36C70712BEDC3E</hash>
<info>
	<company>Artifex Software, Inc.</company>
	<productName>GPL Ghostscript</productName>
	<productVersion>9.15</productVersion>
	<setupType>NSIS</setupType>
	<isX86>true</isX86>
	<hasUninstall>true</hasUninstall>
</info>
<install/>
<uninstall/>
<detection/>
</appdefinition>

Und die entsprechende Datei für die 64-bit Variante:

<appdefinition>
<file>gs915w64.exe</file>
<hash type="SHA256">6CC35A88C45ECE5129C31B8973CD5268CC2458BE6CD2177DCBBCA16ECAEA6BA4</hash>
<info>
	<company>Artifex Software, Inc.</company>
	<productName>GPL Ghostscript</productName>
	<productVersion>9.15</productVersion>
	<setupType>NSIS</setupType>
	<isX86>false</isX86>
	<hasUninstall>true</hasUninstall>
</info>
<install/>
<uninstall/>
<detection/>
</appdefinition>

Es gibt unzählige Clientdruckertreiber, um PDFs zu erzeugen. eDocPrint Pro ist eines davon. Die Nicht PDF-A Variante scheint kostenlos zu sein. Die Software selber ist mit dem Advanced Installer (http://www.advancedinstaller.com/user-guide/exe-setup-file.html) verpackt.
Die kostenlose Variante ist am einfachsten über folgenden Link zu finden: http://www.pdfblog.at/2014/10/edocprintpro-version-3-21-verwendet-ghostscript-9-15/.

Sollte auf dem Zielsystem kein GhostScript installiert sein, so versucht die Software dieses automatisch herunterzuladen. Daher sollte GhostScript manuell heruntergeladen werden und als Abhängigkeit definiert werden. Die Paketierung von GhostScript ist unter folgendem Link beschrieben: GhostScript 9.15.
Der Installer beinhaltet die x64 und x86 Version und benötigt je nach Endgerät ebenfalls die x86 oder x64 Variante von GhostScript.

Da ich den Advanced Installer nicht als Installationstyp aufgeführt habe, nutze ich NSIS als generischen Platzhalter:

<appdefinition>
<file>eDocPrintPro.exe</file>
<hash type="SHA256">616559B154C16177D0E2CF623C17CB9010C6771891D881400407CAF46A9D95DC</hash>
<info>
	<setupType>NSIS</setupType>
	<isX86>false</isX86>
	<hasUninstall>true</hasUninstall>
</info>
<install>
Show-InstallationProgress -StatusMessage "Installing $appName. This may take some time. Please wait..."
Execute-Process -Path 'eDocPrintPro.exe' -Parameters '/exenoui /qn' -WindowStyle Hidden
</install>
<uninstall>
Execute-MSI -Action Uninstall -Path '{7F4F9992-4238-462C-862E-2B38C638D65F}'
</uninstall>
<detection/>
</appdefinition>

Möchte man einen zusätzlichen PDF Drucker unter einem anderen Namen installieren, so ist dies auch mit wenig zusätzlichen Aufwand integrierbar:

<appdefinition>
<file>eDocPrintPro.exe</file>
<hash type="SHA256">616559B154C16177D0E2CF623C17CB9010C6771891D881400407CAF46A9D95DC</hash>
<info>
	<setupType>NSIS</setupType>
	<isX86>false</isX86>
	<hasUninstall>true</hasUninstall>
</info>
<install>
Show-InstallationProgress -StatusMessage "Installing $appName. This may take some time. Please wait..."
Execute-Process -Path 'eDocPrintPro.exe' -Parameters '/exenoui /qn' -WindowStyle Hidden
Show-InstallationProgress -StatusMessage 'Creating custom PDF printer. Please wait...'
execute-process -Path "$env:CommonProgramFiles\MAYComputer\eDocPrintPro\eDocPrintProUtil.exe" -Parameters '/silent /PRINTER="PDF Drucker" /addprinter' -WindowStyle Hidden   -ContinueOnError $true
</install>
<uninstall>
Execute-MSI -Action Uninstall -Path '{7F4F9992-4238-462C-862E-2B38C638D65F}'
</uninstall>
<detection/>
</appdefinition>