Schlagwort-Archiv: PXE

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:

SCCM 2012 R2: Microsoft veröffentlicht Hotfix und behebt PXE-Probleme

Veröffentlicht am 09.11.2013 um 15:37 Uhr von

Ich habe vor ein paar Tagen über einen Fehler berichtet, der beim Configuration Manager 2012 R2 auftritt, wenn man den Windows Deployment Service in den Betrieb nimmt. Jetzt hat Microsoft einen Hotfix veröffentlicht, der das Problem lösen soll. Außerdem soll die Geschwindigkeit der Betriebssysteminstallation wieder auf Niveau des Vorgängers erhöht worden sein.

sccm-2012-r2-wds-service-kann-nicht-gestartet-werdenThis update resolves the following issues in Microsoft System Center 2012 R2 Configuration Manager.

After you enable the PXE Service Point role on an instance of a specific distribution point, or you select the Deploy this boot image from the PXE-enabled distribution point property of a boot image, the Windows Deployment Service (WDS) stops running. Additionally, entries that resemble the following are logged in the Windows Application log:

Note This problem affects only distribution points that are installed on site servers.

When operating system image files are downloaded to Configuration Manager 2012 R2 clients, you may find that the download takes longer than it did in previous versions of Configuration Manager 2012 clients. You may see this behavior when the target client is running Windows PE or a full Windows operating system.

Download: KB2905002 – An update is available for the „Operating System Deployment“ feature of System Center 2012 R2 Configuration Manager

SCCM 2012 R2: WDS-Service kann nicht gestartet werden

Veröffentlicht am 30.10.2013 um 13:31 Uhr von

Ich habe mich in den letzten paar Stunden mit einem Problem beschäftigt, mit dem sich derzeit offensichtlich mehrere Anwender rumschlagen. Hier ein Beispiel aus dem Forum von windows-noob.com, bei dem der Anwender sogar einen Call bei Microsoft aufgemacht hat.

Fehlerbild: Im Zuge der Konfiguration des Configuration Manager 2012 R2 (SCCM 2012 R2) stürzte in einer meiner vielen Testumgebungen der WDS-Service immer ab, sobald ich ein Startabbild mit PXE-Unterstützung auf einen Verteilungspunkt verteilt habe. In der Ereignisanzeige tauchte folgende Meldung auf.

sccm-2012-r2-wds-service-kann-nicht-gestartet-werden

Der Fehler tauchte auch nach mehrmaliger Neuinstallation des WDS-Services und vielen anderen Maßnahmen immer wieder auf.

Die Lösung: System Center 2012 Endpoint Protection auf dem Server deinstallieren bzw. mit passenden Ausnahmen arbeiten.

Update: Microsoft hat einen Hotfix veröffentlicht.

SCCM 2012 SP1: Cumulative Update 1 erlaubt PXE-Boot auf UEFI x86-Systemen

Veröffentlicht am 23.03.2013 um 11:27 Uhr von

Microsoft hat vor ein paar Stunden das kumulative Update 1 (CU1) für den Configuration Manager 2012 mit Service Pack 1 veröffentlicht. Das CU1 (KB2817245) behebt einige Fehler. Unter anderem können nun auch aktuelle Intel Atom-Prozessoren mit UEFI x86 über PXE gestartet und mit einem Betriebssystem betankt werden. Darunter fällt z.B. auch das Lenovo Thinkpad Tablet 2 oder Microsofts Surface Pro.

kb2816245_1 kb2816245_2Außerdem hat Microsoft weitere Powershell-Befehle implementiert:

  • Add-CMDistributionPoint
  • Import-CMAntiMalwarePolicy
  • Import-CMDriver
  • New-CMAppVVirtualEnvironment
  • New-CMMigrationJob
  • New-CMPackage
  • New-CMSoftwareUpdateAutoDeploymentRule
  • New-CMTaskSequence
  • New-CMTaskSequenceInstallUpdateAction
  • New-CMTaskSequenceMedia
  • New-CMUserDataAndProfileConfigurationItem
  • Remove-CMTaskSequenceInstallUpdateAction
  • Set-CMTaskSequenceGroup
  • New-CMTaskSequenceGroup
  • Remove-CMTaskSequenceGroup
  • Set-CMApplicationCatalogWebsitePoint
  • Set-CMAppVVirtualEnvironment
  • Set-CMClientPushInstallation
  • Set-CMClientSetting
  • Set-CMDistributionPoint
  • Set-CMDriver
  • Set-CMEndpointProtectionPoint
  • Set-CMEnrollmentPoint
  • Set-CMEnrollmentProxyPoint
  • Set-CMHierarchySetting
  • Set-CMManagementPointComponent
  • Set-CMOperatingSystemImageUpdateSchedule
  • Set-CMOutOfBandManagementComponent
  • Set-CMReportingServicePoint
  • Set-CMSite
  • Set-CMSoftwareUpdateAutoDeploymentRule
  • Set-CMSoftwareUpdatePointComponent
  • Set-CMStateMigrationPoint
  • Set-CMStatusSummarizer
  • Set-CMSystemHealthValidatorPointComponent
  • Set-CMTaskSequence
  • Set-CMTaskSequenceInstallUpdateAction
  • Set-CMUserDataAndProfileConfigurationItem
  • Start-CMDistributionPointUpgrade

Bitte beachtet, dass das Update ein installiertes Service Pack 1 voraussetzt. Ebenfalls empfehle ich eine aktuelle Sicherung der Umgebung. Das Cumulative Update 1 for System Center 2012 Configuration Manager SP1 kann über diesen Link heruntergeladen werden.

Im Anschluss der Installation muss die Configuration Manager Console aktualsiert werden. Das entsprechende MSI-Paket liegt unter

Windows Server 2008 R2: Zwei WDS-Server parallel betreiben

Veröffentlicht am 03.10.2011 um 13:41 Uhr von

In manchen Umgebungen kann es hilfreich sein, zwei WDS-Server in einem Netz zu betreiben. Windows Server 2008 R2 unterstützt eine solche Funktion aber erst nach einer Registry-Änderung.

Dazu einfach Regedit.exe ausführen und dort hin navigieren:

Hier muss „AllowServerSelection“ auf „1“ gesetzt werden. Abschließend muss der WDS-Dienst (Windows Deployment Service) neugestartet werden, und fertig. Nun lässt sich über „F11“ während des PXE-Boots ein anderer Server mit WDS-Rolle wählen.