Config Manager Boot Images not working after site upgrade to 2111

Question

Config Manager Boot Images not working after site upgrade to 2111

Phil 96

Hi,

I need some help in diagnosing this issue further.

I have just updated a Endpoint Configuration Manager (SCCM) site to current branch version 2111 (with Hotfix KB12959506)

As part of the upgrade I also updated to ADK 10.1.1904.1 (Windows 10)

I have rebuild my boot images with no errors reported.
However, when booting the updated image, either via PXE or Boot Media, the client loads the image, starts WinPE, then immediately reboots.
Not even a sign that it is trying to start networking / connect to CM.
I know that this can be indicative of missing network drivers, but am pretty sure this is not the case here.
I get the same error when running from a Hyper-V VM, and have also confirmed that the WinPE.wim file on which the image is based has the correct drivers, as I can boot WinPE and successfully connect to the network when using this image (without the CM additions).
I did this by replacing boot.wim in my CM boot media with the native one from winpe.wim from the ADK PXE add-on installed on the site server.

I am unable to obtain any client logs as it immediately reboots.
All looks well from the PXE logs on the DP (and as I get the same issue when booting from an ISO I know its not network boot related)

If I boot using a old boot media ISO, the client connects to the site and starts the Task Sequence Wizard, so the problem appears to be with the new boot image only.

Does anyone have any suggestions of a possible cause or further diagnosis options please.?
I have spent all day on this, trying various things, rebuilt my boot images many times, but still get the same issue (WinPE loads then immediately restarts)
Have even done a screen recording of the VM in the hope of seeing a brief error message before the restart - but nothing.

Worth mentioning that I also have access to another (completely separate) CM site which is running the same versions (without the Hotfix so 5.00.9068.1000) - with no issues.

Thanks in anticipation,
Phil

6 answers

Your answer

Answer 1

By default ConfigMgr has no winpeshl.ini file in the OSD\bin\x64 folder. It generates the winpeshl.ini file on the fly. Also the one it generates on the fly has the following syntax:

[LaunchApps]
%SYSTEMDRIVE%\sms\bin\x64\TsBootShell.exe

Note that there is no line with wpeinit.exe as your example shows. Wpeinit.exe is executed later by the actual task sequence and is viewable in smsts.log.

ConfigMgr does allow custom winpeshl.ini files by putting a custom one in the OSD\bin\x64 folder, but by default one does not exist in there. Most likely if you delete the winpeshl.ini file from the OSD\bin\x64 folder and then rebuild the boot image, it will also fix the problem. I am not sure how that custom winpeshl.ini file got into that directory, but that is not something that ConfigMgr usually creates.

Gerber Patrick BIT 61 Reputation points

2023-01-11T23:13:55.59+00:00

thanks for your hint, after deleting the winpeshl.ini all went fine. this ini was configured by a 3rd party background image solution.

Answer 2

I had the exact same symptoms as this, but it was a different issue.

I was getting the following in my smsts.log

It appears the update to 2111 changes some of the runtimes that TSBootshell, TSPxe and the like use. For some reason when my boot images got refreshed as part of the upgrade to 2111, these new runtime DLLs did not get copied across to the WIMs.

I did a quick test to see if this was the case by live injecting the missing DLLs into the X:\SMS\Bin\X64 folder when booted from the WinPE environment...

net use z: \\[SCCM_Server]\[Install_Drive]  
copy "Z:\Program Files\Microsoft Configuration Manager\OSD\bin\x64\msv*.dll" X:\SMS\bin\x64 /y  
copy "Z:\Program Files\Microsoft Configuration Manager\OSD\bin\x64\vc*.dll" X:\SMS\bin\x64 /y

Then reran:

tsbootshell.exe

And it all came back fine!

After this, I inspected the OSDInjection.xml file (under Program Files\Microsoft Configuration Manager\bin\X64) , and while some of the older files are still in there, it doesn't appear that the newer ones are, so I added them under <Architecture imgArch="x64"> <FileList source="SCCM"> (just after the entry for msvcr120.dll). You may need to add an entry for x86 too.

      <File name="msvcp140.dll">  
        <LocaleNeeded>false</LocaleNeeded>  
        <Source>bin\x64</Source>  
        <Destination>sms\bin\x64</Destination>  
      </File>  
      <File name="msvcp140_1.dll">  
        <LocaleNeeded>false</LocaleNeeded>  
        <Source>bin\x64</Source>  
        <Destination>sms\bin\x64</Destination>  
      </File>  
      <File name="msvcp140_2.dll">  
        <LocaleNeeded>false</LocaleNeeded>  
        <Source>bin\x64</Source>  
        <Destination>sms\bin\x64</Destination>  
      </File>  
      <File name="vcruntime140.dll">  
        <LocaleNeeded>false</LocaleNeeded>  
        <Source>bin\x64</Source>  
        <Destination>sms\bin\x64</Destination>  
      </File>  
      <File name="vcruntime140_1.dll">  
        <LocaleNeeded>false</LocaleNeeded>  
        <Source>bin\x64</Source>  
        <Destination>sms\bin\x64</Destination>  
      </File>

