Software

Hello,

Did you manage to get rid off this error ?

I have currently the same with W10 22h2 image.

Thanks.

I've had similar results when deploying images from SCCM.  Possible fixes included:

* Delete all possible names for the device from AD and from SCCM, change from domain to Workgroup without rebooting, rejoin AD, wait for SCCM to pick up the name, redeploy the SCCM client, start the SCCM image process.

* In BIOS remove all EUFI boot points, boot to Zen boot disk (We're moving from Zen to SCCM), remove all occupied partitions, redeploy previous Zen base image, wait for SCCM to pick up the system name, deploy the SCCM client, start the SCCM image process.

* Boot to the Zen Boot disk, zero out the hard drive (dd if=/dev/zero of=/dev/sda (or of=/dev/nvme  depending on drive type ) bs=2048M status=progress && sync && echo done!      After the drive is zeroed out, redeploy Zen Base image, wait for SCCM to pick up the system name, deploy the SCCM client, start the SCCM image process.

I expect that a hand install of the OS to the problem unit could have been a viable substitute for "redeploy Zen Base image".

Zeroing out the hard drive in the manner listed above can also be done from a Linux Live CD/DVD/USB boot, or from products like Boot & Nuke or DBAN.  It also zeros the image safe area so the part of hard storage where the computer name and dns hostname are stored will be wiped out so unless they're added back prior to imaging, after imaging the system will have a default windows name of some sort.

There are two ways to tackle this:

1- For Glory:
https://support.quest.com/kace-systems-deployment-appliance/kb/4286974/how-to-gather-logs-from-kbe-to-troubleshoot-a-windows-deployment

You will need to pull Windows Logs via KBE, and analyze them to see why this sort of BSOD is happening. This will take time unless you are experienced with Windows Logs debugging.

2- For Simplicity:
 -Make sure your Image was captured from a VM not from a physical device. (VMs produce stable images).
 -Make sure the OS that was Sysprepped, was installed from an ISO using whatever build you want to deploy. (It is considered Bad practice to Sysprep upgraded Windows versions, if you check your Volume License Portal, MS Offers ISOs patched and updated up to last mont).
 -BSODs are normally tied to drivers, you could try to deploy the same image again, and uncheck the box to Use Driver Feeds from your Image before testing. If that works check if the drivers supplied by case, are the latest ones from the ENTEPRISE DELL site (not from support.dell.com).

@Channeler

Thank you for your response, I will see what I can do with the logs.

to answer the Simplicity questions: 

It is from a VM, It was a clean ISO install on the VM (not an upgrade) and was sysprepped successfully.

I will try without the drivers as suggested as well.

Thanks again

Unfortunately, without drivers, it came up with the same message

I ran into an odd issue where it kept trying to start to another UEFI load point that no longer existed.  Possible delete all UEFI disk boot points and try it again?

@ jmogle

Thank you for your reply, I have never done that - do you have the steps to remove the UEFI boot points?

thanks,

In Bios settings, remove any UEFI boot entry on the boot menu that is not PXE boot.  Depends on the system where it is. I don't have a Dell AIO in front of me but it is usually in the boot sequence.

ok will try that, thanks

Unfortunately, no luck keeps getting the msg, in fact, I get it on the VM I capture from as well, perhaps that is part of the issue.