Forums on Intune, SCCM, and Windows 11

Welcome to the forums. Register a free account today to become a member! Once signed in, you'll be able to participate on this site by adding your topics and posts, as well as connect with other members through your own private inbox!

PENDING Unable to add Boot Image to Config Manager, ErrorCode = 2151811598;

  • Thread starter Thread starter surfrock66
  • Start date Start date
  • Replies Replies 16
  • Views Views 13K

surfrock66

Member
Messages
23
Solutions
2
Reaction score
0
Points
1
We are on MCM 5.00.9122.1000. We are attempting to deploy Windows 10 22H2. I have used 2 different ADK versions, 22H2 (10.0.22621) and 23H2 (10.0.25398) (I made sure to reboot after the uninstall AND after the install any time I did a version change) but both are showing the same results. I validated that the ADK and the Win-PE add-on were the same version each time. We are not loading any drivers into the boot image, so that is not a factor.

Once I create my boot image, I go to add it to CM, and I get the following error:

ConfigMgr Error Object:
instance of SMS_ExtendedStatus
{
Description = "Error retrieving object PackageID=";
ErrorCode = 2151811598;
File = "K:\\dbs\\sh\\cmgm\\1026_005344\\cmd\\u\\src\\SiteServer\\SDK_Provider\\SMSProv\\SspInterface.h";
Line = 1199;
Operation = "GetObject";
ParameterInfo = "SMS_BootImagePackage.PackageID=\"\"";
ProviderName = "ExtnProv";
StatusCode = 2147749890;
};

-------------------------------
Microsoft.ConfigurationManagement.ManagementProvider.WqlQueryEngine.WqlQueryException
The SMS Provider reported an error.


Stack Trace:
at Microsoft.ConfigurationManagement.ManagementProvider.WqlQueryEngine.WqlResultObjectBase.get_ObjectClass()
at Microsoft.ConfigurationManagement.AdminConsole.OsdCommon.OsdImageWizardForm.PostApply(BackgroundWorker worker, DoWorkEventArgs e)
at Microsoft.ConfigurationManagement.AdminConsole.ProgressPage.backgroundWorkerPostApply_DoWork(Object sender, DoWorkEventArgs e)
at System.ComponentModel.BackgroundWorker.OnDoWork(DoWorkEventArgs e)
at System.ComponentModel.BackgroundWorker.WorkerThreadStart(Object argument)

-------------------------------

System.Management.ManagementException
Not found


Stack Trace:
at Microsoft.ConfigurationManagement.ManagementProvider.WqlQueryEngine.WqlResultObjectBase.get_ObjectClass()
at Microsoft.ConfigurationManagement.AdminConsole.OsdCommon.OsdImageWizardForm.PostApply(BackgroundWorker worker, DoWorkEventArgs e)
at Microsoft.ConfigurationManagement.AdminConsole.ProgressPage.backgroundWorkerPostApply_DoWork(Object sender, DoWorkEventArgs e)
at System.ComponentModel.BackgroundWorker.OnDoWork(DoWorkEventArgs e)
at System.ComponentModel.BackgroundWorker.WorkerThreadStart(Object argument)

-------------------------------

I did notice that in SMSProv.log I see this:
Failed to mount file C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Windows Preinstallation Environment\amd64\en-us\{1BF23E9A-A084-45B4-956E-AD57E2C2765C}.wim. Error code = 5~ $$<SMS Provider><02-29-2024 10:51:11.415+480><thread=13864 (0x3628)>
~*~*~K:\dbs\sh\cmgm\1026_005344\cmd\u\src\SiteServer\SDK_Provider\SMSProv\sspbootimagepackage.cpp(4980) : Failed to export default x64 boot image from ADK installation source~*~*~ $$<SMS Provider><02-29-2024 10:51:11.458+480><thread=13864 (0x3628)>
~*~*~Failed to export default x64 boot image from ADK installation source ~*~*~ $$<SMS Provider><02-29-2024 10:51:11.459+480><thread=13864 (0x3628)>
But that doesn't make sense, as that's not the path to the wim in the adk:
1709239417054.png

