Die Koppelung von SCCM-Sites über Domänengrenzen hinweg
Mittwoch, 1. Juni 2011, 23:04
Abgelegt unter: Erkenntnisse | Tags: , , ,

Die Frage tauchte auf, ob es möglich sei, SCCM-Sites über Domänengrenzen zu einer Hierarchie zu verbinden. So sollen z.B. alle Pakete der übergeordneten Site (Central Site) für die Systeme der untergeordneten Site (Primary Site) bereitgestellt werden und die Systeme der untergeordneten Site aus der übergeordneten Site mitverwaltet werden. Doch die unterzuordnende Site befindet sich in einer anderen Active-Directory-Domäne, ja sogar in einem anderen Forest. Und dass zwischen den beiden Forests keine Vertrauensstellungen existieren, macht die Angelegenheit noch interessanter. Ist so ein Szenario überhaupt machbar?

Um die Antwort gleich vorweg zu nehmen: Ja, es geht. Und dies sogar erstaunlich einfach!

Nachfolgend werden die dazu notwendigen Schritte beschrieben, dabei gehe ich davon aus, dass beide Siteserver bereits mit derselben Version von SCCM installiert sind.

Notwendige Vorbereitungen

In vertrauten Umgebungen werden normalerweise die Computerobjekte der Site-Server in die passende Gruppe(n) aufgenommen, um die Kommunikation zwischen den Site-Servern zu ermöglichen. Genau dies ist jedoch in diesem Szenario nicht möglich, da das Computerobjekt des anderen Site-Server in der unvertrauten Domäne nicht sichtbar ist. Aus diesem Grund muss in jeder Domäne ein passendes Benutzerkonto erstellt werden, das für die Kommunikation verwendet werden kann.

Ich erstellte deshalb folgende beiden Benutzerkonti in der jeweiligen Domäne(die <Platzhalter> wären mit den passenden Werten zu ersetzen)

  • <Parentdomain>\SCCM-Sender-<Child>-to-<Parent>
  • <Childdomain>\SCCM-Sender-<Parent>-to-<Child>

Auf jedem Siteserver existiert eine lokale Gruppe mit dem Namen „SMS_SiteToSiteConnection_<Sitecode>“, in welche das soeben generierte AD-Benutzerkonto aufzunehmen ist, womit für die Vergabe der notwendigen Zugriffsrechte an diese Benutzerkonti gesorgt wird. Auch dies war mit wenigen Mausklicks erledigt.

Definition der Sender

Nun können die Sender konfiguriert werden, welche für die Ãœbermittlung der Daten sorgen. Dazu wird in der SCCM-Konsole zu „Site Database“, „<Site>“, „Site Settings“, „Site Settings“, „Addresses“ navigiert und dort eine neue „Standard Sender Address“ erstellt:

Die Definition der "Standard Sender Address"

Wichtig ist hier einfach, dass wir beim Sender der Parent-Site das AD-Konto der Child-Domäne konfigurieren und beim Sender der Childsite das entsprechende Konto der Parent-Site.

Austausch der Schlüssel

Innerhalb von vertrauten Active-Directory-Forests können die Sites ihre öffentlichen Schlüssel selbständig austauschen, dies muss nun in diesem Szenario manuell nachgeholt werden, da ansonsten die Sitehierarchie nicht erstellt werden kann. Dazu muss auf dem Siteserver der zukünftigen Parent-Site der Befehl

preinst.exe /KEYFORCHILD

Wir starten dazu eine CMD.exe mit Administratorrechten und wechseln ins Verzeichnis <Path-to>\Microsoft Configuration Manager\bin\i386\00000409, wo preinst.exe zu finden ist und setzen den genannten Befehl ab. Damit wird im Root-Verzeichnis der betreffenden Festplatte die Key-Datei „<Parentsitecode>.ct5“ erstellt.

Auf dem Siteserver der zukünftigen Child-Site muss nun der entsprechende Befehl

preinst.exe /KEYFORPARENT

ausgeführt werden, womit auf diesem im Rootverzeichnis der betreffenden Festplatte die Key-Datei „<Childsitecode>.ct4“ erstellt wird.

Randbemerkung: Als ich dies im konkreten Falle durchführen wollte, wurde ich bei der Ausführung von preinst.exe plötzlich mit folgender Fehlermeldung konfrontiert: „This site’s public key has not been created, and configured yet.  Therefore, keys cannot be dumped from this site.  Please allow Hierarchy Manager to correct the situation, and try again.„  Diese Meldung lässt ein gröberes Problem befürchten, hat aber eine einfache Ursache: Die CMD.exe wurde nicht mit Administrator-Rechten gestartet. Mit Administrator-Rechten funktionierte es problemlos…

Die beiden Key-Files müssen nun manuell ausgetauscht werden:

Der öffentliche Schlüssel der Child-Site muss auf der Parent-Site importiert werden. Dazu muss die Datei <Childsitecode>.CT4 in den Ordner  <Path-to>\Microsoft Configuration Manager\inboxes\hman.box auf dem Parentsite-Server kopiert, die <Parentsitecode>.CT5 in den entsprechenden Ordner der Childsite kopiert werden.

Die Komponente „SMS_Hierarchy_Manager“ importiert nun den jeweiligen Schlüssel, was in <Path-to>\Microsoft Configuration Manager\logs\hman.log protokolliert wird.

Damit ist nun das Gröbste geschafft, nun muss nur noch in der Childsite die entsprechende Parent-Site konfiguriert werden, wozu wir in den „Properties“ der Childsite den Button „Set Parent Site“ finden. Sobald hier die Parent-Site konfiguriert wurde, beginnen die Siteserver mit dem Austausch der Daten, was z.B. in folgenden Protokollen mitverfolgt werden kann:

  • hman.log
  • sender.log
  • replmgr.log
  • objreplmgr.log
  • distmgr.log

Tauchen dort keine Fehlermeldungen auf und die Replikation läuft wunschgemäss, ist der Sprung über die Domänengrenze geschafft und die Childsite in der fremden AD-Domäne kann nun wie jede andere Childsite von der Parent-Site her verwaltet werden.



Der Fall des hängenden Update zum MS10-070/KB2416472
Dienstag, 1. März 2011, 22:53
Abgelegt unter: Der gelöste Fall | Tags: , , , , ,

Vor zwei Wochen erreichten uns – während ich in den Ferien weilte -  mehrere Meldungen von Benutzern, die allesamt dasselbe Problem feststellten, was dann auch von Administratoren-Kollegen verifiziert werden konnte:

Download hängt stundenlang bei 66%

