Skip to content

Conversation

@MichaelEscamilla
Copy link
Collaborator

@MichaelEscamilla MichaelEscamilla commented Oct 2, 2025

Added Windows 11 25H2 to the Older Cloud Operating System Catalogs

To be used with OSDCloudv1

Just the catalogs - made an attempt to add full support here: #318

@MichaelEscamilla
Copy link
Collaborator Author

Testing
image

image image

@OSDeploy OSDeploy merged commit a465175 into OSDeploy:master Oct 2, 2025
@MichaelEscamilla MichaelEscamilla deleted the scarlet-tarantula branch October 2, 2025 15:31
@KatsuhiroWatanabe
Copy link
Contributor

Hi @OSDeploy and @MichaelEscamilla ,

I have a question regarding the 25H2 catalog updates.

Observation:
For 25H2 OS catalog entries the SHA1 field is null, while previous releases included SHA1 values.
In OSD, setting $Global:OSDCloud.CheckSHA1 = $true triggers a strict SHA1 comparison and, when the catalog SHA1 is null, the workflow effectively hangs (24h sleep) on “SHA1 Mismatch”.

Question:

  • Is SHA1 intentionally deprecated for 25H2 and future releases?
  • If not deprecated, will SHA1 be populated in a follow-up?

Thank you in advance for any clarification you can provide.

@OSDeploy
Copy link
Owner

OSDeploy commented Jan 16, 2026

Microsoft has changed their catalogs from 25H2 going forward to use SHA256

image

OSDCloud in the OSDCloud PowerShell Module does validate the hash automatically (no setting needed) depending on the Algorithm specified in the OS Catalog.

This has not been addressed in the OSD PowerShell Module at this time. The end goal for OSDCloud is to use the OSDCloud PSModule, not the OSD PSModule. So if it is breaking things in OSD, then it should be fixed, but new features should not be added to OSD.

  • OSD has issues with Surface DriverPacks in OSD, which is resolved with OSDCloud in the OSDCloud PSModule.
  • OSD doesn't support OSDCloud ARM64, which is resolved with OSDCloud in the OSDCloud PSModule.

@OSDeploy
Copy link
Owner

Solution in the OSDCloud PSModule in the script step-install-downloadwindowsimage.ps1

image

@KatsuhiroWatanabe
Copy link
Contributor

Hi @OSDeploy @MichaelEscamilla ,

Thank you very much for the clarification.

I now understand that starting with 25H2, Microsoft’s official catalog has transitioned from SHA1 to SHA256, and that the OSDCloud PSModule already handles SHA256‑based validation automatically.

However, in our environment we are still using the classic OSD module (not OSDCloud), and we originally attempted to set the following, in order to detect potential ESD corruption (which can occasionally occur under poor internet connectivity):

$Global:OSDCloud.CheckSHA1 = $true

This was applied through an external PowerShell script invoked at the starting phase of Invoke-OSDCloud
(e.g., OSDCloud\Config\Script\Startup\ExampleCode.ps1).

Please also refer to #335 for more background.

In this scenario, catalog entries without a SHA1 value result in a blocking “SHA1 mismatch” behavior. Because OSD automatically expects a SHA1 value when SHA1 checking is enabled, the absence of SHA1 in the catalog causes the workflow to halt (24‑hour sleep). This makes 25H2 deployments difficult for environments still dependent on the classic OSD module.

I fully understand that new development is focused on the OSDCloud module, and that the classic OSD module is no longer receiving major feature updates. That said, if possible, could you please consider either:

  1. Populating SHA1 temporarily for OSD users in cache/archive-cloudoperatingsystems/CloudOperatingSystems.json, or
  2. Adding explicit SHA256 fields (e.g., "HashAlgorithm": "SHA256", "Hash": "<sha256>") to catalog entries so that OSD can fall back to SHA256 when SHA1 is null, or
  3. Applying a small fallback fix in the OSD module so that catalog entries with SHA1 = null do not break the workflow.

Additionally, if there is a new catalog source or endpoint that includes the SHA256 values, please let me know — I would be happy to help contribute or validate once I understand how to access it.

We do not expect new features for OSD, but avoiding a blocking behavior for existing users would be extremely helpful.

Thank you again for your support and for all the work you put into this project.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants