PDFCreator 2.0.2 ist etwas einfacher bereitzustellen, als die 1er Linie, da keine Browsertoolbars erzwungen werden. Nach meinen Tests (bitte kommentieren, falls ich etwas übersehen habe), wird beim Silent Setup keine Adware installiert (beim normalen Setup kommt am Ende noch ein extra Setup mit irgendeiner Zusatzsoftware).

PDFForge verwendet InnoSetup. Die nachfolgende appdefinition.xml erzeigt zuerst ein inf-file, um den Setupprozess genauer steuern zu können. Danach wird das InnoSetup silent mit diesem inf-file ausgeführt.
Es wird die Firma und die Produktversion überschrieben, da die in der Datei hinterlegte Produktversion inkl. einer Buildnummer ist (2.0.2.751), die bei der Detection in der Registry nicht gefunden werden kann.

Nochmal zur Erinnerung, wie die Anwendung im ConfigMgr erstellt werden kann:

• Aktuelle Version des AutomaticDeploymentToolkits herunterladen und wie in Toolkit v0.1 beschrieben einrichten
• Neuen Ordner (z.B. PDFCreator202) anlegen
• pdfcreator-2_0_2-setup.exe herunterladen und in dem Ordner ablegen
• Eine Datei appdefinition.xml anlegen und mit dem unten angehängten Inhalt füllen
• In Powershell das Toolkit mit

  .\main.ps1 -appDefinition .\PDFCreator202\appdefinition.xml

aufrufen

Anbei eine aktualisierte Version der Powershell Scripte. Anleitung zur Einrichtung bitte dem ersten Post entnehmen: ConfigMgr: Automatisierte Softwarepaketierung und -bereitstellung
Das 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
  

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.

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:

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.

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:

Gerade wenn man in einem POC viel mit dem Microsoft Gateway im System Center Virtual Machine Manager (SCVMM) experimentiert, dann kann man in eine Situation geraten, in dem das Gateway nicht mehr konfigurierbar ist. Ein Entfernen funktioniert ebenfalls nicht mehr, da angelegte VM Networks davon abhängig sind. Die VM Networks lassen sich nicht mehr löschen, da dafür eine Aktualisierung des Gateways notwendig ist.

In diesem Bild sieht man ein Network “Tenant Test”, dass von einem Gateway abhängig ist:

Versucht man dieses zu löschen, dann bekommt man eine Fehlermeldung. Der Abhängigkeitsbericht zeigt folgendes:

Je nachdem wie gründlich man seinen Hyper-V Server pflegt, kann es passieren, dass im Cluster Shared Volume (CSV) ein paar Leichen übrig bleiben, da beim Löschen einer Virtuellen Maschine (VM) nicht automatisch die zugehörigen Disks (VHD) gelöscht werden.

Daher habe ich für meine Demo-Umgebung ein kleines Powershell Script geschrieben, dass alle an im Cluster registrierten VMs angehängte Disks auflistet und diese mit den im Dateisystem vorhandenen VHD Dateien abgleicht. Das Ergebnis kann dann genutzt werden, um eventuelle Leichen zu entdecken.