I've done a lot of research, and thus far what I've tried swapping ADK versions between 22H2 and 23H2, though I have not gone earlier. I am seeing a lot of advice to go with the boot image 10.0.22000.1 from a prior ADK, but that's getting kind of old and I wanted validation that it is still good advice.
 
Solution
Ok, we solved it, and it was NOT what I thought.

A year ago we got cyber-attacked and a remediation company was brought in, made a bunch of changes, stopped responding to our instructions and several months later we severed ties. Ultimately I believe their intention was to replace all on-staff IT services with their company (and we are a medical school building a hospital, and I think they were auditioning to become the IT provider for the hospital), but they were a mess...they took over pushing updates, and accidentally installed software licensed to other customers on all our servers with a bad push. We cannot contact them to ask what they did in our environment.

Ok, enter now. I'm troubleshooting, and in event viewer...
I am also noticing that the default boot images were not created at MCM install (this is a fresh install) which is unexpected. Could there be something more globally wrong with my CM install?
 
If the boot images aren't created, you'll have to manually create them. This is a common issue, and I had encountered it while working on a customer's setup.
 
How would I do that? When I try to create custom images, I'm getting that failure, is there a guide for making the default ones just to get it all started?
 
I'm going through that, but it seems the newest ADK is not detected by the MDOP installer. I'm gonna go back to 20.04, I'm not seeing an official compatability matrix anywhere.
 
Sorry to revive a dead thread, but I'm just coming back to this after a high priority project. I've been experimenting in a bunch of ways but getting the same results. After going down the DaRT path (which is installed) the step is to create a boot image in ConfigMgr using "Create Boot Image using MDT" but that doesn't show up for me (see below)? MDT is installed and I thought it was properly integrated (I've run the "Configure ConfigMgr Integration" and it defaults to remove), but I get nothing in the console:

I've uninstalled/reinstalled the ADK (I'm currently using ADK 10.1.25398.1 on Config Manager 5.0.0.9122.1018, Windows Server 2019) to no avail. I've messed with permissions on the share the wim is located (on both a file server and the OSD share). I'm getting the exact result no matter what I try.

1712245212242.png
 
I have this exact same issue, it also prevents me creating new driver packages with a "not found" error when specifying the UNC path to the new driver package. Adding Everyone with full access to the SMB share permissions to the share where the package is to be created resolves the issue, so it is clearly SMB permissions related but obviously this is not an acceptable solution.
Did you get anywhere with your problem?
 
I have this exact same issue, it also prevents me creating new driver packages with a "not found" error when specifying the UNC path to the new driver package. Adding Everyone with full access to the SMB share permissions to the share where the package is to be created resolves the issue, so it is clearly SMB permissions related but obviously this is not an acceptable solution.
Did you get anywhere with your problem?
Note that both my account and the AD computer account for the primary site server already have full access permissions to the share, which to my knowledge is all that should be required.
 
No, I am still stuck. I have too many projects to get any focus on this; can I ask, did you have a previous MDT install on this computer before setting up SCCM? We did on the one we're using, and I'm wondering if there's something left behind.
 
No, I am still stuck. I have too many projects to get any focus on this; can I ask, did you have a previous MDT install on this computer before setting up SCCM? We did on the one we're using, and I'm wondering if there's something left behind.
This happened to me after doing reinstall from backup on new hardware. I didn't install MDT initially as we'd switched to UI++, but I reinstalled it try and solve the problem it didn't help. Given that the everyone full access permissions on the share fixes it, its clearly a permissions issue of some kind.
 
This happened to me after doing reinstall from backup on new hardware. I didn't install MDT initially as we'd switched to UI++, but I reinstalled it try and solve the problem it didn't help. Given that the everyone full access permissions on the share fixes it, its clearly a permissions issue of some kind.
Cracked my problem, the SMB share permissions for the folder you're doing drivers or boot images in need to have the user who is running the admin console explicitly added by username (not via a group or anything), I also did the same for the ntfs permissions.
 
