Update 20160130: Im Script fehlte ein kleiner Teil, daher war die Verteilung nicht in jedem Fall erfolgreich. Dies ist jetzt angepasst.

Nachdem ich im letzten Post die Verteilung von 8u66 beschrieben habe, schiebe ich direkt die Verteilung vom aktuellen 8u71 hinterher. Wie gewünscht ist es hauptsächlich das Austauschen der EXE und Anpassen der Filenamen bzw. GUIDs und Versionsnummern.

<appdefinition>
<file>jre-8u71-windows-i586.exe</file>
<hash type="SHA256">3CC0BE2A34F0989692C30F2CACB89CACFCA7159570D5FC8C1B1498C60CBC07FB</hash>             
<info>
	<setupType>InnoSetup</setupType>
	<isX86>true</isX86>
	<company>Oracle Corporation</company>
	<productName>Java 8 Update 71</productName>
	<msiProductCode>{26A24AE4-039D-4CA4-87B4-2F83218071F0}</msiProductCode>
</info>
<install>
Show-InstallationProgress -StatusMessage 'Installing Java JRE. This may take some time. Please wait...'
$path=join-path (join-path $env:programdata 'Oracle') 'Java'
if ((Test-Path $path) -eq $false) {
   New-Item -Type Directory $path |out-null
}
new-item -type File (join-path $path 'java.settings.cfg') -force | out-null
if ($is64Bit) {
	$path=join-path $envWinDir "System32\config\systemprofile\AppData\LocalLow\Oracle"
	$symName=join-path $envWinDir "SysWOW64\config\systemprofile\AppData\LocalLow\Oracle"
	if  (Test-Path $symname) {
		remove-Item -Recurse -Path $symName
	}
	if (-not (Test-Path $path)) {
		new-item -ItemType Directory -Path $path
	}
	#Quelle: https://gallery.technet.microsoft.com/scriptcenter/New-SymLink-60d2531e
	        Try {
	            $null = [mklink.symlink]
	        } Catch {
	            Add-Type @"
	            using System;
	            using System.Runtime.InteropServices;
	 
	            namespace mklink
	            {
	                public class symlink
	                {
	                    [DllImport("kernel32.dll")]
	                    public static extern bool CreateSymbolicLink(string lpSymlinkFileName, string lpTargetFileName, int dwFlags);
	                }
	            }
"@
	        }
	            Try {
	                $return = [mklink.symlink]::CreateSymbolicLink($SymName,$Path,1)
	            } Catch {
	            }
}

Execute-Process -Path "jre-8u71-windows-i586.exe" -Parameters "/s INSTALL_SILENT=Enable AUTO_UPDATE=Disable WEB_JAVA=Disable WEB_ANALYTICS=Disable REBOOT=Disable NOSTARTMENU=Enable SPONSORS=Disable" -WindowStyle Hidden
</install>
<uninstall>
Execute-MSI -Action Uninstall -Path "{26A24AE4-039D-4CA4-87B4-2F83218071F0}"
</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 {$_.psChildname -like "{26A24AE4-039D-4CA4-87B4-2F83218071F0}" -and $_.DisplayVersion -eq "8.0.710.15" -and $_.WindowsInstaller -eq 1}
</detection>
</appdefinition>

Seit längerem stört es mich, dass man für die JRE Verteilung immer noch das MSI File extrahieren muss. Das macht den Sinn vom AutomaticAppDeployment kaputt, da mehr manuelle Schritte notwendig sind.

Ursache dafür ist ein alter Bug im Oracle JRE Setup, der Probleme mit der Installation im SYSTEM Kontext von 32bit Java unter x64 Betriebssystemen hat. Der Bug ist u.a. hier dokumentiert: http://bugs.java.com/bugdatabase/view_bug.do?bug_id=7014194

Angeblich ist der Fehler bereits in 8u51 behoben. Meine Realität sieht aber anders aus.

Das Toolkit zum automatischen Erstellen von Verteilungen im ConfigMgr ist jetzt in der Version 0.5 verfügbar.

Folgende Punkte haben sich geändert:

• 0.5    – 2015-09-29

• NEW: MSI Product Code kann ebenfalls überschrieben werden (z.B. beim Mumble Client)

• BUG: Fehler im InnoSetup Powershell Code korrigiert.

