The update to SCCM 1806 completed without issues but the little challenge was that PXE didn’t work on many of our distribution points. SMSPXE.log in \\server\sms_dp$\sms\logs showed the following entries:
PXE::MP_GetList failed; 0x80070490 SMSPXE 8/23/2018 2:52:24 PM 13148 (0x335C)
PXE::MP_LookupDevice failed; 0x80070490 SMSPXE 8/23/2018 2:52:24 PM 13148 (0x335C)
PXE::MP_GetList failed; 0x80070490 SMSPXE 8/23/2018 2:52:24 PM 13148 (0x335C)
PXE::MP_ReportStatus failed; 0x80070490 SMSPXE 8/23/2018 2:52:24 PM 13148 (0x335C)
PXE Provider failed to process message.
Element not found. (Error: 80070490; Source: Windows) SMSPXE 8/23/2018 2:52:24 PM 13148 (0x335C)
The issue was probably caused by the implementation of a new feature in 1806, enable a PXE responder without Windows Deployment Service. I didn’t find any obvious misconfiguration, but it helped on all distribution points with the issue to reconfigure PXE via the SCCM console. There’s no need to redistribute the boot images! Below is a short guide in case you see the same issue:
In the SCCM console, go to \Administration\Overview\Distribution Points, select the affected DP and open properties, note which settings you have set and uncheck Enable PXE support for clients.
Wait a few minutes. You can watch the removal in \\server\ sms_dp$\sms\logs\smsdpprov.log
Connect to the Distribution Point. Open Services and validate that Windows Deployment Services Server is disabled (it will disappear after a restart).
Rename or delete the folder RemoteInstall. Restart the server.
In the SCCM console, enable Enable PXE support for clients again and reconfigure the settings (don’t miss to set the password again).
Wait a few minutes. Again, you can check the smsdpprov.log and smspxe.log to see what’s happening.
Open regedit.exe and navigate to
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\WDSServer\Providers\WDSPXE and set UseDhcpPorts to 0.
You may save the lines below in a reg file to simplify the process
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\WDSServer\Providers\WDSPXE]
“UseDhcpPorts”=dword:00000000
Open Services and check that Windows Deployment Services Server is there. Start the process (if you start the server again you are on the safe side).
That’s it.
Thank you for this! We ran into the exact scenario you describe on one of our distribution point servers that we PXE boot from after upgrading to 1806. This article saved us loads of time and probably a support call into Microsoft. A couple notes:
1) We had also tried regenerate certificates following information from this site: http://blog.dlgordon.com/2017/04/sccm-2012-smspxe-error.html because it seemed possibly related and we had not run across your site yet. We did not test between the steps from that other link before the steps from this link. I’m fairly certain it was the steps from your link that resolved the problem since your description of symptoms is exactly what we had and the other site was more of a stretch. Just mentioning since I am not 100% positive that the other steps did not resolve the issue first.
2) After running your steps, we then got to a new phase of a problem. It ended up being that wdsmgfw.efi was missing from remoteinstall\smsboot\x64. I had renamed remoteinstall as part of your steps and it got regenerated, but somehow did not have all files. We had another distribution point that was working so I copied the files from that server. Apparently others have had this issue of that file missing after an upgrade: https://social.technet.microsoft.com/Forums/azure/en-US/aac2626a-0ba3-446d-8f91-f3395bac57e0/wds-not-generating-boot-files?forum=mdt
3) We did not change UseDhcpPorts to 0 like your article suggests. Our other distribution point that is working has this set to 1 so we kept the problem dp with that registry value set to 1. It looks like that value should be 0 if WDS and DHCP are on the same server. Otherwise it can (should?) be 1.
Many thanks for the feedback. Regarding 3), I had to change the value since the WDS service wasn’t starting, if it does it’s obviously not necessary. You are right that there seems to be a dependency to DHCP (which wasn’t installed on our DPs), but after reading https://support.microsoft.com/en-us/help/954410/the-wds-server-may-not-start-and-an-error-is-logged-in-the-system-log it seems to me that 0 is the right value in case it is. Strange.
Hi,
thank you very much for this post ! We ran into exactly the same situation after upgrading to CB 1806 and this post here really helped a lot !
The reboots can be completey avoided b.t.w if you perform the following steps:
Adminkonsole
===============
Disable PXE but do not uninstall WDS
Wait for things to complete
On the DP
============
wdsutil /uninitialize-server
stop-service wdsserver -Force
cmd /crd /s /q
wdsutil /initialize-server /REMINST:””
start-service wdsserver
wait for things to complete
On The Adminkonsole
===================
Enable PXE again
Win !