Für die OS Installation wird in SCCM ein WinPE Bootimage eingesetzt. Über die Konsole lässt sich hier auf einfache Art und Weise zusätzliche Treiber einbinden. Relevant ist dies im Allgemeinen nur für sehr neue Netzwerk bzw. SATA Treiber, da Windows 7 von Haus aus schon sehr viele Geräte unterstützt.
Manchmal ist es schwierig den passenden Treiber zu finden. Hilfreich dabei ist die PCI Device ID. Mit dieser eindeutigen ID kann man den Hersteller (VEN_XYZ) und das entsprechende Gerät (DEV_…) über eine Google Suche ermitteln.
Um diese ID zu ermitteln muss man zuerst die Kommandozeilen Option im WinPE Boot Image aktivieren (Eigenschaften des Images).
Danach kann man per F8 eine Kommandozeile auf dem System mit den fehlenden Treibern starten und per
wmic nic get PNPDeviceID
bzw.
wmic idecontroller get deviceid
die IDs ermitteln. Ein Beispiel der Ausgabe ist im folgenden Bild dargestellt:
Momentan scheint Microsoft fleißig bei Entwicklung von Management Packs zu sein. Ein Monat passiert nichts und jetzt schon zwei Aktualisierung von zentralen Management Packs.
Diesmal war das Active Directory MP an der Reihe:
Neue Management Packs im Zeitraum zwischen 02.10.2011 und 09.10.2011
Die Änderungen beziehen sich nur auf Bugfixes. Einer Implementierung sollte somit nichts im Wege stehen.
Eine Besonderheit ist aber zu beachten: Da Windows 2000 nicht mehr supported ist, ist auch das 2000er MP nicht aktualisiert worden und nicht mehr enthalten. (Ausnahme: Der Discovery Part)
“Liebe Microsoftler,” habe ich einen Blog Post im Juni 2009 begonnen. Und heute ist mir aufgefallen, dass der damals angemeckerte Dienst vom SCOM jetzt nicht mehr “System Center Management” heißt, sondern jetzt mit dem viel sinnvolleren Text “System Center Management Health Service” im SCOM 2012 bezeichnet ist:
Also, da man nicht nur schimpfen soll, sondern auch loben: Gut so (und ich hoffe es bleibt auch im RTM so )
Juhu! Endlich wieder ein paar neue Management Packs (MP) auf der SCOM 2007 Front!. Nach langem wurde wieder das Core OS MP aktualisiert.
Folgende Änderungen wurden dabei gemacht:
The September 2011 release (version 6.0.6957.0) of the System Center Monitoring Pack for the Windows Server Operating System includes the following changes:
Optimized operating system performance collection rules.
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.
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
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 <Configuration> Bereichs)
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.
Dort gibt es zwei primäre Einstellungen:
1. Heartbeat Time: die Zeit, die zwischen zwei Heartbeats vertreichen darf, ohne dass dieser als vermisst angesehen wird.
2. Server –> Heartbeat Server Count: Die Anzahl der Heartbeats, die verloren gehen können, bevor ein Client als vermisst angesehen wird.
Standardmäßig steht die Heartbeat Time auf 180 Sekunden und der Counter auf drei. Somit darf ein Client bis zu neun Minuten weg sein, bevor dieser als fehlerhaft markiert wird.
Dabei hat der SCOM ein weiteres Feature: Sobald der Heartbeat ausgeblieben, ist Ping der Server den Client automatisch an, um herauszufinden ob eventuell nur der SCOM Dienst steht oder das komplette System weg ist. An dieses Ergebnis kann natürlich SCOM-Typisch ein Recovery Task wie z.B. ein Neustart des Diensts angehängt werden. Der Ping-Monitor hängt übrigens nicht am eigentlichen Client-Objekt, sondern an einem getrennten Objekt, der unterhalb des SCOM-Servers hängt (Client-Watcher).
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.
Die SCCM Produkt Gruppe hat zu diesem Problem bereits einen Workaround beschrieben, der anhand der Anleitung auch sehr gut umzusetzen war:
Ich arbeite als Systemingenieur in diversen Kundenprojekten bei der TechniData IT Service GmbH, die u.a. Standorte in Karlsruhe und Markdorf unterhält.
Für die OS Installation wird in SCCM ein WinPE Bootimage eingesetzt. Über die Konsole lässt sich hier auf einfache Art und Weise zusätzliche Treiber einbinden. Relevant ist dies im Allgemeinen nur für sehr neue Netzwerk bzw. SATA Treiber, da Windows 7 von Haus aus schon sehr viele Geräte unterstützt.
)
Juhu! Endlich wieder ein paar neue Management Packs (MP) auf der SCOM 2007 Front!. Nach langem wurde wieder das Core OS MP aktualisiert.
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.
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.
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.
