Forum Discussion
FSLogix with O365 Container on RDS 2019 Server, some users Intermittently get "The information store
We have a RDP Server farm with 3 servers currently in the farm. I inherited this FSLogix setup from someone else, and I also inherited this issue. We have about 20 users on each RDS Server.
Generally in the morning when some (about 2) users sign in for the day, when they open outlook, they get an error message:
"Cannot start Microsoft Outlook. cannot open the outlook window. The set of folders cannot be opened. The information store could not be opened."
Launching outlook again doesn't help, it throws the same issue.
So far the only workaround we have which seems to work reliably, is we open another office application, like word, sign out of the office account, under file -> account, then sign back in.
Then we can use outlook fine.
Tomorrow the same users might not be affected, there might be 2-3 others that is affected, sometimes the same user is affected 2 days in a row.
From what I can tell the container for Office is successfully attaching, and I think the clue that signing out of word and back in fixes it should tell me something about what is causing it, but so far no luck.
Things I have tried so far.
Setting outlook to cached mode.
Hybrid joining the servers
disabling adal (multifactor doesn't work)
Clearing the outlook profile and re-creating it.
Other bits of information.
Users are federated with ADFS, and ADFS uses a Duo Multi factor plugin for MFA.
FSLogix is on version 2.9.8228.50276
any idea where to look next would be appreciated.
Edited to mention FSLogix Version
13 Replies
- We are experiencing this as well and I'm looking at the suggested fixes, for some reason the FSLogix known issues guide says to not do this if the device is intune managed, any ideas?
WihanHerbst Hi @everone I found something suspicious that may be related to this because authentication tokens are not roaming and can be re-new with when a user lunching a 365 based app each time.
In my case my VDAs are automatically registering to Azure AD when a user signs in using 365 Apps, hence I added the following reg keyt on VDAs and currently testing the behavior. Will come back here if there's any progress.HKLM\SOFTWARE\Policies\Microsoft\Windows\WorkplaceJoin, "BlockAADWorkplaceJoin"=dword:00000001
Also refer the article below for MS recommendations.
https://learn.microsoft.com/en-us/azure/active-directory/devices/howto-device-identity-virtual-desktop-infrastructure#non-persistent-vdiAny further updates on this?
The environmental consistencies between those that are having the problem seem to be:
- Windows Server 2019 Remote Desktop Services.
- Multiple session hosts.
- User profile disks/FSLogix.
- Microsoft 365 apps.
Chris House Sorry Guys I totally forgot this one.
Yes I resolved the issue, The root cause was the fslogix not roaming following component with their roaming profile which is crucial for the MS365 authentication especially after the Moderne authentication pushed by MS365 recently.
So after adding the following to the redirections.xml these components can be roam ,That fixed my issue.
Create GPO to add the following Registry key or manually create:
HKEY_LOCAL_MACHINE\Software\FSlogix\Profiles
KeepLocalDir DWORD 1
Contents of redirections.xml file:
<?xml version="1.0" encoding="UTF-8"?><FrxProfileFolderRedirection>
<Excludes>
<Exclude Copy="0">AppData\Local\Packages\Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy</Exclude>
<Exclude Copy="0">AppData\Local\Packages\Microsoft.Windows.CloudExperienceHost_cw5n1h2txyewy</Exclude>
<Exclude Copy="0">AppData\Local\Microsoft\TokenBroker</Exclude>
</Excludes>
</FrxProfileFolderRedirection>
alternatively, You can enable SSO + Azure AD join session hosts or VDIs will resolve the issue completely.
Interestingly enough this is listed on fslogix known issue but My Microsoft engineer still going here and there and couldn't figure this out yet.
refer the link
https://learn.microsoft.com/en-us/fslogix/troubleshooting-known-issues#azure-ad-broker-directories-and-apps
- Is this something that might be mitigated with disabling the IncludeOfficeActivation setting? Or there are other troubleshooting ideas here...
https://learn.microsoft.com/en-us/office/troubleshoot/activation/shared-computer-activation#FSLogix%20issues%20with%20shared%20computer%20activation- we have already played with this. It hasn't helped. In addition, when the outlook connectivity to exchange online breaks, office is still activated. Word excel etc, still works fine, you are still licensed. You just can't connect to exchange online.
We are not sure why going into word, going file account, and the signing out and back in, in word, fixes the connection to exchange online, but I imagine that the authentication token that is used for syncing settings in word, and for connecting to oulook to exchange online is probably shared, and outlook is trying to use an invalid token, it fails, and it is not asking to renew it. In word, when you sign out and in, it renews it, so outlook functions again. This is just an assumption though.
We also played with Hybrid joining the RDS hosts, but it seems to have no impact.We're having the same problems, and have been for the last few months.
It's actually good to see there are others out there with the same problem.
We don't use FSLogix though - our user profile disks are stored on a separate VM, so I don't believe the issue is specific to FSLogix.
I'm coming round to the conclusion that there is a fault/incompatibility between M365 apps and Remote Desktop Services/Multiple RDS Session Hosts/User Profile Disks.
Our setup:
- Windows Server 2019 Standard - Remote Desktop Services.
- Three RDS Session Hosts.
- User Profile Disks.
- 60 users.
- Windows and Office always kept up to date with latest updates.
Things tried so far:- Signing out of Microsoft account via Word or Excel, then signing back in.
- Steps on this site: https://www.matrix7.com.au/microsoft-365/o365-outlook-logon-error-something-went-wrong-1001/
- Completely recreating the users' RDS profile.
Usually one or a combination of the above will sort the problem, although often it won't sort it for good. We've got one user in particular that we've recreated the RDS profile for and it still won't work.
I think WihanHerbst is on to something with the authentication token - I've wondered the exact same thing, given that we have multiple RDS session hosts.
- I can't help with this, but we have the exact same issue. We have also tried reinstalling Office on one of the Terminal Servers still no luck.
If you find a solution defianetly keep us postedCan you share a bit more information about your setup? FSLogix version and if you are also using ADFS and or Duo, or other multifactor?
I am still speaking to Microsoft about it. They keep bouncing the ball between FSLogix support and O365 and are not really getting anywhere but they are at least looking at it.
Since moving all users to cached mode, the general issue is now simply that outlook has "need password", in the bottom right. Clicking it does nothing. We are still using the word sign in / sign out trick.
Is this workaround also working for you?
- any new update to this thread ? I'm also having the same issue randomly with following setup.
Server 2019
Citrix DAAS
VDA 2305
VMware Hypervisor
Fslogix Latest (2.9.8440.42104) with No Office Container Configured.
Office 365 – Semi-annual channel. Latest Update
Outlook Online Mode.
