The way I noticed this was when I got engaged in setting up FSLogix on-prem in a Windows Server 2019 VDI-environment. Naturally we downloaded the latest and greatest FSLogix version and got it installed. GPOs were set and with the latest ADMX-files installed all seemed okay. We set up both profile disk and Office containers for the users. The trouble started the next day. The users had to log on to Office apps every time they logged on for the day. They had to repeat the login process the next time they logged off and on again. Everything else in the profile was saved as it should be, so I knew FSLogix was set correctly, at least for the most part.

Some back and forth with GPO’s, checking logs and a lot of searching on Google led me to this thread: https://techcommunity.microsoft.com/t5/fslogix/fslogix-2-9-8308-44092/m-p/3682055.

Beginning with the latest build of 2201, a lot of roaming tokens and AAD Broker-stuff are no longer roamed as part of the user profile. See reference: https://learn.microsoft.com/en-us/fslogix/reference-configuration-settings?tabs=profiles#roamidentity. The Office Apps are using legacy roaming of credentials via the Web account Manager (WAM). This is no longer a part of the roaming profile, by default. The ultimate solution here was enabling this new setting called Roaming Identity. This setting re-enables this functionality that was enabled as default before. As soon as I enabled this everything worked as it should.

Pro tip: be sure to update to the latest ADMX-files when updating your FSLogix agents! There might be some new or changed settings relevant to the new version.

Microsoft’s FSLogix team are working with their Identity team for a long term solution on this matter.

More info:

https://learn.microsoft.com/en-us/fslogix/troubleshooting-known-issues#azure-ad-authentication-for-applications