OSD bleibt bei „Initializing the System Center Configuration Manager client“ hängen

Veröffentlicht am 15.06.2017 um 12:26 Uhr von

Vor kurzem hatte ich das seltsame Phänomen, dass mein neuerstelltes Windows 7 Image beim Initialisierung-Step des ConfigMgr-Clients stehen geblieben ist. Abhilfe schaffte nur ein harter Reset des PCs, danach lief die Tasksequenz weiter und konnte erfolgreich abgeschlossen werden. Das Image, das aktuell verteilt wurde, sowie ältere Images liefen allerdings ohne Problem durch.

Im SMSTS.log konnte ich folgende Zeilen entdecken:

Seltsam, wenn der Step erfolgreich ausgeführt wurde, wieso sollte er dann wiederholt werden? Am Ende des SMSTS.log fand ich dann diesen sich ständig wiederholenden Fehler:

Nach langer Fehlersuche und allerlei Troubleshooting-Maßnahmen (neues Image einbinden, ConfigMgr-Client neu verteilen usw.) bin ich dann auf die Fehlerursache gestoßen. Ich hatte kurz zuvor unsere ConfigMgr-Umgebung von 1602 auf 1606 aktualisiert, allerdings aus Unachtsamkeit nicht mein Custom Boot Image neuverteilt, was dann zu diesem Fehler führte. Nachdem das Bootimage upgedatet war lief alles wieder fehlerfrei durch.

ConfigMgr: „Altes“ Software Center schafft 2018 Platz für Neues

Veröffentlicht am 10.06.2017 um 17:50 Uhr von

Ein Blick in die aktuellen System Center Configuration Manager Dokumentation verrät, dass das „alte“ Softwarecenter und der auf Microsoft Silverlight-basierende Application Catalog mit dem ersten Update-Release in 2018 gestrichen werden.

Der genaue Wortlaut von Microsoft:

The Software Center has a new, modern look. Apps that would have appeared only in the Silverlight-dependent Application Catalog (user-available apps) now appear in Software Center, on the Applications tab. The Application Catalog can still be accessed by using the link on the Installation Status tab of Software Center.
In the coming months, the previous version of Software Center will no longer be available.

[…]

Support for the previous version of Software Center ends with the first update released after January 1, 2018.

Quelle: Removed and deprecated features for System Center Configuration Manager

Microsoft bietet bereits seit Version 1511 von System Center Configuration Manager ein neues Softwarecenter an, das optional über die Client-Settings (Computer Agent > Use new Software Center) aktiviert werden muss.

Update 1705 für Configuration Manager Technical Preview verfügbar

Veröffentlicht am 09.06.2017 um 10:27 Uhr von

Microsoft hat vor wenigen Tagen das Update 1705 für Configuration Manager Technical Preview veröffentlicht. Das Update bringt erneut zahlreiche Neuerungen und Verbesserungen mit.

Dazu zählen:

  • High DPI console support
  • Peer Cache improvements
  • Improvements for SQL Server Always On Availability Groups
  • Improved user notifications for Office 365 updates
  • Configure and deploy Windows Defender Application Guard policies
  • New capabilities for Azure AD and cloud management
  • Use Azure Services Wizard to configure a connection to OMS

Außerdem gibt es nun ein Configuration Manager Update Reset Tool. CMUpdateReset.exe soll Abhilfe bei Problemen mit dem Download und der Replizierung von In-console-Updates schaffen.

You can use this tool with Technical Preview versions 1606 or later. This backwards support is provided so the tool can be used with a range of technical preview update scenarios, and without having to wait until the next technical preview becomes available.

You can use this tool when an in-console update has not yet installed and is in a failed state. A failed state can mean the update download remains in progress but is stuck and taking an excessively long time, perhaps hours longer than your historical expectations for update packages of similar size. It can also be a failure to replicate the update to child primary sites.

Eine vollständige Übersicht der Neuerungen gibt es hier:

Configuration Manager 1702 Hotfix Rollup (KB4019926)

Veröffentlicht am 09.06.2017 um 09:51 Uhr von

Microsoft hat ein Update-Rollup für System Center Configuration Manager Current Branch, version 1702 veröffentlicht. Das Update KB4019926 ist über die „Updates and Servicing“-Node in der Configuration Manager-Console verfügbar und bringt zahlreiche Fehlerkorrekturen mit sich.

Eine vollständige Liste der Fehlerkorrekturen finder Ihr hier:

ConfigMgr 1702 Media über VLSC-Portal verfügbar

Veröffentlicht am 01.05.2017 um 18:01 Uhr von

