Author Archives: Jonk

About Jonk

I am a Configuration Manager Administrator. When I'm not deploying Software Updates and Operating Systems, you'll find me at the local Curling Club.

ConfigMgr UEFI PXE Booting Error: \Boot\BCD 0xc000000f (SOLVED)

I wanted to share the resolution to a crazy hair-pulling issue I’ve been having since late mid-July with Microsoft Support unable to determine the cause.

We had been using PXE booting from our locations for a while now. Got everything setup by our infrastructure teams with IP Helpers, no DHCP scope options. I tuned the registry settings for RamDiskTFTPBlockSize and RamDiskTFTPWindowSize for our VPN tunnels. Everything was working great for months.

Then all of a sudden PXE booting stopped working… But only for UEFI devices… Legacy clients were still booting correctly.

Error:

File: \Boot\BCD
Status: 0xc000000f
Info: The Boot Configuration Data for you PC is missing or contains errors.

2017-08-25 18_54_32-Clipboard

Everything still worked great at our local office. So we figured something had changed on the networking side. But then we thought to test booting an unknown device and UEFI PXE works… Huh? Since Unknown Computers work, that basically rules out Networking. From any subnet that has to traverse a WAN connection to an ConfigMgr PXE server, UEFI PXE booting fails for computers that are in the ConfigMgr database. ‘Unknown’ computers boot fine. Legacy PXE works from all scenarios.

Computer Type Client Location Server Location UEFI PXE Legacy PXE
Known Computer Local Office Local Data Center Pass Pass
Known Computer Local Office Remote Data Center Fail Pass
Known Computer Remote Office Local Data Center Fail Pass
Known Computer Remote Office Remote Data Center Fail Pass
Unknown Computer Local Office Local Data Center Pass Pass
Unknown Computer Local Office Remote Data Center Pass Pass
Unknown Computer Remote Office Local Data Center Pass Pass
Unknown Computer Remote Office Remote Data Center Pass Pass

I tried every bit of advice the internet had to offer:

  • DHCP options 60, 66, 67 are NOT set on the subnet(s)
  • IP Helpers are in place on the router config to forward DHCP broadcasts
  • TFTP Options have been set to ensure that the block size is small enough for our VPN tunnels and prevent fragmentation
    • [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\DP]
      • “RamDiskTFTPBlockSize”=dword:00000550 (1360)
      • “RamDiskTFTPWindowSize”=dword:00000004 (4)
    • [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\WDSTFTP]
      • “MaximumBlockSize”=dword:00000550 (1360)
  • Tried different task sequences with difference boot images.
  • Tried updating boot images
  • Disabled and re-enabled PXE on the DPs to rebuild the PXE role.

I asked for some help from the networking team and I was able to get a router setup like one of our locations with a mirrored port.

I did some Wireshark captures from the client. The only difference in the Wireshark captures from a working and non-working client is the DCHP ACK contains option 243 and option 252 with the BCD file path:

Non-working client:
Wireshark1

Working client:
Wireshark2.png

So what gives?

After looking at the SMSPXE.log though I noticed that there were two attempts made to update the Device Cached LastAdv Time. On clients that were failing to boot, the ‘Client boot action reply’ found no advertisements:
smspxe1.png

So this got me thinking, maybe there was some sort of timeout happening after the first time the Device Cached LastAdv Time was updated.

I starting to poke around the ConfigMgr DB at the stored procedures, filtered down to ones with just ‘PXE’ in the name.

In the SQL stored procedure dbo.NBS_GetPXEBootAction I noticed the following SELECT statement:

