SCCM – PXE-E55 ProcyDHCP problem

A very strange problem with a very strange resolve.

So we are deploying a bunch of virtual servers and yesterday I found myself in a heap of trouble, I had a server that I needed to be ready but it kept failing the PXE boot.  Normally you would just delete the virtual server and create a new and the problem would likely be solved, however these servers are created by a script which creates a bunch of servers and a bunch of MDT settings and thus re-starting the process would require re-creating a bunch of servers.

The error I got was; PXE-E55: ProxyDHCP service did not reply to request on port 4011.

When I looked in the PXE log on the PXE server however I found;

MAC=02:00:AA:55:1E:02 SMBIOS GUID=4BDBDC9E-FD92-4BBB-BCA3-2D3A0752C049 > Device found in the database. MacCount=1 GuidCount=0 smspxe 01-06-2011 10:21:21 2364 (0x093C)

This appeared like everything was ok, so I tried logging on to the SCCM server and “Cleared last PXE advertisement” but still no luck, and following this I was unable to do so again as from now on SCCM stated that there was no PXE advertisement to clear (even though I tried PXE booting and got the “Device found in the database” in the pxe log).

Anyhow, I moved on to deleting the computer object on the SCCM server and then re-importing it manually (note; we use static ip on our virtual servers, these are created via the create script to avoid MAC conflicts) with the same MAC.  This did no difference, still the PXE log stated the same, Device found in database, but DHCP kept hanging.  I restarted both the SCCM, DHCP and PXE servers but no luck.

So after a bit of googeling which did not really turn up anything I out of fustration tried to set the MAC address to dynamic and booted the server again, this time everything worked fine as an unknown system – thus the connectivity was obviously fine – I even noticed that the GUID stayed the same.  Anyhow more puzzled I set the MAC address back to the static address from before and viola the PXE boot started and worked like a charm..

I have no idea why, my guess would be that the GUID somehow was cached in some stalled state and the the change of MAC somehow jolted that state.

Anyway, changing the MAC address may be worth a try if you find yourself in a similar situation.