regsvr32 /i kaos.dll

Quick & Dirty: Aufgefallen ist der Client durch seine veraltete Endpoint Protection Definitionsdatei. Nach einer erfolgloser Suche wollte ich den Agent neu installieren, allerdings bricht das ccmsetup mit denm Fehlercode 0x80004005 ab.

Hier liegt die Ursache meist beim WMI Namespace, den Fehler konnte ich mit dem guten, alten SCCM Client Center von Roger Zander (http://smsclictr.sourceforge.net/) beheben:

Unter dem Reiter Install/Repair findet man u.a. WMI Repair Optionen. Das löschen des root\ccm Namespace brauchte die Lösung – der SCCM Agent war weg und konnte neu installiert werden.

Mit dem ConfigMgr Current Branch (Version 1606) kam auch das neue Softwarecenter ("ClientUX") auf die Clients welches in der Standard Ansicht die Anwendungen mit großen Symbolen, ähnlich zur Windows 10 Kacheloptik, darstellt. Wenn man in der Vergangenheit hier keine sauberen Icons bei den Anwendungen gepflegt hat, schaut das nach der Migration eher unschön aus:

Der ConfigMgt unterstützt neben Icons (.ICO oder eingebundene Symbole aus .DLL oder .EXE) auch Bilddateien in den Formaten .JPG, .JPEG und .PNG bis zu einer Größe von 250×250 Pixeln:

Ergebniss:

Beim gestrigen System Center User Group (#SCUG) Treffen im München hielt André Picker einen Vortrag über OS-Deployment mit dem ConfigMgr. Ein Teil davon ging um das Thema PXE Boot und wie man hier optimieren kann.

Technisch bedeutet PXE Boot beim ConfigMgr, dass der Client ein Windows Preboot Environment (WinPE) Image per TFTP herunterläd und dann davon startet um die eigentliche Betriebssysteminstallation durchzuführen. Hier gibt es einige Stellschrauben, konkret die TFTP Block Size und die TFTP Windows Size.

Die ConfigMgr Standartwerte sind eine WindowsSize von 4 und eine BlockSize von 1024 Bytes. Damit dauert der Startvorgang mit einem HP Testnotebook bis zur Abfrage des Task Sequence Passwortes knapp 80 Sekunden.

Davon ausgehend habe ich einige Werte getestet und konnte das beste Ergebniss mit 8192 Byte Blöcken und 8 Chunks erhalten, die Bootzeit ging auf ca. 35 Sekunden zurück. Leider stellte sich dann aber heraus, dass VMware ESX mit einer Blockgröße >1432 Bytes Probleme bekommt. Bei Verwendung eines E1000 Adapters bricht das PXE mit einer „A required device isn’t connected or can’t be accessed“ ab, mit einem VMXNET3 Adapter um kommt stattdessen „The application or operating system couldn’t be loaded because a required file is missing or contains error“.

Als ein funktionierender Kompromiss für meine Umgebung hat sich eine Windows Size von 6 und eine Blocksize von 1024 herausgestellt womit Virtuelle Maschinen noch sauber vom Netzwerk starten und das Testnotebook bereits nach 44 Sekunden bei der TS-Passwort Abfrage steht. Manches mal muss man auch mal mit etwas zufrieden sein… ;-)

Gesetzt werden die Werte direkt auf dem entsprechenden Distribution Point in der Registry wo zwei neue DWORD (32bit) Schlüssel gesetzt werden müssen:

Name: RamDiskTFTPWindowsSize
Key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\DP
Values: 4 (Default), 8

Name: RamDiskTFTPBlockSize
Key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\DP
Values: 1024 (Default), 2048, 4096, 8192, 16384

Wenn die Änderungen nicht gleich übernommen werden dann muss ggf. der WDS Dienst (Windows Deployment Services Service) neu gestartet werden.

Weiterführende Informationen:

• Technet – Planning for PXE-Initiated OSD in ConfigMgr
• bcTechNet – VMware PXE Limitations

Microsoft hat das Update Rollup 1 für den ConfigMgr 1606 veröffentlicht welches über den "Updates and Servicing" Note in der Konsole bereitgestellt wird.

Unter anderem wird ein Bug behoben, der dafür sorgt dass bereits bearbeitete EPP Dateien (\EpMgr.box\process) nicht automatisch gelöscht werden. Außerdem können nun Task Sequenzen importiert werden, welche einen "Install Software Updates" Step beinhalten. 

Nach der Umstellung auf den aktuellen ConfigMgr 1606 haben wir festgestellt, dass OSD via PXE funktioniert aber beim Start aus dem Softwarecenter heraus abbricht. Es kommt folgende Fehlermeldung:

 "Windows PE initialization failed with error code 0x80220014"

Die Ursache liegt hier am Windows 10 ADK und von Microsoft gibt es dazu ein Hotfix:

Windows PE boot images don't initialize in System Center Configuration Manager

In einer neuen ConfigMgr Current Branch (1602) Umgebung meldete ein Distribution Point seit Tagen dass ein Neustart von nöten wäre:

Über die Zeit sollten Meldungen an dieser Stelle durch die Wartungsaufgaben verschwinden. Alternativ dazu kann man hier auch in die Datenbank eingreifen:

Damit verschwindet die Meldung und der Distribution Point meldet wieder einen grünen Daumen nach oben. Direkte Datenbankeingriffe bei SCCM werden von Microsoft nicht unterstützt, ein ordentliches Datenbank/Server Backup sollte vorhanden sein!

Idealerweise verlegt man größere Content Distribution Jobs ausserhalb der Geschäftszeiten um die Beeinträchtigung für die Enduser zu minimieren. Das bedeutete in der Vergangenheit für mich, dass ich mich regelmässig Nachts und am Wochenende per VPN aufgeschalten habe um Jobs zu starten. Inzwischen löse ich das mit einem super Powershell Script von Trever Jones: ConfigMgr Package Distribution Scheduler and Monitor.

Mit dem Script kann man einfach Tasks anlegen, um Inhalte zu einer gewissen Uhrzeit zu verteilen. Das Script sendet selbst dann noch Emails wenn die Aufgabe los rennt bzw. wenn sie abgeschlossen ist. Eine ausführliche Erläuterung aller Funktionen findet ihr im Blog von Travor: https://smsagent.wordpress.com/2014/10/27/schedule-and-monitor-configmgr-package-distributions-with-powershell/