Forum Discussion
Outlook login issues with WVD - FSLogix
Having an issue where user of WVD Windows 10 Multi-session have issues moving between hosts. Essentially first login on a host is fine, when the user moves to a new host outlook eventually says "need password" however the modern authentication prompts are never presented to the user.
Anyone have any insight? Perhaps Something with AzureFiles / FSlogix?
Thanks in advance.
DAsnow this scenario isn't ringing a bell in terms of a common scenario, probably best to contact support on this.
- cvanaxelBrass ContributorDoes anyone know when this error occurs?
We rebuilded or environment and the problem did not occur anymore.- fadelbergerCopper Contributor
What exactly did you rebuild? Just the masterimage or the whole infrastructure?
Did you store the FSLogix disks on Azure File Share on standard HDDs or Premium SSDs?- cvanaxelBrass ContributorI rebuild the master image and we use azure premium storage
- fadelbergerCopper Contributor
Did you install your own image or did you take one from Azure Gallery?
- cvanaxelBrass ContributorOne from Azure. Windows 10 multi 1909 with Office365 pro plus.
- Lewis-HIron ContributorWVD, 2 x Windows 10 Deployed in Application Group w/Office 365 w/FSLogix redirected to Fileserver.
User logs on, profiledisc created, user logs on, gpo's work fine and all behaves 'correctly'.
we configure outlook (autodiscover via O365) and outlook starts.
user logs off and at next logon if they are redirected to another host all hell breaks loose.
outlook says; "password required". If we click the prompt the 'signon' bliks and dissapears.
E.g. Outlook does not work any more.
If we then remove profile (%appdata%\local\microsoft\outlook inkl. roaming) and create new profile and try to configure outlook it gives an error 'are you this user' blablabla...
Tried setting different regsettings but nothing helps also tried updating to newest Windows 1909 but to no avail.
if we however DELETE the entire VHD profile then we can configure outlook for that user again but only that way.- DeanbostedorBrass Contributor
These are the reg keys we used for WVD session hosts :
[HKLM\SOFTWARE\Policies\Microsoft\Windows\WorkplaceJoin​]
"BlockAADWorkplaceJoin"=dword:00000001
[HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\WorkplaceJoin​]
"autoWorkplaceJoin"=dword:00000000"
If you go back to some of my other posts, I describe what is happening in detail. The short version is that Office Pro Plus is doing workplace join as designed for non-Hybrid Azure AD joined devices on Host A. The Modern Authentication/Azure AD token contains a device ID tied to Host A. When the user logs into Host B, the token is invalid as the device ID no longer matches to the host. So, Outlook freaks out and Modern Auth breaks.
You must get the registry keys in place on the hosts (I used a GPO), then delete the user profile to clear the token/workplace join settings in the user's profile.
Although, I think someone else in this thread figured out a command to remove the workplace join without needing to delete the profile, not sure.
I believe that the new multi-session Windows 10 images have the registry key by default but your issue indicates that you do not have the keys.
- Sponge405Copper Contributor
This maybe an old thread but... using WVD, Fslogix and Azure files and having the black screen issue, I disabled the app readiness service and started seeing this issue. Re-enabling the app readiness service on a Windows 10 Multi-session PC resolved the issue again. It might help someone. DAsnow
- jamie11288Copper Contributor
Sorry to post in an older thread but I am seeing issues with additional mailboxes in Outlook with AVD.
Adding the mailbox will work initially but the next day when the user logs in the additional mailbox does not update and the 'Needs password' appears but prompt box will not show - removing the mailbox and trying to re-add then gives error that mailbox cannot be added and to retry. Recreating the whole FSLogix profile fixes but only creating new Outlook profile does not - anyone have any idea what is causing this and a fix?
- azanoncelloCopper ContributorThis appears to be a new problem as I have been running AVD multi-session environments for a year now with all the "fixes" and settings set from the start. No issue for 12 months but after the December Windows patches were installed they seem to break the sign in tokens both on my existing environments and my new environments.
- KBankoCopper ContributorSomone got any news on this problem?
- KevinDeSchrijverCopper ContributorDepends on what you call "this problem". The problem this case was started for is defined as losing credential info for O365 services on a multihost AVD with accounts that are not SSO-enabled (secondary accounts). The AVD's need to be persistent.
The solution is mentioned in the thread: using redirections.xml to redirect certain folders out of the FSLogix profile and retaining the local_%username% folder on logoff. That solution still works on 2201 FSLogix and prior and is the advised solution by MS for the situation described. They are still debating internally on how to proceed with further versions of FSLogix as 2210 breaks this solution. - azanoncelloCopper Contributor2 options.
If you have SSO then no issue you can use 2210 (in which case you probably wouldn't be in this thread then).
If you don't have SSO then stay on 2201 and use the redirection methods described above. Do not update FSLogix past 2201 until MS comes up with something better.
- TraceyCatanzaroCopper Contributor
I am not sure if anyone is still referring to this thread but two years and a hotfix later, FSLogix still has not resolved this issue. I have a case open with Microsoft but they can't seem to get a tech assigned. Has anyone come up with a resolution using the latest version of FSLogix? Will the redirected folder xml solution still work?
- ElliottCCopper Contributor
DAsnow This is something similar to our experience, except OneDrive, Outlook and Teams do not authenticate after users sign into the session host. If we get all users to sign out, restart the session host and then sign back in this normally resolves the issue.
This occurs across all environments and it is very frustrating.