• NEW: GlobalDef Variable, um nur die Dateien anzulegen und keine ConfigMgr Integration durchzuführen.

• BUG: Falls der Files Ordner im Template noch nicht existiert, scheiterte das Kopieren.

• BUG: Bei der neuen AppDeploymentToolkit Version wurde die Abschlussmeldung nicht mehr entfernt.

Die 2015er Version von Adobe Reader ist  ist aufgeteilt in eine continuous und classic Variante. Die continuous Version ist eher für weniger zentral strukturierte Umgebungen vorgesehen, da sie ähnlich wie Cloud Software ständig aktualisiert. Die classic Variante wird wie gehabt weiterhin Quartalsweise aktualisiert.

Eine kurze Gegenüberstellung ist hier zu finden:

http://www.adobe.com/devnet-docs/acrobatetk/tools/AdminGuide/whatsnewdc.html#continuous-vs-classic-comparison

In dieser Beschreibung werde ich auf die classic Variante eingehen. Sie ist über die Adobe Webseite herunterladbar.  Dazu lädt man zuerst die Basis Version unter ftp://ftp.adobe.com/pub/adobe/reader/win/Acrobat2015/1500630033/ herunter. Diese kann man mit der Kommandozeile

Auch im Fall des 8er Releases wird die Verteilung noch über die entpackte MSI Datei gemacht. Die Verwendung der eigentlichen EXE ist an sich stabiler, aber läßt sich nicht 100% steuern. Die neuen Möglichkeiten mit dem 8er Installer habe ich hier (noch) nicht verwendet.

Auch dieser Oracle MSI Installer hat ein Problem, dass er in ProgramData eine java.settings.cfg erwartet, falls eine JRE Version bereits vorhanden ist. Daher überprüft das Skript das Vorhandensein des Pfades und legt eine leere Datei an:

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
  

Natürlich ist 7u71 nicht die neueste Version. Daher hier das XML für die Version 7u75:

<appdefinition>
<file>jre1.7.0_75.msi</file>
<hash type="SHA256">63FDCEF04140AFE7236DD8BE904066056EA8E1C7619DE0F8F9496FDB241DE507</hash>
<info>
	<company>Oracle Corporation</company>
	<setupType>MSI</setupType>
	<isX86>true</isX86>
	<hasUninstall>true</hasUninstall>
</info>
<install>
Execute-MSI -Action Install -Path "jre1.7.0_75.msi" -Parameters "REBOOT=ReallySuppress JAVAUPDATE=0 CUSTOM=1 /QB"
if ($is64Bit) {$regPath="HKLM:\Software\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*"} else { $regPath="HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall\*"}
$javaPath=(Get-ItemProperty $regPath | where {$_.psChildname -like "{26A24AE4-039D-4CA4-87B4-2F03217075FF}" -and $_.DisplayVersion -eq "7.0.750" -and $_.WindowsInstaller -eq 1}).InstallLocation
$jqs=join-path (join-path $javaPath "bin") "jqs.exe"
if (test-path $jqs) {
	Execute-Process -Path "$jqs" -Parameters "-unregister" -WindowStyle Hidden -ContinueOnError $true
}
$runKey="HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Run"
$run=Get-Item $runKey
if ($run.GetValue("SunJavaUpdateSched",$null)) {
	remove-itemProperty -Path $runKey -Name "SunJavaUpdateSched"
}
if ($is64Bit) {
$runKey="HKLM:\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Run"
$run=Get-Item $runKey
if ($run.GetValue("SunJavaUpdateSched",$null)) {
	remove-itemProperty -Path $runKey -Name "SunJavaUpdateSched"
}
}
</install>
<uninstall/>
<detection/>
</appdefinition>

Obwohl bereits JRE8 bereitsteht, wird die 7er Version trotzdem noch verteilt. Das Setup hat trotz anderslautender Parameter die Autoupdate Dienste mitinstalliert, die in einem Unternehmensumfeld nicht sinnvoll sind.
Daher entfernt diese appdefinition.xml Datei diese nach der Installation. Das notwendige MSI File erhält man, in dem man die Exe ausführt und dann (ohne das Setup zu beenden) die msi und cab Datei aus dem %userprofile%\AppData\LocalLow\Sun\Java\jre1.7.0_71 kopiert.

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:

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.