Since you logged this with support as well, I helped with the support ticket and the main response is there. I'm repeating the one significant part here.
The main take-away is that the load-balancing is the only real issue. We don't test it, we won't support it, but - most importantly - I wouldn't expect it to work. Any kind of load-balancing is pretty much "fatal" (except for failover teaming) in my experience when it comes to PXE - it's pretty rudimentary network code, and often doesn't work well with load balancing.
DOS used to be just as bad, if not worse - but if it works for you (I'd highly advise testing it thoroughly) feel free to use it.
LANDesk EMEA Technical Lead.
1 of 1 people found this helpful
I don't think there really is an issue with multple pxe servers as the fastest to respond should win out.
If you are wanting to use the ip helper then your limitation is likely to be how many addresses you can point that to.
I think you should be fine if you install a local pxe rep and set up ip helper to point to another one as your backup. The local one should respond first as it would in a normal dhacp scenario and the secondary would only respond if the first does not.
Beware of where your secondary is because the size of the boot image transfer is large if using winpe so try not to put it across a wan link like you might for dhcp backup services.
Mark Star - http://www.marxtar.com
Home of Power State Notifier & Wake-On-WAN for LANDesk
Paul is right that whatever you do will not be officially supported (for unsupported read untested).
Just to add a comment, I've installed pxe reps into environments that have unknown to me had other pxe service on the same subnet. The technology is very similar to dhcp so in these situations I might have one PXE system respond on one boot and another on the next boot. So realistically there should not be an issue if the pxe services are both on the same subnet providing nothing relies on it reconnecting to the same one on the next reboot.
You would have issues with putting your reps into holding queue mode though since that takes note of whether a machine has been in the queue for a particular rep. I would think the menu would be OK though.
In simple terms, suck it and see. If it works, great, if not, then you won't get much support.
Essentially, all you create is a race-condition. "First come - first served" in terms of the PXE request. There's no problem there (from our point of view) - but it could cause problems on your side (having to identify / admin two systems).
Port forwarding shouldn't be necessary, since the entire point of a PXE Rep is so that you don't need to forward these requests in the first place - they're there to make the OSD process more router friendly. That's why we came up with 'em :).
LANDesk EMEA Technical Lead.
Thank you for your answers.
I identified three point:
1) It's possible without any problems
2) Don't use NLB
3) Watch WAN links for the WinPE file size
OK - I will give it a try and by chance report about it.
bis denn dann
Where exactly are you hosting your PXE proxies? The whole point of them (well - now with WinPE especially) is so that you DON'T have to go over the WAN to pull the boot-image down.
The only time the WinPE image should be going over the WAN (if at all) is if you're updating/installing a PXE rep...
LANDesk EMEA Technical Lead
The comment for WinPE across the WAN I think was made in regards to have IP helpers provide backup for a failed PXE rep on the local subnet. In a dhcp scenario a backup DHCP server could reside across the WAN, not such a good idea for a PXE rep backup. Much better to have one than one on the same subnet if redundancy is really that important (although I haven't seen anywhere where PXE services would be considered this important).
although all our WAN links are 50 Mb/s we will try to avoid sending each and every bit of software over the wire. Instead we will try to build offshore distribution server (or use PCs) for OSD and software distribution. Building an simple and efficient process to point a PC to it's closest "OSD image providing server" is the challenge here (ideally only one OSD script for all subnets / main or branch offices).
I will consider the point. Indeed one could argument that one PXE proxy per subnet is enough, because another proxy can be deployed very quick. But someone has to do it quick in the case of failure and a second proxy will pull away the pressure of "quick" for the LDMS admin.
bis denn dann
I've spent a quality weekend discovering problems with multiple PXE reps per subnet -- as Paul and Mark note, on the subnet it's just a race condition, but the reps are PROXIES, and they're communicating with the core, and it was getting confused. This was back in 8.1 or 8.5 or something though, maybe it's been fixed now.