Auf allen betroffenen Geräten blieb der Download des  „Sicherheitsupdate für Microsoft .NET Framework 4“ (MS10-070/KB2416472) bei 66% stehen, worauf sich in dem abgebildeten Dialog stundenlang nichts mehr bewegte, bis die Benutzer entnervt auf „Cancel“ klickten. Leider dauerte es dann jeweils nicht allzulange, bis die Installation des Updates erneut gestartet wurde, da dieses unseren Client zur Installation zugewiesen ist und die entsprechende Zeitpunkt für das Assignment bereits deutlich in der Vergangenheit liegt.

Dieser Effekt trat im laufenden Betrieb der Clients auf und hat nichts mit den Problemen beim Schritt „Install Updates“ in Tasksequenzen zu tun, den wir in unserer Umgebung leider auch beobachten.

Auf den betroffenen Geräten konnte – wie meine Admin-Kollegen rasch herausfanden – das fragliche Update als Workaround problemlos über Microsoft-Update installiert werden, worauf dann die nervenden Installationsversuche durch den Configuration Manager Client aufhörten.

Zurück aus den Ferien habe ich dann versucht, die Ursache dieser Downloadprobleme zu ergründen und wurde auch recht rasch fündig. Die Geschichte des betroffenen Updates ist relativ lang; so ist auch im entsprechenden Security-Bulletin MS10-070 zu lesen, dass dieses inzwischen viermal überarbeitet wurde.

Beim Update KB2416472 handelt es sich um ein gebündeltes Update, d.h. unter dem Eintrag dieses Updates werden in der Konsole mehrere Updates aufgelistet. Und genau hier lag das Problem:

Unvollständiges Update zum KB2416472

Wie man im obigen Screenshot erkennen kann, wurden in der Konsole drei Updates zum KB2416472 aufgelistet, dabei handelt es sich um die Varianten für x86-, x64- und Itanium-Systeme. Alle drei Updates werden als „Downloaded: yes“ ausgewiesen, wie das der grüne Rahmen zeigt. Betrachtet man nun jedoch die „Content Information“ zu einem der drei Updates, kann man sehen, dass hier mehrere Updates gebündelt sind. Und wie das im roten Rahmen zu sehen sind, sind zwei dieser drei Updates heruntergeladen, das dritte jedoch nicht. „Zwei von drei Updates?“ Genau: „66%!“

Wie zudem im blauen Rahmen zu sehen ist, hat das fehlende Update zudem eine deutlich höhere Content-ID als die anderen beiden, was den Schluss nahelegt, dieses erst später nachgeliefert wurde. Und das passt auch zu unseren Beobachtungen: Schliesslich wurde MS10-070 bereits am 28. September 2010 publiziert und unzählige unserer Clients konnten dieses Update in den vergangenen Monaten problemlos installieren. Erst in jüngster Zeit wurden hier Probleme gemeldet.

Die jüngsten Installationsversuche dieses Updates schlugen also fehl, da die Clients versuchten, auch den dritten, nicht verfügbaren Teil beim Distribution Point abzuholen. Dies sieht man bestens im UpdatesHandler.log eines betroffenen Gerätes:

Bundle update (8b86deae-c862-4405-8fca-3a2dcfae1de0) is requesting download from child updates for action (INSTALL)        UpdatesHandler        09.02.2011 09:33:12        2876 (0x0B3C)
Starting download on action (INSTALL) for Update (57529fa0-4c49-458f-bd14-08c1c87679d7)        UpdatesHandler        09.02.2011 09:33:12        2876 (0x0B3C)
Contents already available for the update (bfa8bdd3-cf5c-44e9-b937-98aad87e0451).        UpdatesHandler        09.02.2011 09:33:12        2876 (0x0B3C)
Contents already available for the update (ee89b5c2-ac3b-4216-9bb2-e0654ef63626).        UpdatesHandler        09.02.2011 09:33:12        2876 (0x0B3C)
CancelJob received from SDM.        UpdatesHandler        09.02.2011 15:35:52        4908 (0x132C)

So zeigt dieser Logauszug, dass das „Bundle Update“ den Download der „Child-Updates“ verlangt.  Zwei Inhalte sind „already available“, der dritte Inhalt soll jedoch heruntergeladen werden. Doch dann geschieht nichts mehr, bis der der betroffene Benutzer unzählige Stunden später auf „Cancel“ geklickt hat.

Dies erklärt auch, weshalb das Problem auch durch manuelle Installation via Microsoft Update gelöst werden konnte, denn dort dürften ja – im Gegensatz zu unserem Distribution Point – alle benötigten Files vorhanden gewesen sein.

Die definitive Lösung dieses Problems war nun trivial: Ich habe nun die betreffenden Updates zum KB2416472 nochmals heruntergeladen und die Distribution Points aktualisiert. Danach waren die Updates komplett, wie im grünen Rahmen zu sehen ist:

Vervollständigtes Update zum KB2416472

Auch war nun das Update mit der im Protokoll genannten GUID 57529fa0-4c49-458f-bd14-08c1c87679d7 tatsächlich auf unseren Distribution Points zu finden, die Hänger bei 66% waren beseitigt.

Beim zusätzlichen Update handelte es sich übrigens im konkreten Falle um das „Update für Microsoft .NET Framework 4 für Probleme bei ausstehenden Dateiumbenennungsvorgängen“ zum Microsoft KB-Artikel 2473228.



Wenn der SCCM Reporting Point einer anderen Site bockt…
Mittwoch, 19. Januar 2011, 22:27
Abgelegt unter: Erkenntnisse | Tags: , , , ,

Wie ich im letzten November geschrieben habe, aktualisieren immer mal wieder Anwendungen auf neue Versionen. Wenn derartige Deployments von Anwendungsupdates alle Child-Sites betreffen, steuern wir diese aus unserer Central Site. Und damit auch die Administratoren der Child-Sites bequem kontrollieren können, welche ihrer Clients noch nicht aktualisiert wurden, wollte ich diesen einige vorkonfigurierte Reports zur Verfügung stellen. „Vorkonfigurierte Reports?“

Die meisten Reports werden ja mit irgendwelchen Parametern aufgerufen, so z.B. auch der Report „Computers with specific software registered in Add Remove Programs“, den ich zu diesem Zwecke herangezogen habe. Dieser Report will nun mit Parametern  für den „Software Title“ (d.h. den Namen, unter welchem die Software eingetragen ist) und die auszuwertende Collection aufgerufen werden. Und diese Werte jedesmal nachzuschlagen, finde ich noch ziemlich mühsam, denn gerade beim „Software Title“ muss der exakte Wert angegeben werden, ansonsten der Report ein leeres Ergebnis liefert. Hat man nun den gewünschten Report erhalten, lassen sich noch die Spalten wunschgemäss sortieren. Dann findet man in der Adresszeile des Browsers die genaue URL, welche diesen Report generiert, d.h. irgendwas in der Form:

