In Configuration Manager 1606 we got a new option to tweak our PXE boot times, TFTPWindowsSize which we can change in the registry on our PXE enabled DP’s.
PXE booting a machine can never be fast enough!
https://technet.microsoft.com/en-us/library/mt627944.aspx#BKMK_RamDiskTFTP
Location: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\DP
Name: RamDiskTFTPWindowSize
Type: REG_DWORD
The default value is 1 (1 data block fills the window)
We can also tweak the TFTPBlockSize which has been around for many versions of Configuration Manager.
Location: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\DP
Name: RamDiskTFTPBlockSize
Type: REG_DWORD
Value: <customized block size>
The default value is 4096 (4k).
So I did a lot of testing and when it comes down to it, you need to verify the settings that are best in your environment with your network configuration, your computermodels and so on.
What we know for example:
- That HP Probook for instance doesn’t support a higher TFTPBlockSize value than 1456 otherwise it freezes.
- Vmware 5.x doesn’t support a higher value for TFTPWindowsSize than 8.
I put together this list that could be a good starting point when testing out the different TFTP values, I used a Latitude E7450 and an Optiplex 7010 and Max, who helped me PXE boot otherwise I would have overdosed on Coffee by now!
Conclusion UEFI boot is slower! and the values used will be different for many customers as there are now optimal values that will be best in all environments.
Changing the TFTP settings was really boring so when I did the tests I wrote this little powershell tool as well to help in setting the values. I am planning to update it next week to be able to use it on Remote DPs and some more error handling. But you can use it as it is now to do you your testing. Run it as administrator so you have the permisisons necessary to change the registry values.
It can be downloaded here: SCCMTFTP
I hope this can be of use!
In VMWare, what network adapter did you test with?
Interesting! Testing a ProBook 6460b right now, no problem with a blocksize of 8192, but any windowsize other than 1 makes it super slow.
Did similar testing with similar conclusion. However you don’t need to restart the WDS service. Change the values in registry and PXE boot your client. You can verify the values used in the SMSPXE.log file..
When I did the testing, I really didn’t have the time to double check the log files each time, easier to restart the Service to make sure it was correct.
Regards,
Jörgen
Running PXE Boots successfully on many devices for years with these settings:
Blocksize: 8192
Windowsize: 64
The only cases where this doesnt work is on VMWare and some servers using Opensource PXE Firmware
Is your network MTU set to 1500 or do you have a different setting?
Thanks for this tool. It worked very well. No more needed to go in registry 😉
before: 3min30
after: 30sec
(16384 / 8)
Thanks !!
Thanks! I’ve been testing with Lenovo T450s and Dell7240 PXE boot times have dropped from ~2 minutes to ~30 seconds.
Using BlockSize = 16384, WindowSize = 1.
I’m also trying on Lenovo Yoga 12 and Yoga 260 where I must use a Lenovo USB 3 to Ethernet adapter. On a Window size higher than 1 it was taking over 30 minutes! On dropping it to WindowSize =1, it took 8 minutes and 3 minutes respectively.
Using BlockSize = 8192 and WindowSize = 1, the Yoga 12 and Yoga 260 took 3:30 and 2:30 respectively. My other machines are still booting in under 40 seconds.
We did several tests with HP Elitebooks G3 and nothing seemed to improve…
We are running Branch caching on 1 location, 2 DPs and a Primary site, where all locations are MPLS connected and when we hit “1456” Blocksize and “16” Windows Size we got following numbers:
Branch Cache site: From 15 minutes to 1:50 Minutes
Primary Site: 4 Minutes to 5 seconds
You just saved me a lot of time, appreciated.
I’m guessing this will also work with WDS/MDT and not just SCCM since I believe SCCM uses WDS?
“if the defined blocksize produces an IP packet size that exceeds the minimum MTU at any point of the network path, IP fragmentation and reassembly will occur not only adding more overhead[8] but also leading to total transfer failure when the minimalist IP stack implementation in a host’s BOOTP or PXE ROM does not (or fails to properly) implement IP fragmentation and reassembly” (https://en.wikipedia.org/wiki/Trivial_File_Transfer_Protocol).
If you want to effectively speed up TFTP transfers “windowsize” (RFC 7440) is the way
Was so happy how fast it had become… and now i have to go back to the default values, because the Surface Pro does not seem to support any other value. Microsoft, are you serious?!
Ah actually the surface seems to support a higher Window Size (8) but not a higher Blocksize than 1024…
Well at least its a bit faster now..
This is awesome…thanks! Keep coming back to this post for every customer I help. In my Hyper-V lab my boot image WIM loads in less than 6 seconds with 16384/8.
Great write up and tool! One thing I did with the tool to make it just a tiny bit better is read and use the current values from the registry on load. Just add this after the function:
##Gets current values and sets the form to reflect that
Try{
$comboBlockSize = $Form.FindName(“TFTPBlockSize”)
$comboWindowSize = $Form.FindName(“TFTPWindowsSize”)
$windowSize = get-itempropertyvalue “HKLM:\SOFTWARE\Microsoft\SMS\DP” -Name “RamDiskTFTPWindowSize”
$blockSize = get-itempropertyvalue “HKLM:\SOFTWARE\Microsoft\SMS\DP” -Name “RamdiskTFTPBlockSize”
$comboBlockSize.text = $blockSize
$comboWindowSize.text = $windowSize}
Catch{}
##
Great post! I was really concerned after we received a new model from Dell. Legacy Bios was no longer supported on the model. I had to make the jump to UEFI and a x64 boot image. After upgrading SCCM to 1806 all WIM’s were terribly slow to PXE (3-4 minutes!). Now it is less than 10 seconds. Thank you so much for this information.
Thank you, that saved my Day! it doubled the Speed of TFTP!
This is fantastic, thank you Jörgen!
This makes quicker work for virtual dev environments!
Shout out to you for this article. We don’t use SCCM, just MDT and WDS but the changes to the default.bcd really helped. Used 16384 and 4 for the new Optiplex 7070 Micros I’m deploying.
Thanks for this little golden nugget! My colleague was complaining about the UEFI boot time and convinced it was config manager at fault (he hates it). I can now explain to him that it’s definitely a UEFI / device thing and show him the results. UEFI will no doubt be the only standard before long, so this is very helpful.
Thanks for this post, and all your others you are a font of SCCM knowledge!
Amazed by the speeds of a Window size of 16, but unfortunately had to limit ours to 8 and 4096 block size to avoid Surface issues.
Thanks Jörgen.
We found that RamDiskTFTPBlockSize 16384 and RamDiskTFTPWindowSize of 8 worked the best for our environment.
Thanks for sharing!
RamDiskTFTPWindowSize = RFC 7440
I didn’t see this script anywhere in your GitHub repo(s) so I wanted to post it on the original thread that I’ve updated this tool for those that are using PXE without WDS (‘SccmPxe’ Service): https://github.com/cameronkollwitz/CMTFTPSettings/
Thanks for a great tool, Jörgen!
Hi, brilliant script. I have just tweaked it to work with SccmPxe.
The XML for the display changes to this:
And added three more lines:
#Added these three lines to deal with the ConfigMgr PXE Responder Service replacing the WDS Service
IF((Get-Service -Name SccmPxe -ErrorAction SilentlyContinue)){$ServiceName = “SccmPxe”}
IF((Get-Service -Name WDSServer -ErrorAction SilentlyContinue)){$ServiceName = “$ServiceName”}
Then replaced every other instance of WDSServer with $ServiceName
I just wanted to add that when we changed the RamDiskTFTPWindowSize to 16, our HP EliteBook 8 Flip G1i laptops failed to PXE boot, throwing the following error:
Windows failed to start. A recent hardware or software change might be the cause.
Status: 0xc0000001
Info: A required device isn’t connected or can’t be accessed.
Reducing the TFTP window size down to 8 fixed it (our block size remained at 16384).
Strangely, our other HP desktops and Hyper-V VMs didn’t have any issues, this only affected our Filp portables. We are using SCCM’s built-in PXE responder.