Unable to update X86 default boot image after upgrade to ADK 2262 on MEMCM 2203

John Biggston 71 Reputation points
2022-06-16T14:30:42.873+00:00

I recently upgraded my site to the latest ADK and then upgraded the site to 2203, with reboots in between. I've installed the ADK as well as the Preinstallation environment add-ons. Since then I'm unable to create a new MDT boot image, or update the distribution points on the X86 image, however, updating the default x64 image works fine.

The error I get when trying to create an MDT boot image is:
212133-image.png

This make sense as the latest ADK doesn't have an x86 boot image to source from, so that path doesn't exist, but I'm not trying to create an x86 image.

If I try to update the default x86 image, I get:

Error: The wizard detected the following problems when updating the boot image.
· Failed to insert OSD binaries into the mounted WIM file
The SMS Provider reported an error.: ConfigMgr Error Object:
instance of SMS_ExtendedStatus
{
· Description = "Failed to inject OSD binaries into mounted WIM file (often happens if unsigned drivers are inserted into x64 boot image)";
· ErrorCode = 2152205056;
· File = "X:\bt\1116398\repo\src\SiteServer\SDK_Provider\SMSProv\sspbootimagepackage.cpp";
· Line = 5498;
· ObjectInfo = "CSspBootImagePackage::PreRefreshPkgSrcHook";
· Operation = "ExecMethod";
· ParameterInfo = "SMS_BootImagePackage.PackageID=\"XXX000002\"";
· ProviderName = "WinMgmt";
· StatusCode = 2147749889;

I cant edit the default x86 image as it is now out-of-date, however I can edit the x64 image and there are no drivers installed in it and it updates fine.

Is this a known issue with the latest ADK and MEMCM 2203? If not are there any suggestions to fix this?

Thanks

Microsoft Configuration Manager Deployment
Microsoft Configuration Manager Deployment
Microsoft Configuration Manager: An integrated solution for for managing large groups of personal computers and servers.Deployment: The process of delivering, assembling, and maintaining a particular version of a software system at a site.
906 questions
Microsoft Configuration Manager
Accepted answer
  1. Per Nordqvist 91 Reputation points
    2022-07-28T12:35:25.05+00:00

    My solution was to copy amd64 folder in that path and then change the name to x86.
    225833-image.png
    This must be a bug then ADK does not support x86 but still looks after the folder then you are creating a Boot Image usin MDT

    Regards Per

    3 people found this answer helpful.

3 additional answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Simon Ren-MSFT 30,491 Reputation points Microsoft Vendor
    2022-06-17T02:22:09.32+00:00

    Hi,

    Thanks for posting in Microsoft MEM Q&A forum.

    This is by design: The 32-bit versions of Windows PE (WinPE) in the WinPE add-ons for Windows 11 and Windows Server 2022 aren't supported.

    212267-windows-adk-support.png

    Please refer to the official article: Support for the Windows ADK in Configuration Manager

    Hope it helps. Thanks for your time.

    Best regards,
    Simon

    If the response is helpful, please click "Accept Answer" and upvote it.
    Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

    0 comments
  2. John Biggston 71 Reputation points
    2022-06-20T12:46:51.963+00:00

    Hi Simon,
    The problem isn't that the 32-bit version isn't supported, it's that I can't create any MDT-based boot image, including 64-bit, since the upgrade. Are MDT-based boot images not supported?

  3. Reccoppa, Michael 1 Reputation point
    2023-03-08T21:53:54.48+00:00

    I don't know if you're still having this issue, but I just came across it after updating ADK for Windows 11 22H2. I have this when trying to create an x64 MDT boot image. It still looks for the 32-bit location even if you try to create a 64-bit boot image. This article explains it a bit more.

    https://learn.microsoft.com/en-us/mem/configmgr/mdt/known-issues

    It's a little frustrating, but isn't that the Microsoft way?

    0 comments