http://<siteserver>/SMSReporting_<sitecode>/Report.asp?ReportID=92&displayname=<genaue%28!%29%20Bezeichnung%20der%20Software>&CollID=<collection>&SortRs1Col=1&SortRs1Dir=1

Kennt man diese URL, lässt sich der entsprechende Report jederzeit wieder mit den aktuellen Daten neu generieren, ohne dass man wieder umständlich die passenden Parameter zusammensuchen muss.  Und diese URL lässt sich also als Lesezeichen im Browser ablegen, oder – wie ich das vorgesehen hatte – auf einer Intranetseite verlinken. Und so suchte ich alle notwendigen URLs zusammen, erstellte die Intranetseite, testete erfolgreich alle Links und kontaktierte einen unserer Admins einer Childsite, damit er sich das mal ansehen möge. Doch am anderen Ende der Telefonleitung blieb die grosse Freude aus. Stattdessen hiess es nur: „Aehemm…. ich erhalte da bloss einen Error 500!“

Bei mir funktionierten immer noch alle Links perfekt, beim Kollege Child-Site-Admin jedoch nicht. Sogleich vermutete ich ein Rechteproblem, denn bei uns haben alle Child-Site-Admins ausschliesslich Adminrechte für ihre eigene Site und bloss ein Leserecht für die Central-Site und alle anderen Sites. Doch die Rechte in SCCM waren korrekt vergeben; auch nach mehrmaligem Nachkontrollieren kam ich zum Schluss, dass der Kollege alle benötigten Rechte haben müsste, um die Reports abrufen zu können. Doch irgendwas klemmte da noch immer…

Doch dann fiel mir ein: „Error 500!“. Das bedeutet ja üblicherweise nicht „Access denied“, sondern „Internal Server Error“! Also warf ich mal einen Blick in das Webserver-Protokoll und wurde da tatsächlich fündig:

Error 500: ASP_0178_:_80070005|Server.CreateObject_Access_Error

Nach längerer Suche fand ich dann eine Diskussion über ein Problem „Error accessing reporting services – DCOM“ in den Microsoft Technet Foren.  Als Lösung wird dort die Deaktivierung der „User Account Control“ vorgeschlagen, was ich allerdings nicht unbedingt tun wollte. Doch im letzten Beitrag schrieb der Benutzer „EddieAdams“:

I was having the exact same problem but solved it by adding ‚Authenticated Users‘ to the local ‚SMS Reporting Users‘ group on the SCCM Server.

Das war ein einfacher Lösungsvorschlag, den ich sofort umsetzte. Doch der Kollege sah weiterhin bloss „Error 500!“

Also suchte ich weiter und stiess dann auf den Artikel „Error message when you try to use the SMS Web Reporting Tool: „Server object error ‚ASP 0178 : 80070005′““ in der Microsoft Knowledge Base. Dieser beschreibt exakt das angetroffene Problem, bezieht sich zwar explizit auf den Server 2003 SP1, führte aber auch unter Server 2008 R2 zur Lösung:

This problem occurs because the following conditions are true:

  • You are a member of the SMS Reporting Users security group on the Windows Server 2003 SP1-based computer that is acting as the SMS site server.
  • You are not a member of the local Administrators group on the Windows Server 2003 SP1-based computer that is acting as the SMS site server.

In this case, the DCOM permissions are locked down on the Windows Server 2003 SP1 site server.

Genau dies trifft im vorliegenden Fall zu: Mein Kollege Child-Site-Admin ist zwar nun Mitglied der Gruppe „SMS Reporting Users“, seit ich dort „Authenticated Users“ hinzugefügt hatte, doch ist er keineswegs lokaler Administrator unseres Central-Site-Servers. Und so setzte ich die im Artikel beschriebene Anleitung um:

  1. Log on to the Windows Server 2003 SP1 computer that is acting as the SMS site server by using an account that has administrative permissions.
  2. Click Start, click Run, type dcomcnfg, and then click OK.
  3. In the Component Services MMC snap-in, expand Component Services, expand Computers, right-click My Computer, and then click Properties.
  4. In the My Computer Properties dialog box, click the COM Security tab.
  5. Under Launch and Activation permissions, click Edit Limits.
  6. In the Launch Permission dialog box, make sure that the Everyone group has Remote Launch and Remote Activation permissions.
  7. In the Component Services MMC snap-in, expand My Computer, expand DCOM Config, right-click SMS_Reporting_Point, and then click Properties.
  8. In the SMS_Reporting_Point Properties dialog box, click the Security tab. Under Launch and Activation Permissions, select Customize, and then click Edit.
  9. In the Launch Permission dialog box, make sure that the SMS Reporting Users local group has following permissions:
    • Local Launch
    • Remote Launch
    • Local Activation
    • Remote Activation

Component Services -> SMS_Reporting_Point Properties -> Launch and Activation Permissions

Und tatsächlich: Nun können auch die Administratoren unserer Childsites die von mir vorbereiteten Reports auf dem Central Site Server abrufen!



Wenn der SCCM PXE Point plötzlich bockt…
Mittwoch, 1. Dezember 2010, 19:24
Abgelegt unter: Erkenntnisse | Tags: , , ,

Nachdem wir in der letzten Zeit problemlos unzählige neue Geräte via SCCM installieren konnten, erreichte mich heute morgen der Hilferuf eines Kollegen: „Was gestern noch ging, wolle heute nimmer funktionieren…“ Er erhalte folgende Fehlermeldung, kurz nachdem die zu installierende Maschine das WindowsPE gestartet habe:

The certificate associated with this media has expired!

„Aber ich benutze doch gar kein Medium, sondern habe via PXE gebootet“, fügte dann der Kollege noch hinzu. So machte ich mich auf die Fehlersuche und warf zuerst mal einen Blick in den Site Status, wo sich der Component Status des „SMS_PXE_SERVICE_POINT“ tief rot zeigte:

Komponente "SMS_PXE_SERVICE_POINT" meldet Errors!

Ein Blick in die dazugehörenden Status Messages zeigte dann sofort, dass es offenbar ein Problem mit dem entsprechenden PXE-Zertifikat gibt:

The SMS PXE Certificate used for PXE clients is not valid. Please provide a valid certificate.

Ich schaute mir dann das entsprechende Zertifikat an und siehe da:

Der 30. November 2011 war gestern!

