Long time ago I wrote a blog post about PXE server installation for MDT. Recently a customer asked me to rebuild his deployment factory using SCCM. As a few things changed over the years I put together this post as an update/reminder of the previous one.
PXE enabled distribution point
First, this is how is designed the deployment factory:
As you have noticed, this is also the place where DHCP and remote Access services will be installed (more on those later..).
The DP should be prepared with two network adapters: One connected to the Lan, the other one dedicated to the imaging factory where will live unknown computers requesting DHCP leases.
Installation is really easy whether or not your DP is already in place. If you start from scratch, there are three things that you should take care about:
- The MEMCM primary server account must be a member of the administrators group of the server you want to turn into Distribution Point.
- When deploying the DP role, don't forget to check the "install IIS" option (assuming you are as lazy as me..).
- You should always deploy x86 and x64 boot image even if you only deploy x64 operating system.
WDS/PXE responder
PXE responder was introduced in release 1806 and is aimed at replacing Windows Deployment services role. Apart from a requirement to work with multicast, there is no reason not to use it, so go for it, it works great and will release MEMCM from a dependency !
DHCP role
Before moving forward, I must point that using a dedicated DHCP is not mandatory (and so is remote access). One can simply use the DHCP server from his organization (IP Helper will probably be required) and get rid of DHCP & Remote Access roles and this will be perfectly fine !
But, If for any reason, you are not allowed to use the DHCP from your organization or are behind a router with no option to use IP helper or more likely because of security or isolation, DHCP on the distribution point will be your only solution.
DHCP installation is a no brainer, so i will only point out the most important options:
DHCP option 66 and 67 are not needed in this setup and should be replaced by IP helper if required.
The DHCP option that you need to setup are described in my previous post (003,006,015 and 060).
In 2020 AD, DHCP option 060 still need to be enabled using netsh.
To configure option 060 on your DHCP Server, open an elevated command prompt and tip in the following commands:
C:\WINDOWS\system32>netsh
netsh dhcp>server \\DHCP_Server_HostName
netsh dhcp>add optiondef 60 PXEClient String 0 comment=PXE support
netsh dhcp>set optionvalue 60 STRING PXEClient
netsh dhcp>exit
If you are one of the few that still need to boot on legacy BIOS and UEFI devices at the same time, you've probably came across that kind of blog post: https://marconuijens.com/2018/01/04/supporting-both-legacy-and-uefi-modes-in-your-sccm-environment/ !
Well, astonishingly enough, this is no more needed (probably because it was never supported...)!!! I was able to boot on both BIOS and UEFI with the above described configuration!
DHCP Broadcast.
To ensure that the DHCP will not broadcast leases on all your vlans, you can define on which network adapter the DHCP server is allowed to work on! Follow this blog post for all the details.
You can also set MEMCM to reply to request that come from a dedidacted network adapter:
And yes you combine both options!
IP Helper
The state of the technology as changed over the years and as transitioned from recommended to "only supported solution) https://docs.microsoft.com/en-us/mem/configmgr/osd/deploy-use/use-pxe-to-deploy-windows-over-the-network#BKMK_Configure
To make it clear for everyone: You will need it if and only a router exists between the PXE enabled Distribution Point and PXE clients.
IP Helper configuration is usually beyond the scope of a desktop engineer but to let you know, it's just a pointer to the PXE server stored in the router configuration. When done, Broadcast packets used by DHCP server are sent to the PXE (Replies are of course also handled!).
TFTP Block and Window sizes
Changing the size of your TFTP packet is fully supported . The biggest benefits for doing this is speeding up the deployment of the boot image. If you need a comprehensive how to, Jorgen Nilsson summed up all possible combinations in a awesome blog post .
Unfortunately theory and life does not always match especially if you are using devices from various vendors.
In my customer environment i had hardware from Dell, HP and VmWare. Finding the best setting per vendor was easy. Finding it for all of them together was almost impossible. If somethings works for two vendors, it will almost fails (Download stuck) everytime on the third one when you add it to the mix...