OSOT Issues - Windows 11 23H2

[StephenWagner7]

Hey folks, hoping that someone from Omnissa, or other folks can chime in to this.

Using Windows 11 23H2, Horizon 8 2406, FSLogix, OSOT, and the proper deployment of the base image without vTPM (using Broadcom KB for Win ADK and WinPE), I'm seeing an issue with a particular client. Azure SSO is not configured (nor possibly for this specific environment) with no Seamless SSO, and no PRT.

ISSUE: When Outlook is open, components of the System Tray become unresponsive (can't right click on system tray icons), and the File Explorer Toolbar (address bar, back buttons, up, etc) also become unresponsive. We are able to continue to navigate in the Folder/File view, but nothing in the Toolbar works. Also some anomalies are being reported with the snip tool.

I've done numerous Windows 11 deployments for customers (probably over 40 at this point), but I've only seen this once in my lab when 23H2 came out, and in this particular circumstance.

On one user, we could temporarily resolve it by deselecting the "Show files from Office.com", but then we had other issues. In my own lab (if my memory serves me right) the issue was resolved once the pool was deployed to Instant Clones where hybrid domain joining was enabled.

This leads me to believe that the new updates/features in Windows 11 23H2 File Explorer are causing the issue, with me speculating that it's related to the built in integration in Windows Explorer and it's connectivity to Microsoft 365 online services. On a pre OSOT image, you can notice the "Sign in" button on the file explorer to connect the users profile to M365 services, which is removed after running OSOT.

This specific base image has been optimized using the most recent, and last OSOT versions (OSOT 2046 was released during image deployment and troubleshooting).

As a temporary fixed, we've deployed registry modifications to existing users to use the Windows 10 File Explorer via registry tweaks, which is working as a workaround (although I absolutely hate it).

Has anyone seen this, is there any known issues regarding this? Because of all the successful deployments I've done, I'm speculating this is related to the latest Windows 11 updates in the recent months where features of the new 24H2 are being brought in to 23H2.

Edited November 11 by StephenWagner7

[Collin Joyce]

Out of curiosity, are you keeping the default apps in the image or removing them? I've noticed Microsoft has been sneaking in more Microsoft Apps in their default image the same way they converted Teams to an app that the old OSOT deleted. I'm wondering if their newest update is using one of those apps as a backbone for functionality.

[StephenWagner7]

3 minutes ago, Collin Joyce said:

Out of curiosity, are you keeping the default apps in the image or removing them? I've noticed Microsoft has been sneaking in more Microsoft Apps in their default image the same way they converted Teams to an app that the old OSOT deleted. I'm wondering if their newest update is using one of those apps as a backbone for functionality.

Actually funny you mentioned that....

I noticed that in a test image, if we didn't remove any Windows Apps. Windows just "performed better", although we didn't want these included. Didn't have a chance to test if this issue occurred.

However, as with most deployments, we used the OSOT tool to remove most apps, while only keeping the ones required (Photos, Snip tool, Videos, etc...).

We are also getting reports that sometimes the Snip Tool isn't working, but the IT team hasn't been able to describe the behavior to me, or visibly show me what's happening. It only happens very rarely, but I guess when the selection tool is used, it freezes. You can escape, but the tool stops working.

Edited November 11 by StephenWagner7

[Collin Joyce]

4 minutes ago, StephenWagner7 said:

Actually funny you mentioned that....

I noticed that in a test image, if we didn't remove any Windows Apps. Windows just "performed better", although we didn't want these included. Didn't have a chance to test if this issue occurred.

However, as with most deployments, we used the OSOT tool to remove most apps, while only keeping the ones required (Photos, Snip tool, Videos, etc...).

We are also getting reports that sometimes the Snip Tool isn't working, but the IT team hasn't been able to describe the behavior to me, or visibly show me what's happening. It only happens very rarely, but I guess when the selection tool is used, it freezes. You can escape, but the tool stops working.

I've found this to be the case with removing any of the apps lately. What I've been doing is utilizing a "decrapifier" script that I roll out in the OOB default profile before I do anything else. Then when it comes to getting rid of the apps, I've already deprovisioned everything I don't want in the image, and I leave the rest of them when using the OSOT. Might be worth checking the image to figure out what is installed in the apps, you can do this using powershell running

Get-AppxPackage -AllUsers

This should drop all of the packages that are in the image currently. I'd probably try running this before and after running the OSOT and see what it removes entirely, because the options not being dynamic means we only have a select few of apps that we can "keep" but I think Microsoft is baking more in that are required for functionality.

[StephenWagner7]

3 minutes ago, Collin Joyce said:

I've found this to be the case with removing any of the apps lately. What I've been doing is utilizing a "decrapifier" script that I roll out in the OOB default profile before I do anything else. Then when it comes to getting rid of the apps, I've already deprovisioned everything I don't want in the image, and I leave the rest of them when using the OSOT. Might be worth checking the image to figure out what is installed in the apps, you can do this using powershell running

Get-AppxPackage -AllUsers

This should drop all of the packages that are in the image currently. I'd probably try running this before and after running the OSOT and see what it removes entirely, because the options not being dynamic means we only have a select few of apps that we can "keep" but I think Microsoft is baking more in that are required for functionality.

Good point!

Yeah, because I'm not seeing this in my lab (with 23H2 and 24H2), which I have Hybrid Domain Joining enabled (allowing any M365 integrations to function), I'm thinking you're right that there may be some Windows Apps required for environments where SSO isn't possible.

I'm wondering if this is related to the AADBroker Windows app.

[Collin Joyce]

1 minute ago, StephenWagner7 said:

Good point!

Yeah, because I'm not seeing this in my lab (with 23H2 and 24H2), which I have Hybrid Domain Joining enabled (allowing any M365 integrations to function), I'm thinking you're right that there may be some Windows Apps required for environments where SSO isn't possible.

I'm wondering if this is related to the AADBroker Windows app.

Yea I think if Microsoft continues to roll out things as an "App" then the OSOT should probably be adjusted to populate the default app removal to be dynamic and grab some whatever is installed. I haven't deployed out the Windows 11 image to my user base yet, but after hearing a bunch of the nightmare people are running into with 24H2, I'll probably hold off deployment until a few more people find the issue out. 

My guess would 100% be they're implementing changes that "ties" the OS together a bit more and makes it feel more "fluid" for end users, but also makes disabling un-needed functionality a bit harder of a balancing act which will make administrating the image especially in a virtual environment where we are trying to limit the amount of impact each machine has on the hosts increasingly difficult. Phew, excuse the run-on sentence.🥴

[StephenWagner7]

Well this is interesting. Despite removing most Windows Apps (using OSOT). I just logged in, opened Store, updated all apps.

Opened Outlook, and surprise the file explorer still works. Maybe with the latest updates for 23H2, we need to keep these in place?

EDIT: On log off and back on, the issue occurs again.

Edited November 11 by StephenWagner7

[StephenWagner7]

Logging in, opening Powershell as an administrator, and then launching outlook as user and testing, issue is not present.

In my test above, I had opened powershell as an admin to pull all AppX packages, which is actually what stopped the issue from happening.

Edited November 11 by StephenWagner7

[Collin Joyce]

Sounds to me that we definitely need to keep an eye on that and maybe Omnissa might want to look at making the OSOT be a bit more dynamic on the default apps since Microsoft is being a bit more aggressive with their built-in apps.

I didn't mention in my OOBE step I generally also update the Microsoft store; it seems that is holds a bunch of dependencies for things as well and the standard ISOs don't seem to be on the current version of the store. I mostly do it because of the "App Installer" app since Winget is a nice tool to be able to leverage, but it also just seems that a lot of the updates they've implemented require the apps to be updated to function without constant crashing or weird behavior.

[Collin Joyce]

28 minutes ago, StephenWagner7 said:

Well this is interesting. Despite removing most Windows Apps (using OSOT). I just logged in, opened Store, updated all apps.

Opened Outlook, and surprise the file explorer still works. Maybe with the latest updates for 23H2, we need to keep these in place?

EDIT: On log off and back on, the issue occurs again.

When you log off does the profile show the apps are still a part of the profile? I'm guessing they're not being stored with the FSLogix profile and are being deleted after the disconnect because they're not roaming with the profile.

[StephenWagner7]

So just an update

Test 1 (Control) - Log on, Open Outlook, open File Explorer. Navigate to C drive. Issue present, can open folders, but can't use toolbar. System tray is also dead. Can open start, but can't right click or run programs elevated.

Test 2 (Powershell as Admin) - Log on, open powershell as admin (leave in background). Open Outlook as user, open File Explorer. Issue is not present

Test 3 (Powershell as User) - Log on, open powershell as user (leave in background). Open Outlook as user, open File Explorer, Issue IS present.

Test 4 (Powershell as admin) - Log on, open powershell as admin, close powershell. Open Outlook as user, open File Explorer, Issue IS NOT present.

Test 5 (Control) - Log on, Open Outlook, open File Explorer. Navigate to C drive. Issue IS present.

 

I wonder why opening powershell as admin (even if you close it immediately afterwards) stops the issue from happening. I'm wondering if running something elevated is kicking off the initialization of an admin profile, resulting in processes getting started.

[Collin Joyce]

5 minutes ago, StephenWagner7 said:

So just an update

Test 1 (Control) - Log on, Open Outlook, open File Explorer. Navigate to C drive. Issue present, can open folders, but can't use toolbar. System tray is also dead. Can open start, but can't right click or run programs elevated.

Test 2 (Powershell as Admin) - Log on, open powershell as admin (leave in background). Open Outlook as user, open File Explorer. Issue is not present

Test 3 (Powershell as User) - Log on, open powershell as user (leave in background). Open Outlook as user, open File Explorer, Issue IS present.

Test 4 (Powershell as admin) - Log on, open powershell as admin, close powershell. Open Outlook as user, open File Explorer, Issue IS NOT present.

Test 5 (Control) - Log on, Open Outlook, open File Explorer. Navigate to C drive. Issue IS present.

 

I wonder why opening powershell as admin (even if you close it immediately afterwards) stops the issue from happening. I'm wondering if running something elevated is kicking off the initialization of an admin profile, resulting in processes getting started.

Yep! The admin profile has the apps loaded so when you open the admin profile it is loading the dependencies that aren't loading in the user profile. I'm guessing the admin profile is local to the image and the user profile is FSLogix containerized right?

Since the container isn't carrying the Appx updates it is dumping them each time it reloads it isn't there, but the admin profile being loaded then updates the Apps on the profile that is currently loaded, I believe Microsoft calls this the staged vs installed app package.

Does this environment have the Microsoft Store available to the users? If so try without opening the admin powershell to open the Microsoft Store and update the apps.

Also might be worth running Get-ProvisionedAppxPackage

 

Edited November 11 by Collin Joyce

[StephenWagner7]

3 minutes ago, Collin Joyce said:

Yep! The admin profile has the apps loaded so when you open the admin profile it is loading the dependencies that aren't loading in the user profile. I'm guessing the admin profile is local to the image and the user profile is FSLogix containerized right?

Since the container isn't carrying the Appx updates it is dumping them each time it reloads it isn't there, but the admin profile being loaded then updates the Apps on the profile that is currently loaded, I believe Microsoft calls this the staged vs installed app package.

Does this environment have the Microsoft Store available to the users? If so try without opening the admin powershell to open the Microsoft Store and update the apps.

Updating the apps via the normal user account has no effect. Apps can update, but issue is still present. Originally I thought this fixed it, but I had opened the powershell as admin, which is what led me to think it was the app store, when it was the powershell that actually stopped it from happening.

[Collin Joyce]

1 minute ago, StephenWagner7 said:

Updating the apps via the normal user account has no effect. Apps can update, but issue is still present. Originally I thought this fixed it, but I had opened the powershell as admin, which is what led me to think it was the app store, when it was the powershell that actually stopped it from happening.

Seems to me there is something fishy with the provisioned apps not hitting until the admin profile is being loaded. I know the newest hotfix for FSLogix is supposed to create a folder for the MSIX packages in the ODFC container FSLogix Release Notes - FSLogix | Microsoft Learn I'm wondering if there's something funky going on there.

[StephenWagner7]

Additionally, running taskmgr as admin, does not fix it. Only when running powershell.

[Collin Joyce]

Windows 11 Powershell runs through the "Terminal" app so it would require loading the admin profiles apps vs the taskmgr is still just running as a normal exe program.

Edited November 11 by Collin Joyce

[StephenWagner7]

And just a reminder to anyone reading this. Setting Windows 11 to use the Windows 10 File Explorer is workaround we're currently using. I've attached the (dot) reg file as a txt.

EDIT/ADDITION: Please keep in mind this is unsupported and I cannot recommend it. I also hate doing this to fix it, but it's the only thing working.

Win10-Explorer.txt

Edited November 11 by StephenWagner7

[StephenWagner7]

I have another client that's been having issues with OneDrive (different circumstances as Outlook doesn't play in to theirs), where when OneDrive is configured the File Explorer is unusable (completely freezes 100% can't navigate files). Different than the example I referenced above in the OP. This was occurring on their base images before they brought me onboard, and also occurred on the image I created for them.

They just swapped over to the Windows 10 Explorer using the reg key provided, and now they can use OneDrive and File Explorer works as well. They've been battling with this for months.

Looks like something is definitely going on.

Edited November 11 by StephenWagner7

[Collin Joyce]

Makes me want to look further into how they're deploying the Windows 11 Explorer, wonder if it actually a "Windows App" instead of how it was previously deployed.

[StephenWagner7]

3 hours ago, StephenWagner7 said:

I have another client that's been having issues with OneDrive (different circumstances as Outlook doesn't play in to theirs), where when OneDrive is configured the File Explorer is unusable (completely freezes 100% can't navigate files). Different than the example I referenced above in the OP. This was occurring on their base images before they brought me onboard, and also occurred on the image I created for them.

They just swapped over to the Windows 10 Explorer using the reg key provided, and now they can use OneDrive and File Explorer works as well. They've been battling with this for months.

Looks like something is definitely going on.

One more update! 🙂 

My 2nd customer example disabled Office containers and switched to only profile containers, deleted profile, and now both customers (2 separate environments) are identical with the File Explorer toolbar freezing.

[StephenWagner7]

11 hours ago, Collin Joyce said:

Makes me want to look further into how they're deploying the Windows 11 Explorer, wonder if it actually a "Windows App" instead of how it was previously deployed.

I'm wondering if approaching or we're at the point in the development of the OS, where Azure SSO is actually a requirement now... With Azure SSO configured, this issue doesn't occur.

While I always recommend organizations configure Azure SSO, there's always those that don't have it configured, or those that don't want it configured. Sounds like we might be at the point where it's not longer a feature, but now a requirement for the OS to function properly.

[Collin Joyce]

That sounds like an interesting thought, I don't know why anyone wouldn't want to utilize Azure SSO (aka Entra ID SSO for anyone confused with Microsoft's million different renames) since it makes the experience way better from the end user standpoint. Personally, I think it should be a requirement anyways because of the functionality benefits alone.

[StephenWagner7]

Yet another update! 🙂

In my own lab, I updated my 23H2 to the latest Windows Updates w/ FSLogix. I have two test pools deployed:

Seamless SSO Pool - After updating Office, OneDrive, and Windows to the latest updates. After optimization and finalization, snap push. I log on, open Outlook, and I can't MFA my M365 account, it's frozen on the select "Work/School or Personal Account" to activate/sign in to office. Also, with File Explorer, same issue as above. I can navigate folders, but cannot use the toolbar. After signin/configuration of OneDrive issue temporarily resolves, until you close Outlook then re-open Outlook, and File Explorer becomes unresponsive.

Hybrid Joined w/ PRT Pool - After updating Office, OneDrive, and Windows to latest updates. After optimization, finalization, snap push. I log on and everything works fine.

It appears these issues occur with no Azure SSO, and Seamless SSO. If using Hybrid Domain join w/ PRT, there's no issues.

[StephenWagner7]

3 minutes ago, Collin Joyce said:

That sounds like an interesting thought, I don't know why anyone wouldn't want to utilize Azure SSO (aka Entra ID SSO for anyone confused with Microsoft's million different renames) since it makes the experience way better from the end user standpoint. Personally, I think it should be a requirement anyways because of the functionality benefits alone.

A lot of organizations are struggling to enable Azure SSO with PRTs on their non-persistent pools (there's a million reasons). A lot of orgs still rely on Seamless SSO for their non-persistent environments. But it looks like this issue is also happening with Seamless SSO, so it sounds like PRT is required to avoid it.

[StephenWagner7]

Update - November 13 - Further testing

Windows 11 24H2 - Issue not present

Deployed a Windows 11 24H2 VM. While the OSOT doesn't fully work, I created using the proper method (WinADK, WinPE, without vTPM), followed my standard provisioning process, etc. While the OSOT tool doesn't fully work, I was able to Optimize (excluding removal of Windows Apps), Generalize (which fails, but if you restart the VM it's generalized), and then finalized. I could not reproduce the issue in Windows 11 24H2 despite multiple log off and ons, configuring OneDrive, restarting Outlook, etc.

This made me start thinking, is it the removal of Windows Apps that OSOT performs? Maybe there's a new Windows App that's involved. So I spun up another Windows 11 23H2 VM.

Windows 11 23H2 - Issue Present (without Windows App Removal)

Followed the same procedure as always (WinADK, WinPE, no VTPM). Installed Office via ODT, OneDrive machine wide (same as example above), FSLogix. Optimized (excluding Windows App removal), Generalized, and Finalized. Pushed the snapshot. Upon login, as soon as attempting to log on to configure Outlook and activate, BAM the Windows Auth freezes. Check File Explorer and the File Explorer toolbar is frozen.

 

So it looks like it's not related to the removal of Windows Apps. But it appears from my testing that 24H2 isn't effected by the issue, only the latest fresh installs and fully updated installs of 23H2 with either no Azure SSO, with Seamless SSO, and with FSLogix.

Additional side note, I need to take a holiday from creating base images, as I've done over 12 in the last 7 days haha.

I don't think this is related to OSOT, and more of issues with Win11 23H2 and FSLogix.

Edited November 13 by StephenWagner7