Die Ursache der Fehlermeldung war nun sonnenklar. Das bisherige Zertifikat war genau bis gestern abend um 22:30 Uhr gültig. Kein Wunder also, dass  heute entsprechende Fehlermeldungen generiert werden. Aber wie erneuert man das PXE-Zertifikat? Mir schwante böses: seitenlange Technet-Artikel mit unzähligen vorzunehmenden Schritten, …

Doch nein: Nichts dergleichen war nötig. Ein kurzer Blick in die Eigenschaften des „ConfigMgr PXE service point“ zeigte mir den Ablaufzeitpunkt des Zertifikates von gestern abend:

Eigenschaften von "ConfigMgr PXE service Point"

„Da könnte man doch einfach mal probieren, ein neues Datum zu setzen…“, war mein erster Gedanke, was ich sogleich machte: Und siehe da:

Ein neues Zertifikat wurde erstellt!

Das bisherige Zertifikat wurde auf „blocked“ gesetzt, daneben wird nun ein neues Zertifikat aufgelistet. Und schon funktionieren auch die Installationen via PXE wieder… Hoffentlich weiss ich Anfangs 2012 noch, was zu tun ist, wenn dasselbe „Problem“ wieder auftaucht…



Aktualisierung von x86- und x64-Software via System Center Configuration Manager
Donnerstag, 18. November 2010, 15:04
Abgelegt unter: Erkenntnisse | Tags: , , , ,

Wenn ein Hersteller eine neue Version einer von uns verwendeten Software bereitstellt, gehen wir immer nach demselben Schema vor, falls wir die neue Softwareversion bereitstellen wollen:

  • Wir erstellen ein aktualisiertes Paket in der Testumgebung und testen dieses. Dabei kontrollieren wir nicht nur die Funktionstüchtigkeit einer Neuinstallation, sondern überprüfen auch, ob bestehende Installationen vonVorversionen der betreffenden Software aktualisiert werden können.
  • Sobald wir von der Tauglichkeit des neuen Paketes überzeugt sind, stellen wir dieses als zusätzliches Paket in der Produktionsumgebung bereit. Das Paket der Vorversion bleibt daneben unverändert erhalten.
  • Ab diesem Zeitpunkt wird dann normalerweise auf den Clients die neue Version installiert, doch ein Rückgriff auf die Vorversion wäre nötigenfalls immer noch möglich, falls mit der neuen Version unerwartete Probleme auftauchen sollten.
  • Zu einem bestimmten Zeitpunkt – bei uns normalerweise gebündelt mit der monatlichen Microsoft-Updaterunde -  wird dann die Aktualisierung der auf den Clients installierten Vorversionen in Angriff genommen. Hierzu wird unseren Benutzern die Installation des Updates eine Woche lang angeboten; während dieser Zeit kann der Benutzer sich den für ihn geeigneten Installationszeitpunkt selber auswählen. Danach wird die Installation des Updates per Assignment durchgesetzt.
  • Sobald die Aktualisierung aller Clients abgeschlossen ist, kann das veraltete Paket der Vorversion entsorgt werden. (Aber gerade bei diesem Schritt lassen wir uns üblicherweise tüchtig Zeit… )

Wie man Softwarepakete via SCCM verteilt, dürfte wohl jedem Administrator bekannt sein, der sich mit diesem Thema beschäftigt. Doch wie funktioniert der Schritt „Aktualisierung installierter Vorversionen“ genau?

Hierzu erstellen wir jeweils eine Collection, an welche die Installation des Updates dann advertised bzw. assigned werden kann. Die Mitgliedschaft in dieser Collection wird jeweils anhand einer Query definiert, welche bei uns immer folgenden Aufbau hat: „Gesucht sind alle Clients, die eine bestimmte Software installiert haben, jedoch nicht in der von uns aktuell gewünschten Version“. Wie dies in einem konkreten Fall aussieht, möchte ich anhand des kürzlich publizierten Update „Java Version 6 (Update 22) zeigen:

Ein x86-Client mit einer veralteten Java-Version

Wir erkennen hier im Bereich „Programme und Funktionen“ in der Systemsteuerung eines Clients, dass auf diesem noch das Update 20 von Java installiert ist. Genau diese Information können wir auch für folgende WQL-Query zur Definition einer Collection in SCCM verwenden:

select SMS_R_SYSTEM.ResourceID, SMS_R_SYSTEM.ResourceType, SMS_R_SYSTEM.Name, SMS_R_SYSTEM.SMSUniqueIdentifier, SMS_R_SYSTEM.ResourceDomainORWorkgroup, SMS_R_SYSTEM.Client
from SMS_R_System
inner join SMS_G_System_ADD_REMOVE_PROGRAMS
on SMS_G_System_ADD_REMOVE_PROGRAMS.ResourceID = SMS_R_System.ResourceId
where SMS_G_System_ADD_REMOVE_PROGRAMS.DisplayName like "Java%"
and SMS_G_System_ADD_REMOVE_PROGRAMS.Version not like "6.0.220%"

Wir suchen also nach Programmen mit der Zeichenkette „Java“ am Anfang des Anzeigenamens, die nicht eine Versionsbezeichnung haben, welche mit „6.0.220“ beginnt. Bei der Versionsnummer gilt es zu beachten, dass es sich hier um eine Zeichenkette und nicht um einen Wert handelt; eine Query in der Form „Version < 6.0.220“ funktioniert nicht. Dass man auch bei der Wahl des Suchbegriffes im Anzeigenamen die nötige Vorsicht walten lassen sollte, dürfte sich von selbst verstehen. Schliesslich möchte man ja nicht ein Java-Update auf einen Client installieren, weil dort auch noch zufälligerweise irgendein „Java-Free-Editor“ (und dummerweise leider nicht in der Version 6.0.220.7) vorhanden ist. Den Suchbegriff sollte man also möglichst spezifisch definieren, nötigenfalls lässt sich auch noch ein Hersteller mit einer weiteren Klausel in der Form „and ..._ADD_REMOVE_PROGRAMS.Publisher like "...%"“ einbeziehen.

Dies funktionierte im vorliegenden Fall bestens und schon hatten wir die passende Collection aller Clients, welche dringend ein Java Update nötig hätten, bereit. Wirklich?

Nein, leider nicht ganz. Denn wir haben nicht nur 32bit (d.h. x86)-Systeme im Einsatz, sondern es sind auch 64bit (d.h. x64)-Systeme vorhanden. Und da sieht das Ganze leicht anders aus:

Ein x64-Client mit zwei veralteten Java-Versionen

