Bootimage download with HTTP instead of TFTP
Downloading the boot image with TFTP is slow and download may fail within slow or unreliable networks.
Downloading with HTTP or iSCSI will increase the speed dramatically and the stability is improved also.
With iPXE this technology is implemented and works fine.
My idea is to implement the HTTP download with SCCM.
This would be a great enhancement to performance and stability in the OS deployment.
Hi. I’m setting the status back to Noted – this was mixed up with the item “Add support for TFTP Window Size” – that has been Started and is available in the 1603 tech preview build.
BobMN on behalf of SangeeV for SCCM OS Deployment
+1 here. Currently I am using 4 different ramdisktftpblocksize and ramdisktftpwindowsize in order to work with different types of environment
1) ramdisktftpblocksize 1432 for VPN tunnel network
2) ramdisktftpwindowsize 4 for VMware legacy PXE rom compaibility
3) ramdisktftpblocksize 8192 + ramdisktftpwindowsize 4 for HP laptop using USB-c dock
4) ramdisktftpblocksize 16384 + ramdisktftpwindowsize 8 for regular desktop for best speed
This is way too inefficient and complicated.
Johnny Soto commented
The last admin note on this was more than three years ago. While SCCM has had many great features added in that time, I don't know why this has not been implemented yet. It's such a great idea and a way of saving so much time. PXE would still be used to download the .sdi file but if the next part was HTTP, it would improve performance a tremendous amount.
From someone who has lost WEEKS of their life waiting for TFTP downloads.
Philip Webb commented
I realise this is an old request but I'd like to add another voice to this. It would be an incredibly useful feature to have natively in SCCM.
While the other comments are right that iPXE does this, it shouldn't really be neccessary to use third party software, and it requires extra steps when you update your boot image that could be eliminated natively.
Any chance this might actually get done?
James Dennis commented
Add support for PXE over HTTP, we have experimented with iPXE and the performance is incredible, boot wim download from 5 minutes to a few seconds.
Any updates on this? With newer machines that don't have an ethernet jack (MS Surface series, Latitude 7370, plenty of others), PXE boot is painfully slow - ranging from 30 minutes to several HOURS (if it doesn't just fail outright). Would be great to have a cure for that, not to mention speeding up the 3-5 minute PXE boot times of other machines.
This is a must have feature. TFTP should be left in the past.
These guys do it already, and integrate with ConfigMgr: http://2pintsoftware.com/ipxeanywhere
Nash Pherson (MVP) commented
PXE reliability and performance has been a considerable hurdle for almost every organization that has tried it. On most ConfigMgr engagement I've worked on, regardless of network hardware vendor or age, PXE unfortunately has been something that requires several meetings to get it to kinda sorta mostly work in most places. Anything we can do to get off the TFTP protocol from 1981 will go a long way to making this actually work well in enterprises without so much pain and suffering.
these guys already do this, AND it has BranchCache in it - super cool
HTTP download could also integrate with Branch Cache.
Shouldnt this be moved to Operating System Deployment Instead?
If loading the boot image/windows PE with http instead of TFTP, then it could also be WAN accelerated. Thinking ahead, it could might even work together with the cloud so you could boot an installation from a DP in Azure.
Think about it. Bare metal installations from the cloud.
Brandon Penglase commented
iPXE even has support to load the WIM directly, this would be an awesome inclusion!
TFTP is ugly, slow and not state of the art.
This will be a major improvment.