When performing a general infrastructure health check and reviewing the site status messages one day, I noticed that for a few sites, in the Component Status view, the SMS_PXE_SERVICE_POINT component was showing as Critical Status due to an Availability of ‘Failed’:
I immediately contacted the office in question and was informed that PXE was functioning fine. I hopped onto the secondary site server in question and checked the Windows Deployment Services service and this was running. I opened up the SMSPXE.log from the client logs directory on the server and observed machines successfully contacting the PXE server and retrieving advertised task sequences.
I then opened up the pxecontrol.log from the server logs directory and the problem became evident. The log was reporting “PXE test request failed, status code is -2147467259 ‘ Error receiving replies from PXE server'”:
The first IP address used to perform the PXE test was that of an ISCSI adapter. This obviously failed and then subsequent adapters failed. All our PXE Service Points are set to respond to requests on All Adapters. The server list used by the PXE service point to perform availability checks is populated with the list of addresses of all network adapters on the system, in the order defined in the Adapters & Bindings Connection list. I confirmed the ISCSI adapter was at the top of the connection list so I changed the priority so that the local NIC was at the top of the list and first in the priority order. This had the result shown below:
The change was detected in registry and applied. Then exactly 5 minutes after, the local addresses were added to the array in the revised order.
Upon performing the first test with the correct NIC, the request succeeded and no further test was necessary. Shortly after, this then updated the status in the ConfigMgr console; the component status went green and Availability showed as ‘Online’: