Being a member of FOG Hangouts will allow you to stay updated about the latest FOG Hangout; the when, the where, and the details. Membership in this group is automatic membership in a mailing list.
@Tom-Elliott Thank you so much as always for the detailed, thorough explanations. I was able to get it working again, and tested both imaging and login with several users.
For anyone experiencing additional confusion, I made a quick settings screenshot of what worked for me (descriptions instead of actual data).
2 seconds after I posted the below, I was able to login. I am going to test imaging now.
Getting closer, but something is still off. I felt like I had to add an AD group somewhere specifically, for example if the 3 IT staff are part of the “ITStaff” group, shouldn’t I reference that somewhere within FOG itself? Instead of it pointing directly to an OU that could contain many groups? How does it know to look in ITStaff only for the users?
How does it know where to choose from? Also, do i still use just the samAccountName to login with?
Sorry I know you are swamped with requests today most likely.
@Tom-Elliott I was able to update the plugin and create a brand new LDAP that saves correctly, but having some trouble with associating the group itself. Where do I add the actual search DN for AD for the group to match to?
Under LDAP Groups, it just asks for a common name. Am I supposed to do this in "LDAP Group User Group Associations? Or is that for something else?
Upgraded to version 1.6, couldn’t login to LDAP. Updated the plugin, but everytime i try to add in a new LDAP server I get an error that says “Failed to add LDAP Server”
We use on prem LDAP, it has both port 389 and 636 but I truthfully don’t care which it uses. Any ideas I should check? This is our normal method here on campus for logging into FOG
@gmaurice resetting the host encryption in the gui and then restart the fog service and it should be back up and running. You can also use the api for this, the FogApi powerhsell module (links in my signature) I have this Reset-HostEncryption function https://fogapi.readthedocs.io/en/latest/commands/Reset-HostEncryption/?h=reset+host which will also handle this reset.
Your other other option is to look into post download scripts, there’s some examples in the forums and the docs. If you’re using sysprep and unattend.xml you can inject domain join information into the unattend.xml after imaging and before windows launches for the first time, so the computer is joined to the domain before the fog service or any ui is reachable.
@jmeyer I have some e16 g1s and I am not having the same issue. What version of fog are you running? Are there any other secure boot settings you have configured or maybe not configured? Can you get to the mok enroll with secure boot off? And then turn it back on?
@azm9s actually reading the claude output looks like you’re actually pointing to secureboot/ipxe.efi for option 67. Switch that to either secureboot/snponly-shimx64.efi or secureboot/ipxe-shimx64.efi and that may do the trick
@azm9s I asked Claude for help, it found some stuff
@azm9s Good news buried in your tcpdump: DHCP is working perfectly. Discover → Offer → Request → ACK, the client takes 192.168.65.243, and ARCH (93) = 7 means the firmware is correctly identifying itself as x64 UEFI. Your Realtek 8111H, the board’s UEFI network stack, and IPv4 PXE are all fine. Whatever is broken happens after DHCP.
That reframes the problem — you’re not stuck at “PXE won’t start,” you’re stuck at “NBP won’t load or won’t run.”
Your filter is port 67 or port 68, so the capture cannot show TFTP. Please re-run on the FOG server (192.168.65.35) with:
tcpdump -i eth0 -e -n -vv ether host fc:9d:05:76:7c:00
That one change decides everything:
Also confirm where you ran the original capture — if it wasn’t on .35, you’d never see the unicast TFTP anyway.
DHCP is handing out secureboot/ipxe.efi, but your /tftpboot listing has no secureboot/ directory in it, and no such file. FOG doesn’t ship a secureboot/ipxe.efi under any version — on 1.6 the signed binaries are secureboot/snponly-shimx64.efi and secureboot/ipxe-shimx64.efi.
Check both of these on the server:
ls -la /tftpboot/secureboot/
tftp 192.168.65.35 -c get secureboot/ipxe.efi
If that tftp get fails, there’s your answer. Point option 67 at snponly.efi (a file you’ve confirmed exists) purely as a test.
Vendor-Class (60), length 10: "PXEClient"
This is the old WDS-on-the-same-box workaround, and it can actively break plain TFTP boot. Per the PXE spec, option 60 in the offer tells the client “I am a PXE boot service” — so instead of just using siaddr + boot filename, the client starts looking for option 43 boot-server sub-options and may try ProxyDHCP on port 4011. There’s no option 43 in your offer, so some UEFI implementations simply stall right here, which is exactly what you’re seeing.
Unless WDS is genuinely running on 192.168.65.11, delete option 60 from your scope/server options and retest.
Minor related note: Windows DHCP null-terminates its string options, which is why tcpdump shows "secureboot/ipxe.efi^@". Usually harmless, but if you get the TFTP capture, glance at the RRQ filename for a stray byte.
(The doubled Offer and ACK in your capture are the same packet seen twice — identical IP IDs. Not a second DHCP server, ignore it.)
First, your “UEFI cannot be disabled” is expected behavior, not a fault. MSI greys out / force-locks CSM when Secure Boot is enabled, and also when the installed GPU (including a Ryzen APU’s iGPU) has no legacy VBIOS. Since your client is correctly requesting arch 7, UEFI is what we want — don’t chase legacy mode.
Press Del, then F7 to get into Advanced mode — EZ mode hides all of the following, and it’s the usual reason people report options as missing.
Settings → Advanced → Windows OS Configuration
Secure Boot → Secure Boot Support: DisabledSecure Boot → Key Management → set Factory Default Key Provisioning: Disabled, or delete/clear all keys to put the board in Setup Mode. Secure Boot is always disableable on this board — Tom is right that it would be a firmware bug otherwise.BIOS UEFI/CSM Mode lives here too, which is where you saw UEFI locked.Settings → Boot
MSI Fast Boot skips USB and network initialization outright. It’s a common cause of erratic PXE on these boards and is worth turning off regardless.
Settings → Advanced → Integrated Peripherals
LAN Option ROM: EnabledFlash the latest BIOS via M-FLASH (FAT32 USB stick). MS-7C96 has been through a lot of AGESA revisions and several MSI 500-series releases shipped with a broken Realtek UEFI PXE driver. This is a genuinely common fix for “DHCP completes, NBP never downloads.”
Start PXE over IPv4 on MAC address: 00-00-00-00-00-00 — did you redact that, or is it literally printing zeros? The wire shows a real MAC (fc:9d:05:76:7c:00) doing valid DHCP, so the two don’t agree. If the screen genuinely shows all zeros, that points at the Realtek LAN EEPROM not being read at ROM init time — CMOS clear plus a BIOS reflash. A photo of the screen would settle it.
When you get to the point of testing binaries, try snponly.efi and ipxe.efi and note which behaves differently. snponly.efi uses the firmware’s own SNP/UNDI driver; ipxe.efi uses iPXE’s native driver. FOG 1.6 standardized on the snponly builds specifically because they’re more reliable on modern UEFI firmware. If snponly fails but ipxe works, the board’s SNP implementation is the culprit and that’s useful information.
Still need to know what version you’re on — your /tftpboot listing looks like 1.5.x. And when you say customized: if you mean you’ve used FOG’s supported customization points (https://docs.fogproject.org/supported-customizations), we can help fine. If you mean you forked it at some snapshot and changed internals, we can still help with the DHCP/BIOS side above, but anything server-side is going to be guesswork on our end.
Either way, working-1.6 is worth a look here — it has proper Secure Boot support with Microsoft-signed shim chains and a local ESP boot option that’s built for testing exactly this kind of stubborn hardware:
Start with the TFTP capture though. That’ll tell us which of the three branches above we’re actually in, and we’ll stop guessing.
@azm9s also, silly question, but is this a problem just with this motherboard? Other devices pxe boot fine?
@azm9s echoing the question if what version you’re on?
Also the pxe saying 0s for the mac points to a mobo option, maybe dhcp has to be turned on in the mobo under pxe or network devices? Maybe it isn’t saving that setting? I’m guessing with no uefi disable you mean there’s no bios/legacy/csm option to use the legacy boot files?
I would suggest trying out working-1.6. There’s a lot of new options for pxe including secure boot support and local pxe boot environment zip downloads for testing trouble hardware like this
https://docs.fogproject.org/install-fog-server
https://docs.fogproject.org/local-esp-boot
Also as far as customized goes, there are lots of supported customizations that don’t get overwritten on updates https://docs.fogproject.org/supported-customizations
