• I have a rather specific problem I’ll try to describe well. On SOME devices (not most of them) when attempting to PXE boot, it tries to boot from our SCCM server. We do not use SCCM for imaging, and the DHCP settings are set correctly on our DC. Both the devices that work, and those that don’t connect to the same DC in order to get the PXE DHCP information. We’ve imaged over 150 machines and captured many images, so the settings work on most devices. Since I set up the Fog server, a colleague of mine has been working on setting up an SCCM server, and I’m concerned there may be some setting on that that is grabbing the PXE requests? This is a pretty specific problem and I’m not sure where to go for help on this. To recap:

    • Fog has been working with no problems for months (both BIOS & UEFI after following these directions: https://wiki.fogproject.org/wiki/index.php?title=BIOS_and_UEFI_Co-Existence)
    • Since the Fog server was created, a colleague has been in the process of creating an SCCM server on our network
    • On a handful of machines, when trying to PXE boot it lists the SCCM server’s IP and not the Fog server IP
    • When looking at the DHCP settings on our DC, the SCCM server’s IP is nowhere to be found
    • I’ve tried updating the BIOS on the affected machines and it doesn’t seem to make a difference
  • Moderator

    Well this will get a little complicated to explain, but lets try.

    Traditional pxe booting requires dhcp options 66 and 67 to be set with the proper information namely the next-server and boot-file settings. In a normal environment that is all that is needed to pxe boot a device.

    Now enter a network function called ProxyDHCP. A proxy dhcp server can be configured to override what is set in dhcp options 66 and 67. FOG can use a ProxyDHCP server in cases where the main dhcp server can’t be modified such as in a managed service. For the FOG/linux world you would install DNSMASQ which can be configured as a proxy dhcp server. ProxyDHCP servers work over broadcast messages. So if you have a ProxyDHCP server on one subnet it will not hear or respond to pxe boot requests on a different subnet unless you have the ProxyDHCP server configured in the dhcp-helper/dhcp-relay service on your subnet router.

    SCCM / WDS has a built in ProxyDHCP server. So that is why your dhcp options are being over written with the SCCM boot loader. If you want to block / stop this there is a netboot service on your SCCM server that you need to stop.

    If you want proof this is happening you can use wireshark on a computer on the same subnet as the pxe booting computer that connects to sccm instead of fog. If you use the capture string of port 67 or port 68 or port 4011 then capture the pxe booting process.

    When you look in wireshark you will see

    1. Discover sent by the client.
    2. (2) Offers one from your dhcp server and one from sccm
    3. Request from the client
    4. ACK from the dhcp server
    5. You probably won’t see this unless you run wireshark on your sccm server, but he client will talk to the proxydhcp server over udp port 4011 to get the pxe boot information.