Cracked my problem, the SMB share permissions for the folder you're doing drivers or boot images in need to have the user who is running the admin console explicitly added by username (not via a group or anything), I also did the same for the ntfs permissions.
That is a fantastic tip that I will try as soon as I get the chance!
I also added to the share and NTFS permissions a group which contains the primary site servers computer account (as well as the computer account also being on both directly) not sure if that helped or not.
 
Hello,

I'm having the same problems this morning. When I try to upload a boot image I get the same error. I tried philw86 suggestion to add to the share the user account that manages configuration console but no luck. If anyone can assist I would greatly appreciate it.
 
Ok, we solved it, and it was NOT what I thought.

A year ago we got cyber-attacked and a remediation company was brought in, made a bunch of changes, stopped responding to our instructions and several months later we severed ties. Ultimately I believe their intention was to replace all on-staff IT services with their company (and we are a medical school building a hospital, and I think they were auditioning to become the IT provider for the hospital), but they were a mess...they took over pushing updates, and accidentally installed software licensed to other customers on all our servers with a bad push. We cannot contact them to ask what they did in our environment.

Ok, enter now. I'm troubleshooting, and in event viewer, "Application and Services Logs" -> "Microsoft" -> "Windows" -> "Windows Defender" -> "Operational" I see this 2 1121 warnings that coincide with trying to load the boot image:

Code:
Microsoft Defender Exploit Guard has blocked an operation that is not allowed by your IT administrator.
 For more information please contact your IT administrator.
     ID: D1E49AAC-8F56-4280-B9BA-993A6D77406C
     Detection time: 2024-04-22T23:36:08.876Z
     User: NT AUTHORITY\SYSTEM
     Path: C:\Windows\System32\wimserv.exe
     Process Name: C:\Windows\System32\wbem\WmiPrvSE.exe
     Target Commandline: wimserv.exe a133ec42-3686-4ccf-86f2-0edf278e4ba2
     Parent Commandline: C:\WINDOWS\system32\wbem\wmiprvse.exe -Embedding
     Involved File:
     Inheritance Flags: 0x00000000
     Security intelligence Version: 1.409.441.0
     Engine Version: 1.1.24030.4
     Product Version: 4.18.24030.9
   
    Microsoft Defender Exploit Guard has blocked an operation that is not allowed by your IT administrator.
 For more information please contact your IT administrator.
     ID: D1E49AAC-8F56-4280-B9BA-993A6D77406C
     Detection time: 2024-04-22T23:36:08.862Z
     User: NT AUTHORITY\SYSTEM
     Path: C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Deployment Tools\amd64\DISM\wimserv.exe
     Process Name: C:\Windows\System32\wbem\WmiPrvSE.exe
     Target Commandline: wimserv.exe a133ec42-3686-4ccf-86f2-0edf278e4ba2
     Parent Commandline: C:\WINDOWS\system32\wbem\wmiprvse.exe -Embedding
     Involved File:
     Inheritance Flags: 0x00000000
     Security intelligence Version: 1.409.441.0
     Engine Version: 1.1.24030.4
     Product Version: 4.18.24030.9

The ID D1E49AAC-8F56-4280-B9BA-993A6D77406C led me here: https://learn.microsoft.com/en-us/m...e?view=o365-worldwide#asr-rule-to-guid-matrix

Specifically: "Block process creations originating from PSExec and WMI commands". I had to find that rule in the security console and disable it (as it's specifically contra-indicated when using config manager). On the server itself to disable the rule I did this:

Code:
Set-MpPreference  -AttackSurfaceReductionRules_Ids d1e49aac-8f56-4280-b9ba-993a6d77406c  -AttackSurfaceReductionRules_Actions Disabled

That took way longer to troubleshoot than it should, but it's 100% solved for me.
 
Solution
Back
Top