Kurze Randnotiz: Microsoft hat die ISO-Dateien für den System Center Configuration Manager 1702 (Current Branch) im Volume Licensing Service Center (VLSC)  freigegeben. Die sogenannte Baseline-Build ist für alldiejenigen unter Euch interessant, die noch mit System Center Configuration Manager 2012 arbeiten und ein Update auf den Current Branch planen. Dies kann mit dem Baseline-Build nämlich ohne Umwege erfolgen. Das VLSC erreicht ihr über diesen Link.

Deep Dive: ConfigMgr RamDisk TFTP-Blocksize und TFTP-Windowsize

Veröffentlicht am 28.04.2017 um 08:05 Uhr von

Es ist sicherlich nicht besonders neu, dass man die PXE-Boot-Performance eines System Center Configuration Manager Distribution Points über das Anpassen der RamDisk TFTP-Blocksize und RamDisk TFTP-Windowsize beeinflussen kann. Aber was passiert genau? Klar ist: Höhere TFTP-Block- und TFTP-Windowsizes sorgen für eine erhöhte PXE-Boot-Geschwindigkeit.

Die folgende Folie zeigt, dass ich durch das Anpassen der TFTP-Blocksize und TFTP-Windowsize die PXE-Bootgeschwindigkeit eines „herkömmlichen“ Windows PE (x64, 10.0.10586.0) von 65,40 Sekunden auf 13,52 Sekunden drücken konnte.

In diesem Fall kamen virtuelle Hyper-V-Maschinen unter Windows 10 mit Windows Server 2012 R2 zum Einsatz. Die Messungen in der Übersicht:

Default BlockSize only WindowSize + BlockSize
Run 1 (in sec.) 62,83 17,32 13,2
Run 2 (in sec.) 69,48 17,87 13,42
Run 3 (in sec.) 63,9 18,54 13,95
Average (in sec.) 65,40 17,91 13,52

Eine Aufzeichnung des Bootvorgangs mit RamDiskTFTPBlockSize: 16384 (16k) und RamDiskTFTPWindowSize: 8:

Die wichtigste Komponente in Bezug auf die PXE-Boot-Geschwindigkeit ist die TFTP-Blockgröße. Microsoft supported eine maximale TFTP-Blockgröße von 16384 Bytes. In der Praxis muss jedoch getestet werden, welche Werte in der Produktion am stabilsten laufen. Um die Anpassungen vorzunehmen, müssen dafür pro Distribution Point folgende Registry-Werte angepasst werden.

  • RamDiskTFTPWindowSize: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\DP
    Name: RamDiskTFTPWindowSize
  • RamDiskTFTPBlockSize: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\DP
    Name: RamDiskTFTPBlockSize

Ein wichtiger Auszug aus dem Microsoft-TechNet, der meiner Meinung gut erklärt was technisch passiert.

You can customize the RamDisk TFTP block size, and beginning in Configuration Manager version 1606, the window size for PXE-enabled distribution points. If you have customized your network, it could cause the boot image download to fail with a time-out error because the block or window size is too large. The RamDisk TFTP block size and window size customization allow you to optimize TFTP traffic when using PXE to meet your specific network requirements. You will need to test the customized settings in your environment to determine what is most efficient.

TFTP block size:

The block size is the size of the data packets that are sent by the server to the client that is downloading the file (as discussed in RFC 2347). A larger block size allows the server to send fewer packets, so there are fewer round-trip delays between the server and the client. However, a large block sizes leads to fragmented packets, which most PXE client implementations do not support.

TFTP window size:

TFTP requires an acknowledgment (ACK) packet for each block of data that is sent. The server does not send the next block in the sequence until it receives the ACK packet for the previous block. TFTP windowing is a feature in Windows Deployment Services that enables you to define how many data blocks it takes to fill a window. The server sends the data blocks back-to-back until the window is filled, and then the client sends an ACK packet. Increasing this window size reduces the number of round-trip delays between the client and server and decreases the overall time that is required to download a boot image.

Zum besseren Verständnis habe ich den Netzwerktraffic mit dem Microsoft Message Analyzer aufgezeichnet:

Capture 1 (Default): RamDiskTFTPBlockSize: 4096 (4k), RamDiskTFTPWindowSize: 1

Capture 2: RamDiskTFTPBlockSize: 8192 (8k), RamDiskTFTPWindowSize: 8

Capture 3: RamDiskTFTPBlockSize: 16384 (16k), RamDiskTFTPWindowSize: 8

Welche Werte schlussendlich für Eure Umgebung in puncto Stabilität am besten geeignet sind, hängt von allerlei Faktoren ab. Hierzu zählen u.a. die verwendeten Netzwerkkomponenten, PC- oder Notebookmodelle sowie die Virtualiserungumgebung. Hier ist testen angesagt.

Last but not least: Im UserVoice gibt es momentan den Vorschlag die Einstellungen für die o.g. Werte über die ConfigMgr-Console zu ermöglichen: