Haikos Blog Blog von Haiko Hertes zu allen Themen rund um Microsoft und Datacenter

18Jun/140

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

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:

inboxes1

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:

inboxes2

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

inboxes3

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:

inboxes4

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…

17Jun/141

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

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:

SCCM_0x80070002

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:

sccm_ts_var

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

sccm_ts_var2

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.

15Jun/140

SCCM 2012 R2: Logging während OSD verbessern

Während einer Betriebssysteminstallation (“OSD” – Operating System Deployment) werden alle Schritte protokolliert. Das Problem dabei ist, dass das Logfile dabei maximal 1MB groß werden darf. Alle älteren Einträge werden überschrieben. Und ein Megabyte ist selbst beim Standard-Loglevel nicht sehr viel…

Um die gewünschten Änderungen zu erreichen, müssen die Boot-Images (“boot.wim”) angepasst werden. Dabei muss eine Konfigurationsdatei erzeugt und in den Abbildern hinterlegt werden. Diesen Vorgang möchte ich hier etwas genauer beschreiben:

Als erstes besorgt man sich die aktuell verwendeten Startabbild-Dateien für 32 Bit und 64 Bit. Wo diese zu finden sind, kann man in den Eigenschaften der Abbilder nachsehen. ^

Screenshot (18)

Der übliche Speicherort lautet

\\[HOSTNAME]\SMS_[SITECODE]\OSD\boot\i386\

für 32 Bit und

\\[HOSTNAME]\SMS_[SITECODE]\OSD\boot\x64\

für 64 Bit.

Als zweites benötigt man das Windows ADK in einer passenden Version. Dieses kann bei Microsoft heruntergeladen werden. (http://www.microsoft.com/de-de/download/details.aspx?id=39982)

Nun kann mit Hilfe von DISM in einer Eingabeaufforderung mit administrativen Rechten die jeweilige WIM-Datei zum verändern gemountet werden. Dies geschieht mittels des Aufrufes

dism /Mount-Wim /WimFile:C:\boot.wim\boot.CAS00005.wim /index:1 /MountDir:C:\boot.wim\mount_x64

(Die Pfade sind entsprechend anzupassen)

Screenshot (13)

Nun kann im Windows-Pfad des gemounteten Images eine Datei mit Namen “SMSTS.INI” und folgendem Inhalt abgelegt werden:

[Logging]

LOGLEVEL=0

LOGMAXSIZE=10485760

LOGMAXHISTORY=3

DEBUGLOGGING=1

CCMDEBUGLOGGING=1

Das LogLevel 0 steht für “verbose”, ist also der höchste Detailgrad. Standard wäre 1…

LogMaxSize erklärt sich sicher von selbst – der Wert wird in Bytes angegeben (hier also 10MB)

LogMaxHistory sorgt dafür, dass nicht nur das letzte LogFile gelesen werden kann, sondern auch die vorherigen. Im Normalfall steht der Wert auf 1 und dabei werden ältere Logs immer durch das aktuelle überschrieben.

DebugLogging aktiviert das Protokollieren von Debug-Meldungen (1 ist “true”, 0 ist “false”)

CCMDebugLogging tut im wesentlichen das selbe, Microsoft empfiehlt die Verwendung beider Varianten, ich vermute aus Gründen der Abwärtskompatibilität

Screenshot (15) 

Die Namen der Konfigurationsparameter müssen in Großbuchstaben geschrieben werden!

Screenshot (14)

Nun kann die WIM-Datei wird zurückgeschrieben werden, dazu dient wieder DISM mit folgendem Kommando:

dism /Unmount-Wim /MountDir:C:\boot.wim\mount_x64 /commit

Screenshot (17)

Danach muss das WIM-File nur noch zurück auf den SCCM-Server kopiert werden und neu auf die Verteilungspunkte (“Distribution Points”) verteilt werden…

11Jun/140

Windows 8.1 Benutzer ohne Frühjahrs-Update (Update 1) bekommen keine Patches mehr

Was Microsoft bereits im April angekündigt hatte (http://blogs.technet.com/b/askpfeplat/archive/2014/04/07/exploring-windows-8-1-update-start-screen-desktop-and-other-enhancements.aspx) wird nun Ernst:

Wer das Update 1 für Windows 8.1 aus dem April 2014 bisher nicht installiert hat, bekommt seit dem gestrigen Patch-Tuesday keine Updates für sein Betriebssystem mehr! (Das gilt natürlich auch für künftige Patches)

Daher sei an dieser Stelle noch einmal daran erinnert, dieses Update zu installieren und neben den folgenden Sicherheitsupdates auch von zahlreichen Verbesserungen zu profitieren. Einige davon hat mein Kollege Remigiusz Suskiewicz in seinem letzten Blogpost beschrieben.

Das Update 1 (KB2919355) bekommen Sie hier:

http://www.microsoft.com/de-de/download/details.aspx?id=42335