Setting up PXE server in an school environment

I am starting the research phase of setting up a PXE server to cover a Junior High School campus but have never done so and have a few questions that pertain to our School District networking setup and I am unsure if those details will change the way I set up PXE.

From what I have seen it is necessary to make configuration changes on the DHCP server to get the clients to successfully connect to the PXE server and get the bootloader/etc. However, I do not have any admin rights to the DHCP server as that is managed centrally by the school district. They have also made some changes at that level to block certain traffic (they are vague on what exactly but I have reports that they block some PXE required ports but am not sure which if any are indeed blocked).

One workaround I am exploring is setting up dnsmasq as a DHCP proxy and to handle the TFTP and PXE requests using the Windows Subsystem for Linux since I don't expect that the district will give me a copy of Windows Server to set up and use.

My thought is that this would allow me to use tools I am more comfortable with (Linux command line is more familiar to me than Windows) plus better documentation and support, plus not have to ask for help from the district (since they allow but do not officially support PXE booting).

My questions:

1. Is using WSL to setup dnsmasq a sane way to get around the limitations I have?
2. What kind of server hardware minimums would I need if the server is going to support a campus with a couple of hundred clients?
3. Are there any resources that may help that I have not found yet? (I've looked on StackExchange and here and found some things on the topic but were issues that I didn't have.)
4. Is there a better way to set up PXE booting given that I don't have control of or access to the DHCP/DNS/etc servers?

I manage a part of the campus network and a pool of lab PCs in the large university as one of my pet projects.

We image PCs, change their default boot choice, detect unbootable computers and boot management tools all via iPXE with Dnsmasq in proxy mode. DHCP for labs is done on the router that lacks conditional statements for PXE, so we use Dnsmasq.

Dnsmasq in proxy mode would answer on the network specified in the configuration with responses that do not bear IP assignment, but have all necessary PXE options set. DHCP clients append this information to the lease responses they receive from the real DHCP server.

We run Dnsmasq on a VM in a lab cluster that at the same time provides necessary (SMB, NFS) shares to facilitate image booting and TFTP server. iSCSI boot targets are served by a SAN port on this network.

The Dnsmasq itself with TFTP for iPXE is not a resource hog, but image distribution with SMB, NFS, iSCSI is. We use 10Gbe uplinks for this because of that.

We use imaging as initial deployment step only and then manage updates, software distribution and configuration changes through Ansible roles on AWX.

You really should coordinate this with your campus IT, as our network is set up so any rogue DHCP server activity detected will trigger a port shutdown on a switch (DHCP snooping), we also do the same for STP BPDUs (BPDU guard) to make sure that students would not wreak havoc and exploit each other. At least they should be aware that you use Dnsmasq somewhere so that would not trigger unnecessary alerts.

You can try Serva

Single exe including all you need, its proxyDHCP mode does not interfere with the DHCP infrastructure already in place, Legacy, UEFI, Windows, Linux, etc.

EDIT1: After reading some of the the OP comments I'd like to add

If you set your PXE setup based on a proxyDHCP service you do not need much from your IT department other than verbal/written authorization. When a PXE client boots up it sends its info on the DHCPDISCOVERY packet then the cleint will get 2 answers, one from the DHCP server providing an IP and the associated DHCP options and the other one from the proxyDHCP only providing PXE info like the TFTP IP address and the path to the NBP (Network boot program). The client takes both offers and completes both DHCP transactions gathering the required information to continue the net boot process. If a regular client (not PXE) boots up will only receive the answer from the DHCP server and the proxyDHCP will remain silent preventing unnecessary disruption of the corresponding collision domain (remember DHCP offers are broadcast traffic).

Microsoft long ago discouraged the use of DHCP options 66/67, the same function can be achieved properly using the corresponding fields of the DHCP packet.

TFTP uses UDP port 69 for transfer establishment but the actual data transfer is carried on an agreed ephemeral UDP port that must be open in your PXE/TFTP server firewall.

The advantages of PXE vs USB sticks are many, scale, centralized management, and remote boot are among the most important ones. All the big producers of PCs either use disk cloning and/or PXE when imaging their PCs