Forum Discussion
Outlook login issues with WVD - FSLogix
DAsnow this scenario isn't ringing a bell in terms of a common scenario, probably best to contact support on this.
knowlite Here's the information summarized on the Office login issue:
https://techcommunity.microsoft.com/t5/windows-virtual-desktop/outlook-displays-quot-need-password-quot-authentication-dialog/m-p/1289230#M3419
- We've done two things to prevent running into this in the future:
The feature team owning this code has added a check and will disable the workplace join by default on Windows 10 Enterprise multi-session (given it's a bad idea to use when using a roaming profile solution) - Modify the image in the Azure Gallery to have the registry workaround applied. This is quicker than #1 and should be visible in the images starting the second week of May.
The AppX is an issue we tracked down recently and we are working on servicing via Windows Update.
Thanks,
Pieter
A long time WVD/AVD administrator here and we're now picking up on some oddities:
First of all mentioning what has and does work perfectly:
AVD VM's are not WorkPlaceJoined like the initial problem in this thread
SSO works for the user logging on
MFA works as expected
FSLogix roaming handles logging on to multiple machines
The problems start when due to business needs a 2nd O365 account gets added to outlook or teams. Especially if that second O365 account is not within the same tenant of the user logging on (the user logging on handles the Windows/Office licensing as required). Another way to make sure it breaks is by adding only a foreign O365 account to Outlook and then logging on to another VM.
The only "fix" we've found so far is to disable WAM and re-enable ADAL. That fixes the issues but isn't recommended or desired in the long run.
Is anyone able to confirm they have a setup like this working with email/Teams accounts other than the logged in user? Or does adding other accounts to Outlook with MFA simply break SSO on AVD/FSlogix setups? The problem persists over multiple different AVD setups
KevinDeSchrijver Thanks for all the information, I am guessing my issue is that I have some users that have registered RDS-Host1 and other users that have registered RDS-Host2 so when I upgraded fslogix to the latest version and it roamed the token the token is only valid for one of the 2 servers and the users can only log onto office on the host that was registered.
Currently just a plain domain with with AD Connect Sync + SSO that has been working fine until the latest Fslogix
Does anyone know if I can enable Hybrid AD and sync the 2 hosts without creating new issues?
AFAIK it will hybrid register the 2 RDS Hosts for all users and remove the individual RDS host per user registrations which will allow the token to work on both hosts at that point I assume?
Worried about creating new issues by enabling hybrid
Server environment is simple and consists of
PDC
RDS1
RDS2
ConnectionBroker
- Just came to this thread looking for an answer for a similar issue with OneDrive on our Horizon non-persistant VDI. The Sync app does not SSO even even the GPO set.
Coming to your your workaround, the redirections is not required now right? as of FSLogix new version those entries are no longer roamed (https://learn.microsoft.com/en-us/fslogix/troubleshooting-known-issues#microsoft-entra-id-authentication-for-applications)
I've set RoamIdentity to 1. But no luck. As far as I know the issue is still present. The fix I noted is still valid though. We still use it in all our RDS Farms under the conditions I mentioned:
- For accounts where SSO does not work or apply (i.e. for all secondary mail accounts)
- You are required to enter your credentials once on every RDS Host. After that logon on each VM you should be fine.
It's unclear from your problem description if you are experiencing this issue for accounts that are expected not to have SSO or not. Because many admins simply have issues getting SSO working which is a requirement for your primary account.
The problem itself will remain for quite some time I guess. Microsoft only officially supports SSO accounts for usage in AVD. This is just a bandaid solution to work around that designflaw.
This issue seems to be still ongoing?
We have two RDS 2022 servers.
FSLogix (Version 2.9.8784.63912)
When setting up O365 (Outlook specifically) it works on RDS1 but when the user gets redirected to RDS2 we get the error: Cannot Start Microsoft Outlook. Cannot open the Outlook window.
We tried the reg key "RoamIdentity" set to 1 which does nothing.
Tried the reg key: "KeepLocalDir" set to 1 and created the "redirections.xml" in the user profile, with this setup Outlook opens on both RDS servers, however asks for authentication every time you log in?
Was there ever a permanent fix from FSLogix?
Also tried both the "roamidentity" AND the "KeepLocalDir" which also does nothing.
Dace93 You mentioned:
Dace93 wrote:
Yes, I was beta tester.
All issues fixed 🙂Do you still have the these reg hacks in place?
- Under HKLM\Software\FSlogix\Profiles, create a KeepLocalDir (DWORD) value and set to 1
- In the redirections.xml file, add these exclusions:
<?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>Or, did you remove all of the above and instead just enable the new "RoamIdentity" config value?
azanoncello Many Many Thanks for guiding us to the correct solution.
Indeed, updating FSLOGIX to 2210 was asking me to sign in to Office Products/One Drive at each opening of AWD Session.
I've added the registry key RoamIdentity to value 1 and it instantly sorted the issue.
I've now updated our FSLOGIX ADMT template to enable the RoamIdentity value to enable by GPO and all my AWD are not authenticating correctly and only once.
That was unbeliviably useful so Thanks again for sharing this tip.
PS:, I've also have another issue on some AWD, where One Drive refuses to start and launch.
this can be sorted by adding a registry key in : [HKEY_CURRENT_USER\SOFTWARE\Microsoft\OneDrive] "ClientEverSignedIn"=dword:00000001.
I don't know yet if this is also a FSLOGIX issue or linked to the new version of One Drive only.
I took this article as reference : https://answers.microsoft.com/en-us/msoffice/forum/all/onedrive-sign-in-failure-on-windows-10-or-11-multi/72775e41-7743-4ef4-a6f3-65150ed5c2cd?rtAction=1695209861528.
Once again a huge thanks for all these articles that helped me sorting the issue for our org. hopefully next release of FSLOGIX will fix it.
Best
- Thanks for the MS article and quick explanation.
- The whole reason you have this issue is because you don't have SSO or can't do SSO in your current setup. (see the note in the MS article I posted above).
If you are using AADDS then you don't have SSO. If you have a regular DC with SSO then this becomes a non-issue because the users are automatically signed in and don't need the token saved to the container (which is preferred but not possible with AADDS at this time). Thanks! Interested in SSO, is there a link you could reply with to get me started? Thanks again.
yes it's because you are missing a setting. Roamidentity
https://learn.microsoft.com/en-us/fslogix/reference-configuration-settings?tabs=profiles#roamidentity
They changed the default to turn this off but if you don't have SSO you need the credentials to save in the container.
I haven't updated my fslogix for quite some time (September 2022). I finally did install the latest fslogix for my hosts. Now I am having this issue with the SSO. Which brought me to this thread. From reading the thread, it looks like it was fixed with the latest fslogix. Hoewever, I am experiencing this and I never was prior to the new install. Any ideas?
Thank you. Absolutely one of the best answers I have ever seen in a forum. I especially applaud the Theory of this fix section. No answer is truly complete without it! Bravo.
Do you have a job with the FSLogix or Outlook team yet!
This should be published in the FSLogix troubleshooting section!
Thank you.
David
- Yes, I was beta tester.
All issues fixed 🙂 Did someone test FSLogix 2210 hotfix 1 yet?
KevinDeSchrijver your hack worked perfectly, thanks!!
KevinDeSchrijver wrote:Following fix in place at the moment:
Create GPO to add the following Registry key or manually create:
HKEY_LOCAL_MACHINE\Software\FSlogix\Profiles
KeepLocalDir DWORD 1
Then add a "redirections.xml" file in the following location of each user:
c:\users\%username%\AppData\Local\FSLogixThe redirection only works when the file is present upon logon so do a logoff/logon afterwards or inject into the dormant profile.
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>
You will have to enter credentials on EACH Session Host ONCE but after that you can move between hosts without any issue.This is indeed the case. No solution for that I'm afraid.
The solution I posted only applies to the specific case and I only created it myself after hitting a dead wall with MS support who started opening their umbrella with statements like: Indeed, having more then one O365 account (Hello, mailaccounts?) is not supported with FSLogix on multiple hosts.
I based my solution on this:
https://learn.microsoft.com/en-us/azure/active-directory/devices/howto-device-identity-virtual-desktop-infrastructureKevinDeSchrijver Wont you have an issue when you re-image the host-pool? Everyone will have to sign in to the new hosts again or am I missing something here.
- Hi Kevin,
SSO works even when Outlook is broken, customer got Mutiple hosts and some users mutiple O365 accounts from different tenants. But we also see outlook broken issues with the users that
dont have the second tenant account added.
Outlook breaks after user change password (They needed to change password every 42 days).
Looks like they need to set new password / token on both RD-Host servers.
We see logs in Azure AD like
"The provided grant has expired due to it being revoked, a fresh auth token is needed. The user might have changed or reset their password. The grant was issued on '{authTime}' and the TokensValidFrom date (before which tokens are not valid) for this user is '{validDate}'."
Expected part of the token lifecycle - either an admin or a user revoked the tokens for this user, causing subsequent token refreshes to fail and require re-authentication. Have the user sign-in again.
Error code: 50173
Next test case will be to extend the password change to 365 and see if it still happen. Token refresh is 90 days i understand. There are more than 1 reason why Modern Authentication can break. My situation and the fix is very specific:
The use-case is multiple Hosts AND multiple O365 accounts (or an O365 account that isn't covered by SSO)
In VDI and almost any setup you should have SSO configured which handles the primary O365 account. If it "breaks" by moving to another VM, SSO kicks in and repairs it without the user ever noticing.
My fix is only intended if both conditions are met: Multiple hosts and multiple O365 accounts.
If you are having issues with Modern Auth and those conditions are not met I suggest looking at SSO which may not be configured or may not function as desired. Seems like the case with the changing password issue. Your local AD may not be in sync with AAD.- Sounds logical but still leave me with questions.
- Only one customer got issues while we have multiple setups like this
- Only happens after password change (in our case)
- I dont see this issue on VDI while they change desktops every day
Only difference is that some users got multiple accounts in outlook from different tenants, but also see this happen with users that got a single account after changing password. - Will give it a try.
The theory sounds logical to me.
Hope Microsoft will find an official fix soon...
Thanks for your work! Following fix in place at the moment:
Create GPO to add the following Registry key or manually create:
HKEY_LOCAL_MACHINE\Software\FSlogix\Profiles
KeepLocalDir DWORD 1
Then add a "redirections.xml" file in the following location of each user:
c:\users\%username%\AppData\Local\FSLogixThe redirection only works when the file is present upon logon so do a logoff/logon afterwards or inject into the dormant profile.
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>
You will have to enter credentials on EACH Session Host ONCE but after that you can move between hosts without any issue.
The theory of this fix:
Modern Authentication works with Tokens. Those tokens contain the Device ID. Storing them in FSLogix breaks them because the Device ID contained in them no longer matches. The fix pushes those tokens out of the FSLogix container to a local_username folder and no longer deletes that folder upon logoff from the machine. Once you have a working token on each host it will refresh if needed but it no longer breaks. Hope this helps because MS was clueless after spending a few weeks with the FSLogix/Office teams.Same issue only with RDS. Latest FSLogix installed but when they change password they loose connection with Office365 and password needed is showing. Prompt wont pop-up and seems to happen with the users that got multiple accounts added from different tenants.
We use DUO as MFA. They will force modern authentication soon so disable this wont help.
Solution what seems to work is logging them off in outlook and sign back in and approve with MFA again.
