Log – Haikos Blog

SCCM 2012: “Inboxes”-Verzeichnis füllt sich / Laufwerk läuft voll

admin — Wed, 18 Jun 2014 19:51:00 +0000

Auf einem unserer SCCM-Server ist mir aufgefallen, dass sich das Laufwerk C:\, welches großzügig bemessen ist, nahezu komplett gefüllt hat. Eine einfach Analyse mit TreeSize brachte folgendes zum Vorschein:

Wie auf dem Screenshot zu sehen ist, hat das receive-Verzeichnis unter "C:\Program Files\Microsoft Configuration Manager\inboxes\despoolr.box\receive" eine beachtliche Größe bekommen. Aber was sind das nun für Dateien? Zuersteinmal kann man allgemein sagen, dass dies Daten sind, die auf dem lokalen Verteilungspunkt (“Distribution Point”, DP) verteilt werden sollten und hier während der Empfangs-Phase zwischengespeichert wurden. Aber um welches Paket handelt es sich?

Dazu kann man das Logfile bemühen. Unter “C:\Program Files\Microsoft Configuration Manager\Logs” liegen die verschiedenen Log-Dateien, für diesen Zweck zuständig ist die despool.log (oder auch despool.lo_, falls die ursprüngliche despool.log ihre maximale Größe erreich hatte). Öffnen kann man die Logdateien am besten mit dem SCCM-eigenen Tool “CMTrace”, welches unter "C:\Program Files\Microsoft Configuration Manager\tools\cmtrace.exe" zu finden ist. Dort kann man nun mittels des Fernglas-Symboles suchen:

Als Suchtext kann der Name der größeren Datei verwendet werden, hier also “PKGhl61p.TRY”. Dabei kommt dann auch der Paketname zum Vorschein:

Hier in diesem Fall also “CAS00045”. Nun kann man in der Configuration Manager Konsole unter “Überwachung / Verteilungsstatus / Inhaltsstatus” den Status für des betreffende Paket prüfen:

Da das Paket (mittlerweile) erfolgreich auf den lokalen DP kopiert wurde, kann man die *.TRY-Datei also löschen. Dass dies nicht automatisch vom System gemacht wurde, dürfte hier in diesem Fall daran liegen, dass die Verteilung über WAN auf Grund der Größe des Paketes mehrfach gescheitert ist…

SCCM 2012 R2: Timeout bei OSD-Fehlern von 15 Minuten auf beliebigen Wert erhöhen

admin — Tue, 17 Jun 2014 20:15:00 +0000

Wenn es während einer Tasksequenz im System Center Configuration Manager 2012 R2 zu einem Fehler kommt, so wird die Fehlermeldung standardmäßig für 15 Minuten angezeigt – danach wird der Client neugestartet. Wenn man nun eine längere Tasksequenz laufen lässt, wird man selten die gesamte Zeit vor dem betroffenen Rechner verbringen und so auch die Fehlermeldung verpassen. Noch schlimmer wird es, wenn der Fehler noch vor dem Abschluss der Formatierung des Laufwerkes geschieht – denn bis zu diesem Punkt ist das Logfile lediglich in einer Ram-Disk abgelegt – und die ist beim Neustart natürlich weg!

Diese Fehlermeldungen sehen dann in etwa so aus:

Dieses Verhalten lässt sich glücklicherweise abändern – mit einem nicht all zu hohem Aufwand! Dazu muss lediglich in der betreffenden Tasksequenz (es geht leider nicht pauschal) eine Tasksequenzvariable gesetzt werden.

Dazu wird die Tasksequenz geöffnet und direkt an erster Stelle ein weiterer Schritt “Tasksequenzvariable festlegen” eingefügt:

Der Name der Variable lautet “SMSTSErrorDialogTimeout” – der Wert ist in Sekunden anzugeben:

Damit ist die gewünschte Änderung auch schon gemacht. Beim nächsten Start der Tasksequenz ist die gemachte Änderung auch schon wirksam… Und dann kann man im Falle eines Fehler mittels F8 die DOS-Box öffnen und beispielsweise mit “cmtrace.exe” die Logfiles analysieren.

SCCM2012: Fehler 0x80070002 während OSD / PXE

Haiko — Wed, 13 Mar 2013 16:00:13 +0000

Mal wieder ein Fehler, den ich hier festhalten möchte, obwohl diesmal recht trivial.

Während einer PXE-gestützten Betriebssysteminstallation (OSD) trat nach der Partitionierung und Formatierung der Festplatte der Fehler 0x80070002 auf:

Ein Blick in das Log-File war leider nur mäßig hilfreich:

Da der nächste Schritt, der nun also nicht erfolgreich bearbeitet wurde, das Kopieren der WIM-Datei gewesen wäre, vermutete ich ein Problem beim Zugriff auf dem DP, und meine Vermutung fand ihre Bestätigung:

Es war einfach kein Network Access Account (Netzwerkzugriffskonto) angegeben!

Dies lässt sich recht einfach erreichen, ich denke die Bilder sind aussagekräftig genug:

UPDATE: Ich habe eben festgestellt, dass dieser Fehler auch trotz korrekt konfiguriertem NAA auftreten kann. In meinem Fall war die Fehlerursache dann auch eine ganz andere: Es fehlte einer Bedingungen für Distribution Points, nämlich die „Windows-Authentifizierung“ des IIS!

Die vollständigen Vorbedingungen lassen sich im Übrigen hier nachlesen: http://technet.microsoft.com/en-us/library/gg682077.aspx#BKMK_SupConfigSiteSystemReq