1 of 1 people found this helpful
You could ask the consulting team from five9s ( five9s.de ). They are LANDesk One Partner and have a great solution for PXE Boot.
With this you need only download a 70kb file via tftp all the rest is http based and very fast. In our Environment we need only 5 seconds to boot to WinPE and need only 1 PXE Server for all subnets and locations.
I have noticed the PXE Booting process seems to be getting really slow now under both LDMS 9.5 SP1, SP2 and LDMS 9.6 SP1. I remember it used to be fast back on LDMS v9.0 SP3.
Like yourself Miw, I too have been looking for some TFTP settings / registry key values to edit to increase performance but to no avail to date. So if anyone have any ideas on how to boost performance and could share, that would be great.
Yes i dont want to implement the solution from five9. Landesk is a big Company , it should be posible to fix this by them.
any luck finding a solution from LANDesk? this is really slow for us, to the point if i try to boot 2 at the same time it either takes forever and only if im luck will it actually make it into WinPE and not fail completely. At 1 site after getting 6 booting to PXE no more will connect to the boot server. We are running 9.6 SP1
No not any luck with this problem
I just startet an other case about
pxe e32 tftp open timeout.
can PXE boot the same machine 10 times but in 20% i get TFTP timeout.
Ive dug in the network tracing and fount out the LANDESK PXE server is responing late with the DHCP offer then the error occurs i have Tracelogs from Wireshark i can send. I think it is the PxeMtftp.exe application that are to slow at responding 20% of the time.
Out server is running WS2008R2 SP1 8GB ram 2Vcpu ( vmware) no load issues
Tftp is UDP, so you don't have a resend of lost packages. Tftp wasn't designed to transfer big data such as boot wim files. If you have network related problems tftp does not work probably
We have a stable workaround to get pxe to work with more speed. You only have to create a http share and replace existing startrom.0, but you are true it isn't landesk
We've experienced the same issue. Especially when PXE booting across subnets. The solution was to chainload iPXE with wimboot over HTTP. The process is well documented on iPXE.org. When implemented PXE boot time is reduced to seconds instead of minutes.
Yes thats it and you only need one pxe for all your subnets.
This i the Wireshark trace of my PXE server with a client on a different subnet that Does NOT Work.
And here is the Trace of my PXE server with the same client on a different subnet that Does Work.
You can see here that the server is responding Slower with the DHCP offer message when the error happends.
As described before i can PXE boot the same machine 10 times but in 20% i get TFTP timeout.
So this trace confirms that the problem in my situation is related to the PXE server.
And I seriously doubt that our Server environment is the cause here. We have over 125 Servers in our VMware blade Cluster with a High performance SAN Storrage. And I have had this problem from the beginning with no load on network, and no clients when we first installed Landesk V 9.6 ( now on 9.6 SP1)
now we are running with 6000+ Windows clients, on 11 different physical locations and of cause hundreds of subnets in a cleen Cisco environment from core to access switch.
let me here your thoughts?
Your timeout issue is related to your original post of slow download speed. TFTP being UDP is sensitive to network conditions. It's also not designed to serve large files efficiently. Switching to HTTP should resolve both your issues.
Hey Tom maybe it would, but in my World i will require landesk to fix this issue, we have allready paid for this product, so it should work from the start.
Microsoft SCCM dont have these kind of issues, and they are also using a PXE server with UDP connection.
I am not certain where the problem is so I am listing the actions in segments:
1. BOOT PC & select Network Boot
2. PC gets an IP address and starts the PXE Boot process.
3. Boot.sdi flys by loading (usually you cannot see it, but on a slow link you can)
4. Boot.wim / Boot_x64.wim starts loading (on a 1gb link to the PXE Server on the same subnet this takes us about 12 - 18 seconds)
5. PE Load screen begins to spin (blue window and rotating marbles)
6. PE loads and OS Provisioning starts
I am guessing your issue is with step 4.
We had problems with this being slow and even timing out before the PC could load the PE (Boot.wim). Not any longer. We placed the PXE server on the same subnet as the devices being imaged. added 1GB connectivity. Problem solved. Also
- I discovered that the PXE Rep Deployment script from 9.5 SP2 does not work in 9.6 (Duh - Right? We didnt't realize we were using that.
- Make certain that the VB Script for the PXE deployment (now found in SD - under all packages) points to OSDREP.vbs in Program Files\LANDesk\ManagementSuite\landesk\files
- We did not have the PXE Reps loaded quite right - I had to actually remove the reps using the 9.6 SP2 script for removal and then re-push the PXE Reps on some units
- We have PXE Reps at remote sites also
You say that the process is well documented on iPXE.org, but I can't find anything specific to LANDESK. Can I get iPXE to run via my PXE reps?
iPXE.org is not going to mention LANDesk. PXE is an industry standard that LANDesk is leveraging. What you need to do is chainload iPXE with wimboot over HTTP
Documented here: iPXE - open source boot firmware [howto:chainloading]
Then use the boot files generated by LANDesk. If you want to go across subnets you'll also need to configure IP helpers or DHCP options.