select * from LastPXEAdvertisement as lpa where lpa.MAC_Addresses = @MACAddress AND lpa.LastPXEAdvertisementID = sp.OfferID
AND LastPXEAdvertisementTime < DATEADD(SECOND, -40, @CurrentTimeInUTC

Based on this, it look like ConfigMgr is only allowing up to 40 seconds for a device to complete the download of smsboot\x64\wdsmgfw.efi. Since our locations take longer than 40 seconds to download the NBP, they would then fail to show up in this query when the second request for this device is made, therefore breaking the boot process.

So I tried changing -40 to -120, as the slowest location we have takes about 90 seconds to download this file:

select * from LastPXEAdvertisement as lpa where lpa.MAC_Addresses = @MACAddress AND lpa.LastPXEAdvertisementID = sp.OfferID
AND LastPXEAdvertisementTime < DATEADD(SECOND, -120, @CurrentTimeInUTC

Computers are now UEFI PXE booting as expected!

It’s still possible that something changed on the networking / server side that’s causing these initial downloads to be slower, but at this time, I’m going to say…

success.jpg

Windows 10 Creators Update 1703 – Avoiding “Just a moment…” in a Task Sequence

Ensure the following is in your Unattend.xml in order to avoid waiting for “Just a moment…”

<OOBE>

<HideWirelessSetupInOOBE>true</HideWirelessSetupInOOBE>
<NetworkLocation>Work</NetworkLocation>
<SkipMachineOOBE>true</SkipMachineOOBE>
<SkipUserOOBE>true</SkipUserOOBE>
<HideOEMRegistrationScreen>true</HideOEMRegistrationScreen>
<HideEULAPage>true</HideEULAPage>
<HideLocalAccountScreen>true</HideLocalAccountScreen>
<HideOnlineAccountScreens>true</HideOnlineAccountScreens>

</OOBE>

Normally ConfigMgr handles updating the xml file for smooth task sequencing. But this seems to be something left out of ConfigMgr 1702 / ADK 1703.

I would recommend using the Windows System Image Manager from the ADK to make these changes to your Answer File as it will do validation.

How to Add URL to a Start Tile Layout Which Opens Using the Default Browser

Had a requirement to add webpage links to a Start Tile Layout, but found that *.URL files wouldn’t work.

The solution is to use explorer.exe as the launching application. Just like typing http://google.com into the file explorer address bar, creating a shortcut with explorer.exe as the program and http://google.com as the parameter works like a charm.

You can of course change the icon too.

2017-06-02 21_53_42-Google Properties

OS Deployment – Change Boot Media During a Running Task Sequence

We still have a couple hundred Windows XP computers which need to be upgraded to a supported operating system. For anyone that’s used ConfigMgr 2012/CB, you’ll know that you need to use the WinPE 3.1 Boot Media in order for Windows XP to properly stage the boot.wim otherwise you will get an error and an unbootable system.

But this presents a problem. It means that you’ll need to maintain at least 2 task sequences: one that boots on Windows XP, and one that boots on everything else.

But I think we can do better! Let make one task sequence to rule them all!

So how can we do this?

I started with a couple of pieces of knowledge:

  1. _SMSTSBootImageID is the task sequence variable that identifies which boot image is assigned to the task sequence. (https://technet.microsoft.com/en-us/library/hh273375.aspx)
  2. TSEnv2.exe is a free tool from 1E that allows you to change task sequence variables (even read only task sequence variables!) at run time. (http://info.1e.com/website-freetools-1e-tsenv2)

So I tried the obvious. I created a package with TSEnv2.exe, and during a test task I added a command line step to run:

x86\TSEnv2.exe set _SMSTSBootImageID=AAAXXXXX

Where AAAXXXXX is your boot image Package ID of your WinPE 3.1 Media.

While a step in the right direction, this failed spectacularly.

Next thing I tried was to assign the WinPE 3.1 Media to the same task sequence. While the task sequence was running, I launched CMD as SYSTEM and ran the TSEnv2.exe list > c:\TSEnv2.txt to dump the variables to a text file. I then did a search for all references of AAAXXXXX. While there were search results to that Package ID, there were a couple more lines struck me:

_SMSTSHTTPAAAXXXXX=https://dpserver.local/SMS_DP_SMSPKG$/AAAXXXXX,https://dpserver.local/NOCERT_SMS_DP_SMSPKG$/AAAXXXXX
_SMSTSAAAXXXXX=http://dpserver.local/SMS_DP_SMSPKG$/AAAXXXXX,https://dpserver.local/NOCERT_SMS_DP_SMSPKG$/AAAXXXXX

These both referenced the download URL of the boot image.

I added two more command line steps to run:

x86\TSEnv2.exe set _SMSTSHTTPAAAXXXXX=https://dpserver.local/SMS_DP_SMSPKG$/AAAXXXXX,https://dpserver.local/NOCERT_SMS_DP_SMSPKG$/AAAXXXXX
x86\TSEnv2.exe set _SMSTSAAAXXXXX=http://dpserver.local/SMS_DP_SMSPKG$/AAAXXXXX,https://dpserver.local/NOCERT_SMS_DP_SMSPKG$/AAAXXXXX

So now I put these three command line steps within a group that only runs under Windows XP, and boom! The task sequence will change the boot image! Only one task sequence now 🙂