Hi Sven.

Yes, absolutely, we're deploying Win11 at several customers right now, without issues (other the one that the Imaging Update fixes, that after windows being fully patched, with secure boot enabled the imaging won't boot with the sbat error).

Please describe in more detail how your image was prepared and how is it being restored. Is it a script? Linux or Winpe imaging?

The first error occurs when either the partition layout of the restored windows isn't correct/complete, or when the restored windows image is lacking storage drivers.

The second issue could again be storage drivers, or partitioning issues, like trying to restore into a too small partition, or into the wrong partition type (GPT vs. MBR).

We currently don't use WinPE but rather the Linux imaging variant, and if possible, I'd prefer to continue using it for Windows 11 as well.

The images are of Windows with the latest patches. I run Sysprep, which shuts down the master image, and then I capture the image. This process has worked since Windows 7, all the way through Windows Server 2022 and Windows 10 21H2.

However, I also imaged Windows 11 24H2 without any modifications or Sysprep, and here I immediately encountered the error "Decompression error occurred" during the restore. If the restore works on a different system, I get the error \WINDOWS\system32\winload.efi Error Code: 0xc000000f on the first boot. I suspect the Linux imaging process might be the cause here.

The partition structure and size of the HDD are correct after the restore.

For Testing Purposes, I would recommend trying WIndows 11 23H2 to see if you are having the same issue and if it's a Windows 11 vs Windows 11 24H2 issue.  

Also make sure you are disabling "SIDChanger on your Imaging Server"....

https://www.novell.com/documentation/zenworks-2020/zen_cm_preboot_imaging/data/bg4iu9s.html#bg4iu9w

Note sure if that is your issue, but something highly recommended WIndows 10 or greater...It gets more critical as time marches on.

ZENWorks WInPE does not support SIDChanger by design as it's just a legacy feature that should not be used anymore.

Okay, I will prepare a test with Windows 11 23H2.

I don't believe it's an SSID issue, as the restore already fails.

The same thing happens with a Windows 11 23H2 (release October 2023) image created directly after installation. On the target system, the restore fails after a few seconds with a 'Decompression error occurred'. The HDD is, of course, more than large enough.

"With an image using comp=0, I get a different error message during the restore: 'Out of space on destination'. The partition structure looks correct after the failure, exactly like on the source system, and the HDD offers more than enough space, so I don't understand the error message.

If I restore a Windows 10 image on the same target system, there are no problems."

To me, all the issues you encounter point towards the imaging process somehow mixes up the partitions. It either attempts to restore the OS image to a wrong partition (too small), or, if the restaore of the image succeeds, it then boots from the wrong partition.

That may also indicate the difference between our setup. I restore windows using a script and restore each partition individually.

Do you also back up all partitions individually, or just the recovery partition?
Could you send or post your script, or parts of it, so I can give it a try as well?

Still, the image shouldn't normally cause any errors here

Hi Sven, I just tested Win11 with 24.2  incl. latest Server FTF (186) and September Imaging Updates and the imaging process for Windows 11 23H2 is working fine without any issues

I only thing I do, is to change the default partition order as it´s much better to have the Windows partition as partition 4...

My Windows Reference Image also has this partition layout

Extract from my script:

.....

CREATE_PARTITIONS ()
(
img -pd -all
img -pc 1 -type=NTFS -size=600 -guid=WRE
img -pc 2 -type=FAT32 -size=150 -guid=ESP
img -pc 3 -type=NTFS -size=128 -guid=MRP
img -pc 4 -type=NTFS -guid=MBD
img -pa1
img -pa2
img -pa3
)

....

RESTORE_IMAGES ()
{
#Restore Images
IMG_ROOT=CUSTOMER/OPENTEXT
IMAGESERVER=$PROXYADDR
img -rp $IMG_ROOT/WIN11EE/W11EE-BASE-23H2-X64-MUI.zmg -ip=${IMAGESERVER} -ap=a1:p1 -ap=a2:p2 -ap=a4:p4
img -rp $IMG_ROOT/WIN11EE/W11EE-SYSPREP-X64-DE.zmg -ip=${IMAGESERVER} -ap=a2:p4
img -rp $IMG_ROOT/WIN11EE/W11EE-${HW_TYPE}-X64.zmg -ip=${IMAGESERVER} -ap=a2:p4
img -rp $IMG_ROOT/WIN11EE/DRIVERS/WIN11-${HARDWARE_IMAGE}.zmg -ip=${IMAGESERVER} -ap=a2:p4
img -rp $IMG_ROOT/WIN11EE/W11EE-ZCMAGENT-X64.zmg -ip=${IMAGESERVER} -ap=a2:p4
}

....

#################### MAIN Script ###########################
WORKSTATION_INFO
#read -p "Press [Enter] key to start imaging..."
GET_WSNAME
GET_HWINFO
CREATE_PARTITIONS
RESTORE_IMAGES

sidChange -i

###############

Regards

Oliver

Hi Oliver, could you maybe test the whole thing again with the standard Windows partition layout?

if I created the partitions like you and then use my standard windows 11 24h2 / 23h2 image

img -pd -all
img -pc 1 -type=NTFS -size=800 -guid=WRE
img -pc 2 -type=FAT32 -size=150 -guid=ESP
img -pc 3 -type=NTFS -size=128 -guid=MRP
img -pc 4 -type=NTFS -guid=MBD
img -pa1
img -pa2
img -pa3

img -rl ap=a1:p2 -> OK # ESP

img -rl ap=a4:p1 -> NOK # WRE

img -rl ap=a3:p1 -> NOK # MBD

a3 and a4 is pointing to the (MBD)

Image Explorer is showing 4 Partitions, img just 3.

Could there be the Problem