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!
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:
- Klappe den untersten Punkt „Tools“ in der SCCM-Konsole auf
- Starte den „ConfigMgr Service Manager“
- Suche die betroffene Komponente in der Liste
- Klicke diese mit der rechten Maustaste an und wähle „Logging…“
Und siehe da: hier steht der komplette Pfad mitsamt Name der gesuchten Protokolldatei!
Abgelegt unter: Tipps & Tricks | Tags: ActiveDirectory, AD, MMC, Organisationseinheit, OU
Heute meldete sich ein Administrator-Kollege bei mir mit dem Problem, dass er eine OU verschieben möchte, dabei aber immer folgende Fehlermeldung erhalte:
Active Directory-Domänendienste:
Das Objekt <Name der OU> konnte aufgrund folgenden Problems nicht verschoben werden:
Zugriff verweigert
„Ich habe wohl nicht alle benötigten Rechte dazu“, meinte er lakonisch. Doch auch als ich als Domänen- (bzw. sogar Enterprise-)Administrator die OU verschieben wollte, durfte ich dieselbe Fehlermeldung auf meinem Bildschirm bewundern…
Dabei ist des Rätsels Lösung ganz einfach: Zum Verschieben einer OU benötigt man das Löschrecht am Ausgangsort und das Schreibrecht am Zielort.
Seit dem Windows Server 2008 existiert die Option „Objekt vor zufälligem Löschen schützen“ (engl: „Protect object from accidental deletion“), die in der Management-Konsole „Active Directory Benutzer und -Computer“ erst dann sichtbar wird, wenn die Option „Erweiterte Features“ (zu finden im Menü „Ansicht“) aktiviert wurde. Diese Option wird standardmässig auf Organisationseinheiten gesetzt und bewirkt nichts anderes, als dass in den Sicherheitseinstellungen das Recht „Löschen“ der Gruppe „Jeder“ verweigert wird. Da eine explizite „Verweigerung“ eines Rechtes alle erteilten Zugriffsrechte wirkungslos macht, kann auch ein Domänen-Administrator eine so geschützte OU nicht löschen, bis er das entsprechende Häckchen entfernt.
Und nun müsste auch klar sein, weshalb sich eine OU nicht einfach so verschieben lässt: Das benötigte Löschrecht am Ausgangsort fehlt, da dieses von der Option „Objekt vor zufälligem Löschen schützen“ verweigert wird.
Und so muss das Häckchen bei „Objekt vor zufälligem Löschen schützen“ auch dann entfernt werden, wenn die OU verschoben werden soll.
Mit Vorteil setzt man das besagte Häckchen nach erfolgter Verschiebung am Zielort wieder neu, damit der Schutz vor versehentlichem Löschen wieder gegeben ist.