![clientmgmt.de by André Picker [MVP]](https://www.clientmgmt.de/wp-content/themes/andrepickerorg/images/logo.png){kind=logo}
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.
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.
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:
Die Console des System Center Configuration Manager (SCCM) bietet keine Möglichkeit mehrere „Retired Applications“ gleichzeitig zu löschen. Abhilfe schafft – wie so oft – die Powershell.
|
1 |
Get-CMApplication | Where-Object {$_.IsExpired -eq $true} | Remove-CMApplication |
Retired Applications müssen nicht unbedingt manuell gelöscht werden. Nach 60 Tagen mit gesetztem Retired-Flag werden alle Revisionen einer Application automatisch gelöscht.
PS: Wer sich sicher ist, kann mit einem einfachen „-force“ natürlich auch die Löschbestätigung umgehen.
Was lange währt, wird endlich gut. Microsoft hat gestern das Update 1704 für den Technical Preview-Branch von System Center Configuration Manager released und bringt erstmals die Möglichkeit Tasksequenzen miteinander zu kombinieren. Mit Nested-Tasksequenzen können Tasksequenzen (Child-Tasksequenzen) aus anderen Tasksequenzen heraus aufgerufen werden. Das Feature stand ganz oben auf der Wunschliste im Uservoice, mit zuletzt über eintausend Stimmen. Es handelt sich zwar noch um einen sehr frühen Entwurf, zeigt aber, wo der Weg hingehen soll. Hier ist Microsoft auf Euer Feedback angewiesen.
Source: UserVoice-Portal
Ein Auszug aus dem Technet:
Consider the following when you add a child task sequence to a task sequence:
- The parent and child task sequences are effectively combined into a single policy that the client runs.
- It is not supported to add a child task sequence that is a parent of another task sequence.
- The environment is global. For example, if a variable is set by the parent task sequence and then changed by the child task sequence, the variable remains changed moving forward. Similarly, if the child task sequence creates a new variable, the variable is available for the remaining steps in the parent task sequence.
- Status messages are sent per normal for a single task sequence operation.
- The task sequences write entries to the smsts.log file, with new log entries that make it clear when a child task sequence starts.
- In the Technical Preview for Configuration Manager, version 1704, if the child task sequences references any package and you run the parent task sequence from Software Center, the client will not find the package content when the child task sequence is run. In this scenario, you must run the task sequence from media (boot media, PXE, etc.).If the child task sequence uses steps like Run Command Line (without any package reference), Format, BitLocker, etc., then the task sequence will run successfully from Software Center.
Das Update 1704 für den Technical Preview-Branch von System Center Configuration Manager ist wie immer über die „Updates and Servicing“-Node in der Configuration Manager-Console der Technical Preview verfügbar. Zu den weiteren Neuerungen des Updates zählen z.B. die erweiterte Hardwareinventarisierung zur Sammlung von Secure Boot Informationen.
Weitere Informationen:
Microsoft hat ein Update für System Center Configuration Manager current branch, version 1702, veröffentlicht. Das Update richtet sich an die Installationen, die über den sogenannten „Fast-Ring“ vor dem 05. April 2017 installiert worden sind. Diejenigen unter Euch, die das Update auf 1702 nach dem o.g. Datum durchgeführt haben, haben bereits aktualisierte Bits zur Verfügung gestellt bekommen und benötigen dieses Update daher nicht.
Das Update bringt zahlreiche Fehlerkorrekturen mit sich, die mitunter von hoher Bedeutung sind. Eine vollständige Übersicht der Änderungen findet Ihr hier. Das Update wird über die „Updates and Servicing“-Node in der ConfigMgr-Console bereitgestellt.
Weitere Informationen:
Microsoft hat das Windows ADK für Windows 10 v1703 alias Creators Update veröffentlicht. Ihr könnt das Windows Assessment and Deployment Kit hier herunterladen. Das neue Windows ADK kann problemlos mit der aktuellen Version vom Microsoft Deployment Toolkit (Build 8443) genutzt werden. Auch kann das Windows ADK 1703 für das Deployment von Windows 10 1607 Current Branch und Current Branch for Business eingesetzt werden.
Bekannte Probleme
ADK Drivers don’t install on systems with secure boot enabled
Drivers on the ADK Deployment tools will not install on systems with Secure Boot (SB) enabled. To work around the issue, disable SB on these systems. This only impacts systems with Secure Boot enabled
Quelle: Hardware development kits for Windows 10, Version 1703 (April 2017)
Nützliche Links: