Seit zwei Tagen (11.03.2016) gibt es die offizielle Version 1602 vom ConfigMgr. Es beinhaltet einige interessante Änderungen, die ich auch in meinem letzten Vortrag angerissen habe.

Achtung: Eine direkte Installation ist nicht vorgesehen, sondern man muss zuerst das letzte Baseline Release (1511) installiert haben und kann dann direkt upgraden (dies kann auch vor dem Clientupgrade erfolgen).

Weitere Details sind hier zu finden:

https://blogs.technet.microsoft.com/configmgrteam/2016/03/11/now-available-update-1602-for-system-center-configuration-manager/

Ein weiteres Beispiel mit Supersedence wäre die aktuelle Version der Unternehmensvariante von Firefox. Es werden die letzten drei von mir vorbereiteten Versionen in die veraltete Softwareliste aufgenommen.

Download unter: https://www.mozilla.org/en-US/firefox/organizations/all/

<appdefinition>
<file>Firefox Setup 38.6.1esr.exe</file>
<hash type="SHA256">771A00786C69F7290A25C495A03622B4616C21D6A062BC712F55E0AE0282C219</hash>
<info>
	<company>Mozilla Corporation</company>
	<productName>Mozilla Firefox</productName>
	<productversion>38.6.1</productversion>
	<setupType>NSIS</setupType>
	<isX86>true</isX86>
	<hasUninstall>true</hasUninstall>
</info>
<install>
$inf=Join-Path $env:temp firefox.ini
$content="[Install]
QuickLaunchShortcut=false
DesktopShortcut=false
MaintenanceService=false" -replace "`n", "`r`n"
Out-File -FilePath $inf -Force -InputObject $content -Encoding ascii
Show-InstallationProgress -StatusMessage "Installing $appName $appVersion. This may take some time. Please wait..."
Execute-Process -Path "Firefox Setup 38.6.1esr.exe" -Parameters "/INI=`"$inf`"" -WindowStyle Hidden
</install>
<uninstall>
if ([IntPtr]::Size -eq 8) {$regPath="HKLM:\Software\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*"} else { $regPath="HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall\*"}
$item=Get-ItemProperty $regPath | where {$_.DisplayName -like "*Mozilla Firefox*" -and $_.DisplayVersion -eq "38.6.1"}
Execute-Process -Path ($item.UninstallString -replace "`"", "") -Parameters "/S"
</uninstall>
<detection/>
<dependency/>
<supersedence>
<deploymentType uninstall="false" type="SHA256">8CA1EC61B9DF30DDCEF3E7CE5234C2BEF6EC7C9C3A4B51F57C67FC9E8822E7FB</deploymentType><!--38.2.0-->
<deploymentType uninstall="false" type="SHA256">40DC3DF8C548819733386B70791DB753793E98C5F08283001D851A204376F017</deploymentType><!--38.2.1-->
<deploymentType uninstall="false" type="SHA256">FDC5BAA6033918E7FE8018DE130F16A23896B623B0B4F60A8EA578759C2DD29C</deploymentType><!--38.6.0-->
</supersedence>
</appdefinition>

Nachfolgend ist ein erstes Beispiel, um Supersedence Regeln automatisch erstellen zu können. Voraussetzung ist, dass die Version 1.8.11 ebenfalls mit der neuesten Version von meinem Toolkit angelegt wurde. Dann ist im DeploymentType der Hash Wert hinterlegt, an Hand der das Script die zu ersetzende Anwendung erkennt. Da es sich hierbei um ein ordentliches MSI Paket handelt, ist ein vorhergehendes Uninstall nicht notwendig und daher auf “False” gesetzt.

Das neue MSI File kann unter https://tortoisesvn.net/downloads.de.html heruntergeladen werden.

Nach langer Zeit habe ich endlich meine über Wochen entwickelte neue Version des Toolkits zur automatischen Verteilungen im ConfigMgr in der Version 0.6 zusammengestellt. Es benötigt die aktuelle ConfigMgr Powershell Version.

Folgende Punkte haben sich geändert:

0.6    – 2016-02-10

• NEW: Benutzer jetzt die neue Methode  Add-CMScriptDeploymentType
• NEW: Verwendet die neue Methode -AvailableDateTime
• NEW: Hash Wert wird im Admin-Kommentar hinterlegt. Ziel ist die Verwendung als deprecated bzw. dependance
• NEW: Im XML File können deprecated Anwendungen über den Hash Wert angegeben werden, die automatisch hinterlegt werden
• NEW: Im XML File können Gruppen von dependent Anwendungen hinterlegt werden, die als Voraussetzung in der Anwendung hinterlegt werden (aktuell nur mit einer Anwendung pro Gruppe getestet)
• NEW: Neue Setupart MSP. Macht aktuell nicht viel anderes als das MSI Setup, aber extrahiert weniger aus der MSI Tabelle (da es meistens nicht gefüllt ist). Dafür nutzt es die ProductID

Download: automateAppDeployment (version 0.6) (2978 downloads )

Vor einiger Zeit wurde die Powershell Library für ConfigMgr aus den Cumulative Updates herausgenommen und wird getrennt veröffentlicht. Dadurch können andere Releasezyklen genutzt werden.

Jetzt wurde vor zwei Tagen eine neue Version veröffentlicht:

http://blogs.technet.com/b/configmgrteam/archive/2016/01/25/winter-2016-update-for-the-sc-configmgr-cmdlet-library.aspx

Sie ist verwendbar für alle aktuellen Configuration Manager Versionen:

• System Center 2012 Configuration Manager SP2
• System Center 2012 R2 Configuration Manager
• System Center 2012 R2 Configuration Manager SP1
• System Center Configuration Manager (current branch version 1511)

Und funktioniert auch mit der aktuellen Preview. In der Preview 1601 soll sie bereits enthalten sein.

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.

Zu meiner Überraschung habe ich am 1.1.2016 folgende Email erhalten:

Ich nehme dies als Ansporn mehr Energie in meine Community Kanäle zu legen!

Anfang 2014 habe ich in Channel9 eine kleinen Überblick über “Consumerization of IT” gegeben: https://channel9.msdn.com/Series/Ein-Ueberblick-ueber-Consumerization-of-IT/Was-ist-Consumerization-of-IT-

Wie stellt sich das damals skizzierte Bild von Microsoft Technologien heute dar?

Zentraler Angelpunkt aller Aktivitäten sollten immer noch die Daten sein. Daher habe ich schon damals viel Augenmerk auf AD RMS gelegt. Mittlerweile wurde es durch einen Azure Dienst namens Azure Rights Management ergänzt. Durch die Integration in Azure AD und eines On-Premise Connectors wird der Austausch mit anderen Firmen deutlich vereinfacht, da keine individuellen Trusts zwischen Firmen erzeugt werden müssen. Durch die Verwendung von RMS for Individuals kann darüber hinaus ein sicherer Austausch von Dokumenten auch mit Personen erfolgen, die keinen Zugang zu kostenpflichtigen Azure Diensten haben.

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.