Windows 11 ISO being recognized as Windows 10

[jespinoza84]

From Server 2016, I'm seeing the following:

The same .ISO and version of OSDBuilder shows properly from my Windows 10 20H2 Workstation.

I tried updating ADK to the support W11 version + WinPE Addons to see if that would make a difference but it's the same behavior.

PSVersionTable for reference:
Name Value

---

PSVersion 5.1.14393.4583
PSEdition Desktop
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
BuildVersion 10.0.14393.4583
CLRVersion 4.0.30319.42000
WSManStackVersion 3.0
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1

[OSDeploy]

Thanks for leaving this, but unfortunately, I do not have any plans to resolve any issues with Server 2016. While still supported by Microsoft, it is very different. I can't read ESD files, etc. Additionally, the rule of thumb is you should not service a newer OS from an older one. You are trying to service a 2021 OS from a 2016 OS. My advice, don't do it, but that's up to you. I'm firm on my opinion. Finally, updating ADK does nothing in the world of OSDBuilder. It uses PowerShell Cmdlets that use Dism, and those are set to the OS Dism, not the ADK Dism.

My advice, run OSDBuilder on a Windows 11 system to service a Windows 11 image.

[Simsi1986]

The issue is independent from the OS, where you run OSDeploy, but caused by wrong values in Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion
as Microsoft has not updated ProductName and ReleaseID for Windows 11 (it's shown as Windows 10 Pro/Enterprise... and 2009 on fresh installed Windows 11).

Therefore, some workarounds are required to carefully make use of values, extracted with Get-RegCurrentVersion. Mostlikely, I recommend to focus on CurrentBuild, CurrentBuildNumber to recognize Windows 11.

[OSDeploy]

Can you link the file that is having the issue? Keep in mind I'm really not looking to continue supporting OSDBuilder, so someone else will need to do the work, and the testing.

[Simsi1986]

Can you link the file that is having the issue? Keep in mind I'm really not looking to continue supporting OSDBuilder, so someone else will need to do the work, and the testing.

I'm aware of your lack of time, to continue the support of OSDBuilder, that's why I hope someone else can benefit from my findings to keep OSDBuilder still alive :)

For example https://github.com/OSDeploy/OSDBuilder/blob/master/Public/New-OSBuildMultiLang.ps1 is using/setting variables based on on Get-RegCurrentVersion, which avoids the proper processing of Windows 11 22H2 LCU.

I'm currently investigating how adapt the solution, which is already used in https://github.com/OSDeploy/OSDBuilder/blob/master/Public/New-OSBuild.ps1 but as usual in a historical grown code, I have to manage a chain of dependencies.

[OSDeploy]

I also need to point out potential liability. My biggest concern is what if someone updates there OS, and I have a mistake in OSDBuilder and that causes some failure on systems that get deployed. I didn't consider that much as I had a team that helped with testing, but not so much anymore. My need for OSDBuilder evaporated when MVLS started receiving monthly updates

[Simsi1986]

Oh, I got you - I wasn't aware of the liability. You never can consider everything, especially if things change later on. Hopefully there is still some possiblity to reduce your concerns. My understanding is, that if I use OSDBuilder it's on my own risk, but what should I know... I keep my fingers crossed, that OSDBuilder won't be gone - even if I agree that the requirement or use cases have shifted with montly MVLS release.