Wir erkennen in diesem Screenshot, dass auf diesem Client zwei Java Versionen installiert sind; zwar in beiden Fällen die Version 6u20, aber einmal als 32bit- und einmal als 64bit-Variante. Also galt es dafür zu sorgen, dass überall dort, wo die 32bit-Version installiert ist, auch das 32bit-Update installiert wird und überall dort, wo die 64bit-Version vorhanden ist, auch das entsprechende 64bit-Update geliefert wird.

Leider passt die oben angegebene WQL-Query auch auf „Java(TM) 6 Update 20 (64-bit)“. Und wir beabsichtigen nicht, auf allen Clients die 32bit-Version nachzuinstallieren, auf denen nur die 64bit-Variante installiert ist. Zudem fehlt noch eine passende Collection für die Aktualisierung der 64bit-Variante. Also flugs eine zweite Collection erstellt und die erste modifiziert!

select SMS_R_SYSTEM.ResourceID, SMS_R_SYSTEM.ResourceType, SMS_R_SYSTEM.Name, SMS_R_SYSTEM.SMSUniqueIdentifier, SMS_R_SYSTEM.ResourceDomainORWorkgroup, SMS_R_SYSTEM.Client
from SMS_R_System
inner join SMS_G_System_ADD_REMOVE_PROGRAMS
on SMS_G_System_ADD_REMOVE_PROGRAMS.ResourceID = SMS_R_System.ResourceId
where SMS_G_System_ADD_REMOVE_PROGRAMS.DisplayName like "Java%"
and SMS_G_System_ADD_REMOVE_PROGRAMS.DisplayName not like "Java%(64-bit)"
and SMS_G_System_ADD_REMOVE_PROGRAMS.Version not like "6.0.220%"

select SMS_R_SYSTEM.ResourceID, SMS_R_SYSTEM.ResourceType, SMS_R_SYSTEM.Name, SMS_R_SYSTEM.SMSUniqueIdentifier, SMS_R_SYSTEM.ResourceDomainORWorkgroup, SMS_R_SYSTEM.Client
from SMS_R_System
inner join SMS_G_System_ADD_REMOVE_PROGRAMS
on SMS_G_System_ADD_REMOVE_PROGRAMS.ResourceID = SMS_R_System.ResourceId
where SMS_G_System_ADD_REMOVE_PROGRAMS.DisplayName like "Java%(64-bit)"
and SMS_G_System_ADD_REMOVE_PROGRAMS.Version not like "6.0.220%"

Und jetzt: sind wir nun bereit für die Verteilung der beiden Updates? Nein, leider immer noch nicht…

Im Falle der ersten Collection für die 32bit-Variante scheint alles bestens: Es sind genau diejenigen Systeme in der Collection enthalten, welche das 32bit-Update nötig haben. Die zweite Collection ist … leer!?!

Dabei wussten wird doch ganz genau, dass es bei uns Systeme gibt, welche die 64-bit-Java-Version installiert haben. Nach einer längeren Suche nach der Ursache entdeckten wir dann des Rätsels Lösung: Es gibt nicht nur eine Tabelle „SMS_G_System_ADD_REMOVE_PROGRAMS„, sondern auch noch eine zweite Tabelle „SMS_G_System_ADD_REMOVE_PROGRAMS_64„. Die Angaben über die auf einem Client installierte Software werden also in separaten Tabellen für 32-bit- und zu 64-bit-Software gespeichert. Kein Wunder also, dass unsere obige Query ein unbrauchbares Ergebnis liefert und demzufolge die Collection leer bleibt, denn wir suchen schlicht und einfach in der falschen Tabelle!

Wir haben dann die Collection für die 64-bit-Java-Version nochmals angepasst, worauf diese dann tatsächlich das gewünschte Ergebnis lieferte:

select SMS_R_SYSTEM.ResourceID, SMS_R_SYSTEM.ResourceType, SMS_R_SYSTEM.Name, SMS_R_SYSTEM.SMSUniqueIdentifier, SMS_R_SYSTEM.ResourceDomainORWorkgroup, SMS_R_SYSTEM.Client
from SMS_R_System
inner join SMS_G_System_ADD_REMOVE_PROGRAMS_64
on SMS_G_System_ADD_REMOVE_PROGRAMS_64.ResourceID = SMS_R_System.ResourceId
where SMS_G_System_ADD_REMOVE_PROGRAMS_64.DisplayName like "Java%(64-bit)"
and SMS_G_System_ADD_REMOVE_PROGRAMS_64.Version not like "6.0.220%"

Endlich hatten wir die notwendigen Collections definiert und die Verteilung der beiden Updates konnte starten. Erst später merkten wir dann noch, dass im Falle der ersten Collection für die 32-bit-Java-Version die Erweiterung ..._ADD_REMOVE_PROGRAMS.DisplayName not like "Java%(64-bit)" gar nicht nötig gewesen wäre, da ja in der betreffenden Tabelle gar keine Angaben zu installierten 64bit-Versionen gespeichert sind.



Wenn der SCCM Distribution Point bockt…
Sonntag, 31. Oktober 2010, 21:30
Abgelegt unter: Erkenntnisse | Tags: , , , ,

Vor einiger Zeit wurde ich von einem Kollegen mit dem Problem konfrontiert, dass bei der Installation eines Softwarepaket über den System Center Configuration Manager 2007 der Download mittendrin ohne klar ersichtlichen Grund hängenbleibe. Doch wenn man im Advertisement von „Download content from distribution point and run locally“ auf „Run program from distribution point“ umstelle, könne das Paket problemlos installiert werden. Dies betreffe jedoch nur die eine Site, in einer anderen Site unserer Sitestruktur könne zudem dasselbe Paket problemlos auf beide Arten installiert werden. „Für den Installer dieser Applikation spiele es keine Rolle, ob er lokal oder über einen UNC-Pfad ausgeführt werde; beides funktioniere problemlos, wie er getestet habe. Und die verwendeten Dateien in den Paketen seien doch in allen Fällen und auf allen Distribution Points dieselben und stammten vom selben Source-Verzeichnis“, konstatierte der verzweifelte Kollege. „Ja schon, aber….“, begann meine Antwort.

