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]

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

ConfigMgr: System Center 2012 Configuration Manager Servicing Extension

Aktuell wird auf Connect die Beta des System Center 2012 Configuration Manager Servicing Extension angeboten:

http://go.microsoft.com/fwlink/?LinkId=398485

Diese Erweiterung für die ConfigMgr Konsole klingt sich in die Konsole unter Administration\Overview als Site Servicing Blatt ein. Sie muss somit nicht auf dem Site Server installiert werden (im Gegensatz zu InTune Erweiterungen).

Ziel der Software ist es auf neue Produktversionen (Cumulative Updates, Service Packs u.ä.) hinzuweisen. Zusätzlich werden auf der Einstiegsseite die aktuellen Blogposts vom ConfigMgr Team und dem ConfigMgr Support Team eingeblendet:

image

Die Informationen werden dabei im Kontext der Konsole (also auf dem Rechner, auf dem die Konsole gestartet wird) beim Zugriff auf den Bereich aus dem Internet heruntergeladen. Dabei wird ein CAB Datei geholt, in der aktuell drei XML Dateien vorhanden:

  • CurrentExtension.xml: Hinweis auf die aktuellste Version der Extension inkl. eines Downloadlinks
  • RssFeeds.xml: Liste mit den beiden ausgewerteten RSS Feeds
  • Updates.xml: Liste aller verfügbarer ConfigMgr Updates

Die Datei ist unter folgendem Link zu finden: http://go.microsoft.com/fwlink/?LinkId=386333

Klappt man den Bereich auf, so gibt es folgende weitere Möglichkeiten:

  • Site Updates
  • Site Versions:
  • Client Targeting
  • Blogs

Site Updates

Site Updates listet die Verfügbaren Updates und Hotfixe genauer auf. Dabei lässt sich auch der Filter entsprechend anpassen, dass auch ältere (anstatt der aktuell installierten) Versionen dargestellt werden können:

image

Natürlich gibt es jeweils den direkten Link zum Download des Updates.

Site Version

Existieren mehrere Sites in der Hierarchie, so werden hier die Versionen aller angeschlossener Sites angezeigt.

Client Targeting

Updates der Site bedeuten im Allgemeinen auch, dass die Clients aktualisiert werden. Verwendet man hierbei nicht den von mir bevorzugten Weg über den SCUP, so benötigt man dynamische Queries, die Clients beinhaltet, die noch nicht aktualisiert wurden. Dazu kann man unter Client Targeting eine gewünschte Zielversion aussuchen und erhalt dann die Auswahl, ob man eine Query mit allen Clients unterhalb dieser Version oder gleich bzw. über dieser Version haben möchte:

image

Die Query landet dann unter Monitoring\Overview\Queries und kann in einer Collection unter Membership Rules -> Query Rules -> Import Query Statement übernommen werden:

image

Zukünftig sollen hier u.U. auch weitere nützliche Abfragen hinterlegt werden.

Blogs

Hier werden die aktuellen Blog Einträge auf den oben genannten Seiten angezeigt. Dabei können Einträge als gelesen markiert werden, so dass man eine schnelle Übersicht über neue Einträge erhält.

Die meisten werden diese Blogs bereits in ihrem RSS Reader hinterlegt haben, so dass der Zusatznutzen dieser Liste eher begrenzt ist.

Fazit

Insgesamt eine nette kleine Erweiterung, die einem den Überblick über neue Updates im ConfigMgr Bereich vereinfacht und gerade bei größeren Installationen einen schnellen Einblick in die installierten Versionen liefert.

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

ConfigMgr: Paketierung mit System Center Configuration Manager – Teil 4

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:

Continue reading

Posted in Configuration Manager, Deutsch, Powershell, System Center, System Center 2012 | Tagged , , , , , | 1 Comment