Im Bereich Softwareverteilung gibt es mehrere Möglichkeiten eine Software auszuführen und zu verteilen:
Neue Management Packs im Zeitraum zwischen 09.03.2014 und 12.10.2014
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:
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.
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
}
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:
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:
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:
Zertifizierungen:
[...]