Auch wenn die Dateien tatsächlich in allen Fällen dieselben sind, ist der Weg, wie die Dateien vom Server zum Client transportiert werden, grundverschieden. Im Falle des „Run program from distribution point“ greift der Client via SMB (d.h. normalen Fileserver-Zugriff) auf den Distribution Point zu. Im Falle von „Download content from distribution point and run locally“ will der Client jedoch die Dateien via BITS (d.h. den „Background Intelligent Transfer Service“) vom Server beziehen, womit auch der IIS („Internet Information Server“ des Distribution Point ins Spiel kommt. Somit liegt der Verdacht nahe, dass es sich beim vorliegenden Problem gar nicht um ein SCCM, sondern ein IIS-Problem handelt.

Denn der IIS blockt standardmässig bestimmte Dateierweiterungen, womit Dateien dieser Typen in der IIS-Standardkonfiguration nicht via BITS heruntergeladen werden können. Dies wird auch im Technet-Artikel „Konfigurieren von Windows Server 2008 für Standortsysteme“ beschrieben:

Wenn an BITS-fähige Verteilungspunkte verteilte Paketquelldateien Dateierweiterungen enthalten, die in IIS 7.0 standardmäßig blockiert sind, muss der Abschnitt „requestFiltering“ der Datei „applicationHost.config“ so geändert werden, dass die erforderlichen Dateierweiterungen zugelassen werden.

Und dies geschieht auf folgende Art und Weise: In der Datei „applicationHost.config“ im Verzeichnis „%windir%\System32\inetsrv\config\“ des Distribution Points muss der Abschnitt „<requestFiltering>“ gesucht werden. In diesem Abschnitt sind Einträge in der folgenden Art zu finden:

<add fileExtension=".mdb" allowed="false" />

Wird hier „false“ durch „true“ ersetzt, die Datei „applicationHost.config“ danach gespeichert und der IIS neu gestartet, können nun auch Dateien mit der Endung „.mdb“ über BITS übertragen werden. Und so kann diese Einstellung für jeden benötigten Dateityp vorgenommen werden. Kandidaten in unserer Umgebung waren primär Dateierweiterungen wie „.config“, „.java“, „.mdb“ und „.ldf“. Natürlich lässt sich dies auch gleich pauschal lösen, indem alle entsprechenden Zeilen auskommentiert oder gelöscht werden, denn für alle nicht aufgeführten Dateitypen ist der Transfer gemäss der Default-Einstellung erlaubt. Man muss sich einfach bewusst sein, dass man durch derartige Anpassungen die Angriffsfläche des Servers vergrößert, zumal die Änderungen für alle Websites auf dem jeweiligen Server gelten.

Ganz abgesehen davon, dass man bei der Installation eines neuen Siteservers selten im voraus weiss, welche Dateitypen dann tatsächlich benötigt werden, verschweigt der besagte Technet-Artikel jedoch einen Punkt, der uns schon mehrfach Probleme verursacht hat:

Es gibt nicht nur bestimmte Dateiendungen, die standardmässig geblockt werden, sondern auch Pakete, welche ein Unterverzeichnis „bin“ haben, können in der IIS-Standardkonfiguration nicht via BITS heruntergeladen werden. Hierzu findet man in derselben Datei „applicationHost.config“ etwas weiter unten einen Abschnitt „hiddenSegments“ mit den dazugehörenden Einträgen in der Form:

<add segment="bin" />

Wird diese Zeile (resp. die passende Zeile bei anderen blockierten Verzeichnisnamen) gelöscht, die geänderte Datei gespeichert und der IIS neu gestartet, können danach auch Pakete mit „bin“-Verzeichnissen über BITS ausgeliefert werden.

Dass in unserem Problemfall der Download von einem Distribution Point geklappt hat und vom anderen nicht, lag schlicht und einfach daran, dass die notwendigen Modifikationen der Datei „applicationHost.config“ auf dem einen Server bereits vorgenommen, auf dem anderen jedoch unterlassen wurden.

Bei der Aufarbeitung dieser Thematik als Blogbeitrag bin ich noch über weitere Blogs bzw. Diskussionen gestossen, welche ähnliche Probleme beschreiben. Diese habe ich in unserem Umfeld zwar nicht direkt angetroffen, doch ich denke, dass die abschliessende Erwähnung dieser Beiträge und Links in diesem Zusammenhang durchaus Sinn macht:



Wenn noch SCCM-Pakete auf einem gelöschten Distribution Point liegen…
Freitag, 15. Oktober 2010, 21:32
Abgelegt unter: Erkenntnisse | Tags: , , ,

Kürzlich entfernte ich einen nicht mehr gebrauchten Distribution Point. Dies ging ruckzuck: Flugs im „Site Management“ unter den „Site Systems“ der entsprechenden Site den betreffenden Server ausgewählt und die Rolle „ConfigMgr Distribution Point“ entfernt. Fertig!

Fertig? Nein, leider nicht ganz…

Der Distribution Point wurde überall aus den Listen entfernt und man konnte auf diesem auch keine Pakete mehr verwalten. Auf den ersten Blick schien alles in bester Ordnung zu sein. Auf den zweiten Blick hingegen…

Immer wieder tauchten seither Fehlermeldungen auf, dass ein bestimmtes Paket auf dem betreffenden Distribution Point nicht bereitgestellt oder entfernt werden konnte. Und wenn man dann die betreffenden Pakete in der Konsole betrachtete, war tatsächlich der betreffende Distribution Point noch im „Package Status“ aufgelistet, zumeist mit einem Status „Removal Pending“. Dabei war doch dieser Distribution Point längst gelöscht und der entsprechende Server ausrangiert und entsorgt.

Was nun?

Ein entsprechender Artikel „How to Remove a Distribution Point“ aus dem Microsoft Technet half etwas weiter, da dort folgendes dokumentiert ist:

1. Remove all distribution package folders and the SMSPKGSIG signature folder from the distribution point computer.
Important: You must manually remove these components before removing the distribution point role.

Tja, hinterher ist man immer schlauer. Bloss war es etwas schwierig für mich, diese Anweisung nachträglich umzusetzen, da der Distribution Point längst weg war.

Da ich vermutete, dass ich nicht der einzige bin, der einen Distribution Point gelöscht hat, bevor er die Packages von diesem Distribution Point entfernt hatte, suchte ich weiter und fand einen Thread in den System Center Foren von Microsoft, bei welcher dieses Problem diskutiert wurde. Als Lösung wurde dabei auf einen Beitrag im „System Center WebLog by Russ Slaten“ verwiesen, dessen Titel „Removing a retired DP from all your packages“ vielversprechend aussah.

Dieser Beitrag beschreibt, dass das Entfernen der Rolle „Distribution Point“ nicht auch automatisch die Pakete von diesen Distribution Point entferne. Man müsse vorgängig die Pakete vom Distribution Point entfernen, was ziemlich mühsam werden kann, wenn man eine grössere Menge von Paketen auf dem betreffenden Distribution Point bereitgestellt hat. Netterweise stellt Russ Slaten bei dem betreffenden Beitrag ein VB-Skript bereit, mit dem diese Aufgabe automatisiert durchgeführt werden kann. Die Angabe der Namen des Site Servers und des leerenden Distribution Points als Parameter bei Aufruf seines Skriptes „SMSDPClean.vbs“ reichen, und schon würden alle Pakete vom betreffenen Distribution Point entfernt werden.

Wie ich dann leider herausfinden musste, funktioniert dieses Skript problemlos, zumindest solange der Distribution Point noch nicht vom Netzwerk entfernt wurde. Das Skript deckt zwar mit einer kleinen vorzunehmenden Modifikation den Fall ab, dass ein Distribution Point schon gelöscht wurde, doch in meinem Falle mit dem bereits entsorgten Distribution Point half das Skript nicht wirklich weiter.

Langsam aber sicher fragte ich mich, weshalb beim Entfernen der Rolle „Distribution Point“ keine entsprechenden Warn- oder Fehlermeldungen erscheinen, die darauf hinweisen, dass man diese Rolle nicht entfernen solle bzw. könne, da diesem Distribution Point noch Packages zugewiesen seien. Wehmütig dachte ich an den Assistenten, der beim Löschversuch einer Collection erscheint, der auf detaillierteste Weise beschreibt, was alles geschehen wird, wenn man diese Collection löscht.

Jegliches Sinnieren über mögliche Unzulänglichkeiten der SCCM-Konsole half mir jedoch nicht weiter. Ich hatte ein Problem, und das sollte gelöst werden! Also las und suchte ich weiter und stiess auf den Artikel „Deletion of Orphaned Distribution Points“ von Brett Wilms in seinem „System Management Blog“. Und dieser Beitrag half tatsächlich weiter!

Doch bevor ich die Lösung des Problemes präsentieren kann, ist nun ein Warnhinweis fällig:

Die direkte Modifikation einer SCCM-Datenbank wird von Microsoft grundsätzlich nicht unterstützt, ausser sie erfolgt direkt auf Anweisung der Microsoft Support Services. Die beschriebene Lösung hat beim Autor dieses Artikels funktioniert und wird als Beispiel publiziert, wie die Problematik gelöst werden könnte. Die unsachgemässe Anwendung der beschriebenen Lösung kann negative Folgen auf eine SCCM-Umgebung haben. Testen Sie die beschriebene Lösung unbedingt in Ihrer Testumgebung, bevor sie diese auf eigene Verantwortung und eigenes Risiko in Ihrer Produktionsumgebung anwenden. Bitte wenden Sie diese Lösung in Ihrer Umgebung nur genau dann an, wenn Sie wissen was sie tun, und kontaktieren Sie die Microsoft Support Services bei jeglicher Unsicherheit.

Mit Hilfe des SQL Server Management Studio konnte ich mit Hilfe der nachfolgenden beiden Queries sehen, welche Einträge zum fraglichen Distribution Point noch in der Datenbank vorhanden waren, wobei natürlich <DistributionpointName> durch den Namen des gelöschten Distribution Points zu ersetzen ist:

SELECT * FROM PkgServers WHERE NALPath like '%<DistributionpointName>%'

SELECT * FROM PkgStatus WHERE PkgServer like '%<DistributionpointName>%'

Als ich mich davon überzeugt hatte, dass diese beiden Queries tatsächlich genau (und nur!) die Einträge zum gelöschten Distribution Point lieferten, und ich mich zudem vergewissert hatte, dass ich ein korrektes und aktuelles Backup der betreffenden Site vorliegen hatte, wagte ich es, die folgenden beiden Queries zu starten, um die Spuren des gelöschten Distribution Points in der Datenbank zu beseitigen:

DELETE FROM PkgServers WHERE NALPath like '%<DistributionpointName>%'

DELETE FROM PkgStatus WHERE PkgServer like '%<DistributionpointName>%'

Und tatsächlich: Seither sind die Fehlermeldungen verschwunden.



SCCM-Protokolle und Trace32.exe
Samstag, 9. Oktober 2010, 21:11
Abgelegt unter: Tipps & Tricks | Tags: , ,

In meinem letzten Beitrag habe ich beschrieben, wie man am einfachsten bestimmte SCCM-Logfiles finden kann. Wenn man derartige Logfiles mit dem Editor (notepad.exe) öffnet, dann schaut das ganze schon ziemlich übersichtlich aus:

Protokollausschnitt, angezeigt mit notepad.exe

Zum Glück gibt es jedoch ein äusserst hilfreiches Werkzeug namens „trace32.exe“, das jedem SCCM-Administrator bekannt sein sollte. Trace32.exe ist Bestandteil des „System Center Configuration Manager 2007 Toolkit„. Damit wird das Logfile schon deutlich lesbarer:

Derselbe Protokollausschnitt, angezeigt mit Trace32.exe

Wie das Bild zeigt, lassen sich mit Trace32 mit der Funktion „Highlight“ beliebige Texte hervorheben. Es reicht dazu aus, den gewünschten Suchtext im Dialogfenster einzutragen und schon werden auch in einer langen Protokolldatei alle Zeilen hervorgehoben, welche den entsprechenden Suchtext enthalten. Ob nun nach irgendeinem Fehlercode, einer bestimmten Paketnummer oder einer sonstigen Zeichenkette gesucht werden soll, bleibt den Bedürfnissen des Administrators überlassen.

Ebenso können im Öffnen von Protokolldateien mehrere Protokolle auf einmal gewählt werden und diese dann mit der Option „Merge selected files“ zusammengeführt werden. Das ist inbesondere dann hilfreich, wenn z.B. an einem Vorgang mehrere SCCM-Komponenten beteiligt sind und man so eine konsolidierte Ansicht erhalten kann.

Mit Trace32.exe können jedoch nicht nur nachträglich irgendwelche Protokolle angeschaut werden. Da Trace32.exe die Ansicht nachführt, sobald neue Protokolleinträge geschrieben werden, wird es auch möglich, Vorgänge in Echtzeit mitzuverfolgen. Wer sich also schon immer gefragt hat, was sein SCCM-Siteserver zur Zeit gerade macht, kann die entsprechenden Protokolle mit trace32.exe öffnen. So erhält man sofort einen guten Einblick, ob beispielsweise das Paket LAB0013C nun tatsächlich auf die Distribution Points verteilt wird, oder ob dies – wie im obigen Beispiel ersichtlich – immer noch fehlschlägt, ohne dass gewartet werden muss, bis die entsprechende Fehlermeldung in der Konsole sichtbar wird.

Sieht man nun eine entsprechenden Eintrag im Protokoll, für den man sich besonders interessiert, und klickt diesen an, um diesen in voller Länge im unteren Detailfenster lesen zu können, hält die automatische Verfolgung sogleich an. Gerade wenn die betreffende Komponente sehr aktiv ist, kann man dann schön sehen, wie der Scrollbalken am rechten Fensterrand immer weiter nach oben rutscht, da unten immer weitere Einträge hinzugefügt werden.

Hat man den Detaileintrag fertig gelesen (und vielleicht auch wegkopiert), möchte man vielleicht gerne wieder ans Ende des Protokolles springen und vor allem auch die automatische Verfolgung wieder aktivieren. Klar: man kann den Scrollbalken nach unten ziehen und sieht dann den neuesten Eintrag, doch die Nachverfolgung wird so nicht wieder aktiviert. Doch einen entsprechenden Menübefehl sucht man vergebens…

Dabei ist es so einfach: Tastenkombination „Ctrl-End“ drücken und schon läuft die Anzeige wieder weiter!



Die Suche nach dem passenden SCCM-Protokoll
Montag, 4. Oktober 2010, 21:54
Abgelegt unter: Tipps & Tricks | Tags: , ,

Wenn ich mit dem System Center Configuration Manager arbeite, werfe ich immer mal wieder einen Blick in den „Site Status“. Und leider kommt es immer wieder vor, dass ich dort nicht nur grüne Häckchen, sondern auch gelbe Ausrufezeichen oder sogar rote Kreuze bei einer oder mehreren Komponenten sehe.

Werde ich aus den entsprechenden Status Messages nicht gleich schlau, möchte ich mal schnell einen Blick in die dazugehörende Protokolldatei werfen. Doch welches der unzähligen Logfiles gehört nun tatsächlich zur betreffenden Komponente? Hinter welchem kryptischen Dateinamen verbirgt sich das gesuchte Protokoll? Ist das nun ciamgr.log oder aikbmgr.log oder gar cscnfsvc.log? Und wo ist das gesuchte Protokoll auf dem betroffenen Server noch gleich zu finden?

Hier gibts einen kleinen Trick, den mir vor einiger Zeit mal ein Microsoft Premier Field Engineer gezeigt hat:

  1. Klappe den untersten Punkt „Tools“ in der SCCM-Konsole auf
  2. Starte den „ConfigMgr Service Manager“
  3. Suche die betroffene Komponente in der Liste
  4. Klicke diese mit der rechten Maustaste an und wähle „Logging…“

Und siehe da: hier steht der komplette Pfad mitsamt Name der gesuchten Protokolldatei!



Wiederholte Alarme bei Ãœberwachung von SCCM 2007 SP2 mit SCOM 2007 R2
Mittwoch, 29. September 2010, 22:41
Abgelegt unter: Erkenntnisse | Tags: , , , ,

Schon vor längerer Zeit habe ich einmal in unsere SCOM-Installation das „Microsoft System Center Configuration Manager 2007 SP2 Management Pack for Microsoft System Center Operations Manager 2007 R2“ (Version 6.0.6000.2) importiert, um damit unsere Configuration Manager Umgebung zu überwachen.  Denn wieso soll ich z.B. regelmässig selber manuell den Site Status unserer Sites kontrollieren, wenn das der Operations Manager für mich tun kann?

Doch an diesem Management-Pack hatte ich keine Freude. Zwar funktionierte die Erkennung von Fehlern recht zuverlässig:

  • Ein Paket konnte nicht auf einen Distribution Point bereitgestellt werden. Alert von SCOM!
  • Ein Site Backup konnte nicht erstellt werden. Alert von SCOM!
  • Der SMS Executive crashte auf einem Server. Alert von SCOM!
  • usw.

Die entsprechenden Fehler wurden behoben und die Alerts geschlossen. Alles bestens, oder?

Nein, leider nicht ganz, denn kurz darauf:

  • Alert von SCOM: Ein Paket konnte nicht auf einem Distribution Point bereitgestellt werden!
  • Alert von SCOM: Ein Site Backup konnte nicht erstellt werden!
  • Alert von SCOM: Der SMS Executive crashte auf einem Server!
  • usw.

Was schon wieder? Tatsächlich: SCOM rapportierte dieselben Ereignisse nochmals. Ja, exakt „dieselben Ereignisse“ nochmals, obwohl der Fehler längst behoben war! Egal, wieviele Male man die betreffenden Alerts schloss, kurz darauf waren sie wieder erneut da. Dies natürlich immer mitsamt Generierung der entsprechenden Alert-Mails usw. Erst am Tag darauf kehrte wieder Ruhe ein.

Vor allem als uns etwa vor einem Monat die Verbindung zum Datenbankserver tauchte, herrschte nachher reger Mailverkehr in meiner Mailbox. Und die SCOM-Konsole war komplett unübersichtlich: Unzählige Alerts wurden da aufgelistet und man verlor völlig den Ãœberblick. Und egal wieviele Male man diese Alerts schloss, um wieder eine aufgeräumte Konsole zu erhalten, füllte sich diese innert weniger Minuten erneut. Und die Mailbox dazu…

Ich war kurz davor, das Management-Pack wegen „völliger Unbrauchbarkeit“ zu entsorgen. Und dann las ich den Blogbeitrag „Want to drastically quiet down your ConfigMgr 2007 MP?“ von Kevin Holman, publiziert am 1. September 2010.

Dieser Blogbeitrag beschreibt genau dieses Phänomen und nennt die Ursache dieser wiederholten Alarme. So schreibt Kevin Holman über die sog. „Consolidation Rules“, die noch von MOM 2005 her stammen:

„What happens is – this consolidation rule causes the alert to continuously repeat, even if the status message is no longer in the database!  If you resolve the condition, close the alert, the alert will be regenerated within a few minutes from the Healthservice that loaded this converted consolidation rule.  The purpose behind these consolidation rules was to control a burst of status messages that occur within a short period of time.  However – they aren’t working as designed today, and furthermore are the cause of the massive repeat counts and re-alerting on old conditions.“

Kevin Holman nennt dann auch die simple Lösung für das Problem: „Consolidation Rules“ deaktivieren! Und netterweise liefert er auch mit seinem Beitrag noch ein „Addendum Management Pack“ mit, das genau diese Aufgabe übernimmt.

Tatsächlich: Seit ich dieses (in seinem Blogbeitrag verlinkte) „Addendum Management Pack“ importiert habe, funktioniert die Ãœberwachung genau so wie ich mir das vorstelle:

  • Problem in SCCM, Alert in SCOM
  • SCCM-Problem gefixt, SCOM-Alert geschlossen.
  • Problem doch nicht erfolgreich gefixt, Alert wieder da…
  • SCCM-Problem erfolgreich gefixt. Kein erneuter Alert mehr.

Mit dem „Addendum Management Pack“ von Kevin Holman wird das „SCCM 2007 SP2 Management Pack“ tatsächlich brauchbar!

Thank you very much, Mr. Holman!