Zwischendurch ist es manchmal einfacher beim SCOM direkt die Datenbank abzufragen. Zwar bietet die Powershell auch eine einfache Zugriffsmöglichkeit, dies ist aber nicht immer der schnellste Weg.

Die Datenbankstruktur des SCOM ist relativ selbsterklärend, aber arbeitet stark mit Referenzen durch schwer lesbare GUIDs.

Um sich den Einstieg  etwas zu vereinfachen wurde hier ein paar SQL Abfragen zusammengetragen: http://www.braindumpblog.co.uk/?p=61

(der Blog Post ist zwar schon relativ alt, aber stellt trotzdem noch eine gute Übersicht dar)

Interessant. Seit fast einem Monat gibt es keine neuen Managementpacks. Trotzdem schreibe ich hier mal diesen Post, damit man nicht glaubt, dass ich es einfach vergessen habe :-)

Wird Software in Enteo per statischen Gruppen zugeordnet, so ist es bei einem Hardwareaustausch notwendig, die Zuordnungen des alten PCs auf den neuen zu übertragen. Dies kann man natürlich durch manuelles Drag&Drop machen, oder aber über ein kleines Powershell Skript:

param([string]$sourcename="source", [string]$targetname="target")
Add-PSSnapin NwcServices.BlsAdministration
$server="\\enteoserver"
New-PSDrive -Name emdb -psProvider BlsEmdb -Root $server
cd "emdb:\rootdse"
$source=get-emdbcomputer -recurse $sourcename

if ($source)
{
    $target=get-emdbcomputer -recurse $targetname
    if ($target)
    {
        $source.GetAssociatedItems() | where {$_.SchemaDisplayName -eq 'Static Group'} |foreach-Object{
        write-host "Cloning group " $_.Name " from $sourcename to $targetname"
        $_.addMember($target)
        }
    }
    else
    {
        write-host "Target $targetname cannot be found!"
    }
}
else
{
    Write-host "Source $sourcename cannot be found!"
}

Das Skript selber ist recht einfach aufgebaut. Es wird der Quellcomputer gesucht und das Objekt abgefragt, welche Verbindungen es hat.
Diese Verbindungen werden nach dem Typ statische Gruppen gefiltert. Über diese Gruppen wird iteriert und jeweils dem Zielobjekt hinzugefügt.

Die Verteilung von Visio und Project 2010 ist ähnlich wie Office 2010 sehr einfach. Im Gegensatz zu Office 2010, bei dem man eine MSP Datei erstellt, ändert man bei Visio und Project die config.xml Datei entsprechend ab. Diese Datei liegt im Visio.ww bzw PrjStd.ww Verzeichnis.

Eine Beispiel-Config kann so aus sehen: (innerhalb des umgebenen Bereichs)

<Display Level="none" CompletionNotice="no" SuppressModal="no" AcceptEula="yes" />
<Logging Type="Verbose" Path="%temp%" Template="VisioProject_Setup(*).txt" />
<USERNAME Value="Benutzername" />
<COMPANYNAME Value="Firma" />
<PIDKEY Value="abcdefg" />
<INSTALLLOCATION Value="%programfiles%\Microsoft Office" />

Ein Heartbeat ist eine wesentliche Komponente innerhalb eines Monitoringsystems. Dabei schickt der Client regelmäßig eine Alive Meldung an den Server. Bleibt diese eine gewisse Zeit aus, dann wird der Client als defekt gemeldet.

Auch der System Center Operation Manager (SCOM) hat ein solches Feature. Die Einstellungen werden primär global im Administrations –> Settings Bereich gemacht.

Bei einem Kunden haben wir momentan das Problem, dass es für jeden per OSD neu installierten Rechner zwei Einträge gibt. Einer mit einem aktiven Client und ein zweiter ohne Client aber mit den Active Directory Gruppen. Da die Verteilung von individueller Zusatzsoftware per AD Gruppen erfolgt ist dies ein Problem, da zwar die Collectionzuordnung erfolgt, als Ziel aber der falsche Client verwendet wird. Aktiv ist das neue Delta-Discovery (5min) von R3 und auch eine relativ kurzes Full-Discovery.

SCCM 2007 setzt (noch) 32bit Agenten ein. Daher wird auch ein Programm zuerst einmal im 32bit Kontext ausgeführt und bekommt daher über die Redirects primär Zugriff auf das syswow64 Verzeichnis. Startet man ein regedit, so wird die 32bit Variante gestartet. Es gibt Situationen, in denen man auf jeden Fall die OS native Variante starten möchte, d.h. auf einem x64 die 64bittige und analog auf einem x86 die 32bit. Dazu kann man in einer Batchdatei überprüfen ob bestimmte Kriterien erfüllt sind, oder man verwendet direkt einen (auch mir vor kurzem ) eher unbekannten Alias: sysnative.

SCCM 2007 hat eine relativ gute Verwaltung der Treiber für eine Betriebssysteminstallation (OSD), die auch automatisch erkannt und installiert werden. Gerade wenn man viel Zeit und Mühe in die Pflege dieser Liste gesteckt hat, möchte man vielleicht auch bereits installierte Systeme mit den Treibern aktualisieren.

Mir ist keine SCCM interne Möglichkeit bekannt dies umzusetzen. Auch eine versuchsweise erstellte Tasksequenz, die nur die Treiberauswahl beinhaltet bricht auf einem Zielsystem ab, da es nicht im richtigen Kontext (WinPE) ausgeführt wird.

Manchmal macht der Windows Update Dienst Probleme. Um einige Probleme zu korrigieren setzte ich schon seit längerer Zeit ein kleines Script ein:

Heute mal wieder eine kurze Powershell Zeile, um alle in Enteo hinterlegten PnP-IDs in den Driver Packages auszulesen und auszugeben.

Interessant kann diese Liste sein, um sie mit einer Enteo-externen Inventur zu vergleichen oder zu überprüfen, ob eine neue Hardware bereits unterstützt wird.

(Get-EmdbSoftwarePackage -recurse -Filter "SchemaTag=PnpPackage" |

where {$_.PnPEnabledIdList -ne $null}) |

foreach-object{$_.PnPEnabledIdList.Split(",")} > c:\temp\pnpids.txt

Zuerst wird in allen Software Paketen nach dem Typ PnPPackage gesucht. Aus diesen Ergebnissen werden alle Treiber ohne PnP Ids ausgefiltert. Das Ergebnis ist eine kommaseparierte Liste pro Treiber-Paket, die beim Komma getrennt wird. Am Ende steht eine Liste mit jeweils einer PnP Id pro Zeile: