OSDCLOUD Fails - Could not find proper Windows Image deployment

[RunCMD-123]

Describe the bug
Issue started yesterday - all new OSDCloud deployments fail using usb Method.
Error States "could not find a proper Windows Image for deployment"
We have tried multiple USB's, and multiple networks
23H2 and 24H2 produce the same error - En-GB
Multiple devices tested (HP and Microsoft)

[Triipie19]

We are seeing this issue too with 24H2, exactly the same as you are experiencing.

Our workaround is to use the previous ESD and select it via the GUI drop-down if you have it available on the USB.

[OSDeploy]

Is it possible the ESD is corrupt? Can you open PowerShell and run Get-WindowsImage against the ESD. Result?

[RunCMD-123]

One of my colleagues spotted it's hitting the fat32 limitation. I'll look at converting the boot device to NTFS later on this morning

[RunCMD-123]

Fix is to format usb with NTFS and then use Rufus to create the usb from the iso.

[Triipie19]

I can confirm that imaging with an NTFS USB works. Seems like with the new ESDs just eclipsing 4GB, FAT32 file systems can't deal with it and as Rufus defaults to FAT32, here we are.

I'm not sure off the top of my head which file system New-OSDCloudUSB creates, but looking at the documentation it seems to be NTFS so if that's true, then no code changes would be needed.

It just means for us that have remote USBs and use Rufus to image them, we'll need to make sure that we tell Rufus to use NTFS rather than FAT32.

[OSDeploy]

You need FAT32 for UEFI booting ... so you can't simply change the USB to NTFS. OSDCloud creates the USB with two partitions. I'll have to add in a check to check the filesystem on the USB and if FAT32, don't cache.

[MichaelEscamilla]

@RunCMD-123 and @Triipie19, any chance I could ask why you use Rufus to build your USBs instead of the 'New-OSDCloudUSB' function? Just curious as it seems like this is coming for a few others as well.

When using Rufus, you end up with the whole drive being FAT32 like below:

But with the 'New-OSDCloudUSB' function, you'll get the 2GB FAT32 portion for the booting, and then the caching is done to the other NTFS partition like below:

[OSDeploy]

@MichaelEscamilla It's possible one person creates an ISO and shares it with a team. The team can then use Rufus to write the ISO to USB disk.

[Triipie19]

@MichaelEscamilla exactly as @OSDeploy says.

We are an international company but our IT is only based in 1 country. We have USBs dotted around all over the world and it's easier for our guys to download the OSDCloud ISO onto an end users endpoint via SFTP and then use Rufus to create the USB for remote deployments rather than us install the module and create the USB that way.

In reality, we could do this as I know with New-OSDCloudUSB you can specify the ISO to use without having to regenerate the entire package on another endpoint but the Rufus way is easie. It would be something we could consider if we came up with other issues of using Rufus but simply changing the file system drop-down in Rufus when creating the USB from FAT32 to NTFS fixes this problem so we'll work through our USBs and make that change.

Thanks for all your work on this project.

[OSDeploy]

Thanks for the information @Triipie19 ... I'll work on excluding FAT32 USB in a future release to resolve this issue

[RunCMD-123]

Thanks for the information @Triipie19 ... I'll work on excluding FAT32 USB in a future release to resolve this issue

Thanks for all your help