New-OSBuildMultiLang for Windows 11 doesn't change Default system UI language about osdbuilder HOT 8 CLOSED

It worked perfectly for Windows 10, then Windows 11 came out with so many changes ... this being one of them

from osdbuilder.

Yep, only MS devs will know why this change was necessary. Of course it's just one of a view things that came with Win11.
Regarding the Default System UI, the only way I see at the moment is to change within a Build and Capture using Sysprep.

EDIT:
Some further findings, which might give some further ideas, but also further room for interpretation.
My basic process is to create a new build and then multiang build via OSDBuilder and then put the German Index of the Install.wim from MultiLang in MDT to create a reference image, which finally contains only one Index. (if someone asks: the imported OS in OSDeploy is en-us and the multilang (OSDBuilder) build is used as upgrade image in SCCM, the reference image (MDT) for OSD in SCCM)

The result of the reference image from MDT is Default system UI language still en-us, but I can change to de-de via DISM with positive result. Seems like, it's only possible to change the system UI language for the first index of a wim. Diffcult to catch, as it should be then technically no reason for MS to change the behaviour of DISM for Set-UILang.

My current conclusion is, that it is either impossible or just with extreme effort to bring back the former behaviour of having all language components with offline servicing. I will reconsider the image creation process and will check the practical impact in our environment.

from osdbuilder.

By the way, with all investigation and "trial and error" I could also recognize, that the behaviour is the same with an updated Windows 10 Build, when I create the MultiLang Build.

Cross-check with DISM is as follows:

• WIM of the fresh OSImage (created by task adding content-pack with language files, not applying any Windows Updates) changes Default system UI language, if I execute Set-AllIntl:de-DE
• WIM of the Build, created with New-OSBuildMultiLang (created by task adding content-pack with NetFx and adding DaRT, applying Windos Updates) doesn't change Default system UI language, if I execute Set-AllIntl:de-DE

(just in case: base is the latest ISO provided by MS)

By the way, I recognized, that this should already happen since Win10 2004::
https://oofhours.com/2020/06/01/new-in-windows-10-2004-better-language-handling/
https://sysmansquad.com/2021/02/16/multilingual-windows-10-20h2-osd-with-configmgr/

My thinking was, that I maybe just haven't been aware about that with all previous offline imaging and it might be the case, that the Build and Capture finally changed the Default System UI. But this is a negative - honestly, I wouldn't bother that much if all new devices would have the same state of Default System UI en-us as I clearly see the benefit for Inplace-Upgrade to Windows 11 getting easier, but not with the mess, that all devices rolled out until May having a different Default System UI.

For the moment, I will close this issue, as it is documented by MS as a "works as intendend".
Hopefully someone can benefit from my findings, as the information in the internet is rather limited.
I guess we will have to change the Inplace-Upgrade to the old way, we did years ago - multiple images depending on the current default system ui.

from osdbuilder.

Thanks for all the info here @Simsi1986
On mobile now but just wanted to say that I tested this a bit the other day and also saw that the default UI language was set to en-US on all indexes when testing with Win11 22H2 MultiLang.

In my testing the default UI language was set correctly in each index if I did not use the NetFx3 MultiLang ContentPack, in my case that meant that I didn't use any ContentPacks at all as that was the only one I had.

So in other words in my case:

• No content pack added in my OSBuild = Correct default UI language in each index in Win11 MultiLang win.

• NetFx3 ContentPack = en-Us set as default UI language in each index.

Only thing left to try to fix in my case is how to add NetFx3 in a way so that the LCU is not applicable when used the finished media as IPU, which is the case if I enable NetFx3 in the OSBuild.
The fix for applying the LCU for Win11 in MultiLang build does not seem to be enough.

The thing with NetFX3 and Win11 is as it seems there is no language files for it as it were for Win10.

from osdbuilder.

Thx for the hint @suazione
Based on that, I had a further check wit both, Windows 10 and Windows 11.

I can reproduce that and both OS have the same result: Default UI Language is set by the MultiLang process as usual in the months before (but just Win10 as I have just in the preperation of the migration to Win11). The only difference to the previous doing, was to remove the content pack from the Build Task.

In parallel I used the MultiLang Build, which has the "wrong" Default System UI, but NetFx3 included again in MDT to finally have some proof. Even due the relevant entries in customsettings.ini, Default System UI is kept like after the offline imaging, BUT now comes the funny part: I can manually change the Default System UI via DISM on the final reference image.
The TS for the reference is mostly the default TS with small custom additions (RemoveApps, Install LPs again, Install VCRests) and a final cleanup before the sysprep with that script: https://github.com/DeploymentBunny/Files/blob/master/Tools/Action-CleanupBeforeSysprep/Action-CleanupBeforeSysprep.wsf

I will now make a test with the new MultiLang Build without NetFx in MDT and how our Task Sequence will result.

I don't think it's because of having less files for Win11 NetFx3, because the issue is happening with Win10 as well. Hopefully, there is some fix with next patch day, but I fear the chance is very limited.

By the way, @suazione are you also doing a Build and Capture after the offline imaging?
If yes, RemoveApps and Cleanup before Sysprep will result in a WIM, that can't be properly deployed - the solution is to remove the apps in the final deployment task sequence.

from osdbuilder.

@Simsi1986 Great, our scenarios does not sound entirely the same but I've consistently had successful results now when running New-OSBuildMultiLang without ContentPacks and IPUs are working without a problem. So should hopefully work for you as well.

Not doing build and capture with that media, using it with IPU Installer (link below) to do IPUs in MultiLang environment.
https://blog.onevinn.com/ipuinstaller-update-with-windows-11-and-mui-support

But I haven't been able to get rid of the CU needing to be reinstalled if I enable NetFx3 in the OSBuild task.

from osdbuilder.

@suazione Ok, understood, but in general we are depending on the same basics.

Therefore it's clear, that the "workaround" of not adding NetFx3 with OSDBuilder is already fine for IPUs which require same Default UI Language.

For new installation I have a very strange finding. Both (win11&win10) WIM have German Default UI - deployment on VMs via SCCM result in changed Default UI for Win11 (English), but not for Win10. Means for bare metal deployment, Win10 is fine to keep, but Win11 still changes the the Default UI. Important to know: I have just one Task Sequence which contains multiple OS images used depending on the choice in UDI Wizard, which gives some cross check that there is no different setting for Win11 done.

from osdbuilder.

Just an update for Offline Imaging after last MS Patchday, which is different from my expectation, but gratefully accepted.
The usual way for creating updated builds incl. MultiLang is working like before May.
Means working with ContentPack NetFx3 results in Win10/Win11 MultiLang WIMs which proper Default System UI.

So for me it's the confirmation, that there is no need to worry about Default System UI by using OSDBuilder for the moment. No worry means, no need to think about changing the well experienced process. For Windows 11 it's just important to manually add the fix in the not yet added pull request: #94

from osdbuilder.