Solution for MDT / SCCM integrated PXE Boot across slow WAN segments?

Hello folks!  I am working with some constraints with booting PXE images (LiteTouch style from MDT 2013) in a multiple site, poor-WAN-interconnect-speed scenario.  

I may only use one WDS server for this environment (directives of centralized servers), but I'd like to avoid having the PXE clients have to TFTP the boot image across the slow WAN links.  Our DHCP solution, thankfully, will allow for different DHCP options and server targets per network segment.

Can anyone recommend some workstation-level PXE/TFTP software that would allow for PXE boot clients to transfer boot images inside the same segment?  I will already be having a "Linked Deployment Share" hosting Workstation on each segment to minimize WAN usage for deployment.  These workstations are likely going to be running Windows 7 Pro x64.

Thanks in advance for your suggestions and shared experiences!  Any other tips for multiple segment, centralized MDT/WDS server scenarios would be appreciated.
Who is Participating?
vivigattConnect With a Mentor Commented:
OK, so you could go without a true PXE server actually.
Set Bootp options (OR DHCP 66 and 67 options) on each dhcp instance so that each client stays local.
Yet, I am not sure that MDT can manage each local repository this way.
I would recommend reading the following:
As the author said, "This installation of MDT is very basic without drivers or database and all the other stuff you can throw at it, but it’ll get you started at least..."

Regarding your other questions, this would require a little investigation for me, but maybe another expert knows better.
Nagendra Pratap SinghCommented:
You can install MDT on a old desktop.
You can use Philippe Jounin's TFTP32 utility (DHCP/PXE/TFTP server).

Yet, be aware:
avoid setting DHCP options 66 or 67 centrally, since the PXE server (MDT/SCCM, WDS, whatever) can conflict with these options. A real PXE server is made mainly to set DHCP options 66 and 67 in DHCP OFFER messages that do not contain a client IP address offer (they just contain the PXE related details). If you set DHCP options 66 and 67 directly in dhcp scopes, they will have precedence over whatever the PXE server sent.
More details about that in my article and its comments:

There seem to be a resource for implementing MDT with an external PXE server here:

I did not try it myself, but I can tell you that you must avoid setting DHCP options 66, 67 and 43 directly in DHCP (unless you do not have a true PXE server locally).
Evaluating UTMs? Here's what you need to know!

Evaluating a UTM appliance and vendor can prove to be an overwhelming exercise.  How can you make sure that you're getting the security that your organization needs without breaking the bank? Check out our UTM Buyer's Guide for more information on what you should be looking for!

murraybdAuthor Commented:
In the scenario so far, each building location (LAN segment) would NOT have its own "True" PXE server (hence the requirement for something that lives on each of the site LinkedDeploymentShare workstations).
The DHCP options are set by a centralized appliance, but we can set different option values per scope/segment.

If I understand correctly, the local PXE daemon would look for PXE-related DHCPRequests, pass them along for actual IP address values, and then set its own 66/67 values?
You should be able to specify the location of the images for each segment so that each segment uses a local repository. In the past, a simple network shared folder used to work.

Then you would have a central DHCP/ and PXE server, the latter being configured so that each client nodes accesses a local server for the image files

Regarding your question regarding PXE/DHCP interaction, here is a good page:

Note that with some implementations of PXE Service, the PXE Server can send a DHCP ACK (or even DHCP OFFER) on its own, without any IP address or lease details, without monitoring the other DHCP messages.
murraybdAuthor Commented:
Based on some further inspection of how things are set up in this particular network, the main server performing the MDT steps may not even end up acting as the PXE server.

Looks like the InfoBlox appliance used can specify BOOTP options per segment, which is how I imagine this would have to be broken down.  The objective is to use the slow WAN links for as little data transfer as possible during the deployment sequence.
I've got the tftpd service running on a test workstation; just need to figure out the settings in the InfoBlox to direct PXE downloads towards it.

And as a side note, I'm learning about more of the limitations of DFS-R ( I was planning to use a differential copy method across the slow WAN links ).
Side Question: Is it true that all the machines in a MS Server 2008 R2 Replication Group must be running the Server flavour of OS?  There is a ban on having ServerOS machines outside of the centralized facility (quite strange with weak WAN links, I know).

From what I understand, the Linked Deployment Share feature of MDT itself doesn't do Remote Differential Compression (RDC).
murraybdAuthor Commented:
Looks like this method of using tftpd as target and the BOOTP options on the DHCP devices will be the way to go for this method.

MDT can do linked deployment shares, where it replicates the data to additional UNC paths.
However, it doesn't use block-based remote differential compression, so I'll be using a different tool to handle the replication across slower WAN links.

Thanks again for the help!
All Courses

From novice to tech pro — start learning today.