Rebuilt the boot images and bam - fixed! Not sure why OSDInjection.xml didn't get updated - perhaps it's because I have some sneaky files in there that I want to be part of the Boot Image?

Got to say thanks to the guys on this Reddit thread who were looking at a similar thing. hd0u8ma

Hope this is useful to someone else who had the same issue!

Cheers, Jack

Simon Ren-MSFT 40,346 Reputation points Microsoft External Staff

2022-03-29T01:38:15.207+00:00

Hi @jackrt ,

Thanks very much for your feedback and sharing! Have a nice day!

Best regards,
Simon

Answer 3

That is actually another known issue. If someone has manually modified the OSDInjection.xml file, ConfigMgr may not replace it if it needs to update that file during an upgrade. It may need to update OSDInjection.xml if it needs to add new or additional components to the boot image as part of the upgrade. If it doesn't update OSDInjection.xml, then those new components are not added to the boot image, and you get the errors you are seeing in the log. Note that third party add-ons like Nomad may also update OSDInjection.xml. This issue is being looked at to be fixed in a future version of ConfigMgr.

Answer 4

Phil 96

So, I've found the problem...

Turns out the file winpeshl.ini has this command in it which is invalid:
(X:\sms\pkg\sms1000\TSBackground\TSBackground.exe does not exist!)

Looking at the previous working image, It should be this:

Changing the file in the OSD\bin\x64 folder on the site server and redistributing the boot image fixed the issue.

So I guess this is a bug/error in the CM update.

Amandayou-MSFT 11,156 Reputation points

2022-02-17T06:27:10.023+00:00

Hi,

Thanks for your updating and reporting.

I will try the best to deliver the information to the product team to see if they have some additional comments, but not guaranteed. Once there is a reply, I will get back to you at the first time. thank you for your kind understanding. Meanwhile, we could wait for any other has the similar issue.

Best regards,
Amanda
Matthew Isaacs 1 Reputation point Microsoft Employee

2022-02-22T14:30:05.62+00:00

Phil -

I experienced the same exact problem at my customer immediately after my 2111 upgrade. I reached out to Frank Rojas about this and told him what happened to me and also sent him the link to your posting, to show that it wasn't an isolated incident. Frank is totally correct that the winpeshl.ini does not exist by default in the OSD directories and instead gets generated and injected on-the-fly when you update the boot images. After searching around for tsbackground.exe, I found this: https://onevinn.schrewelius.it/Files/TSBackground/TSBackground.pdf. TSBackground is a 3rd party OSD customization tool. In order to implement it, two things need to be done. First, you have to modify the boot image properties to include a prestart command and source files. Second, you have to create a custom winpeshl.ini, which will launch the tsbackground.exe (included in the source files) instead of the default tsbootshell.exe. So it sounds like you ran into the same problem I did. Someone at my site must have created the custom winpeshl.ini but didn't modify the boot image properties. When I went to update the boot images, just like you did, the custom winpeshl.ini got injected. When the boot image started, it tried to kick off the tsbackground.exe, but since it wasn't included in the source files, it failed and caused an immediate reboot.

Answer 5

Phil 96

Hi,

Thank you @Frank Rojas / @Matthew Isaacs for the feedback.

This is making more sense now.

Frank - you are quite correct, deleting the winpeshl.ini file from the OSD\bin\x64 folder, and rebuilding the image did indeed cause the file to be recreated and injected in to the image (but not created in the OSD\bin\x64 folder on the server).

This would also explain why I am not seeing the file on my other 2111 site!

So it would appear likely that the issue was caused by a previous admin or process creating the (bad) winpeshl.ini file in the server folder OSD\bin\x64 folder and not rebuilding the image.
Hence, I experienced the issue following the site update and subsequent image rebuild.

Regards

Amandayou-MSFT 11,156 Reputation points

2022-02-23T02:34:25.74+00:00

Hi,

Thanks for your update and frankrojas's patient answer.

If frankrojas is helpful, please accept the answer of frankrojas, so that people who encounter the same problem can solve the problem better.

Best regards,
Amanda You

Share via

Config Manager Boot Images not working after site upgrade to 2111

6 answers

Your answer