OpsMgr: Neue Management Packs seit März 2014

Neue Management Packs im Zeitraum zwischen 09.03.2014 und 12.10.2014

Message Queuing

Active Directory

DHCP

DNS

Microsoft Dynamics

Operating System

Posted in Active Directory Domain Service, Deutsch, Operations Manager, System Center, Windows | Tagged , , , | Leave a comment

ConfigMgr: Cumulative Update 3 für ConfigMgr 2012 R2 verfügbar

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:

image

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.

Posted in Configuration Manager, Deutsch, System Center, System Center 2012 | Tagged , , | Leave a comment

OpsMgr, SCSM: Sortierhilfe für Management Pack Autoren

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
}
Posted in Deutsch, Operations Manager, Service Manager, System Center, System Center 2012 | Tagged , , | Leave a comment

Software Update Strategie

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.

image

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

image

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)
Posted in Configuration Manager, Deutsch, System Center, System Center 2012 | Tagged , , | Leave a comment

Azure Pack: SMA Params anzeigen

Arbeitet man mit Service Management Automation (SMA) im Microsoft Azure Pack, so werden in den Aufträgen die Parameter (Variable Params) und das zugrundeliegende Ressourcenobjekt als scheinbare Textwüste dargestellt. Das nachfolgende Bild zeigt ein Beispiel:

clip_image002

Die Struktur ist schnell erkennbar und wer sich tiefer mit Azure Pack und SMA auseinandergesetzt hat, sieht schnell, dass es sich um ein JSON (JavaScript Object Notation) Objekt handelt.

Um diese Objekte übersichtlicher darzustellen, gibt es ein praktische Webseite: Ein Beispiel ist

http://jsonviewer.stack.hu/

Darin sieht das Beispiel von oben bereits deutlich lesbarer aus:

clip_image002[6]

m4s0n501
Posted in Deutsch, System Center | Tagged , | Leave a comment