Troubleshooting auth issues in Outlook if you are Azure joining non-persistent Virtual Desktop Infra

[ad_1]

Virtual desktop infrastructure (VDI) is defined as the hosting of desktop environments on a central server. It is a form of desktop virtualization, as the specific desktop images run within virtual machines (VMs) and are delivered to end clients over a network. Those endpoints can be various devices including PC and tablets. There are many applications for this technology but today we will discuss some of the most common issues our customers face when using Microsoft Outlook (this extends to other Microsoft office apps) in a non-persistent Virtual Desktop Infrastructure (a.k.a. VDI) and are using Exchange Online. Some of the issues end users might see include:

Outlook prompting for password repeatedly
Outlook displaying “Need Password”
Outlook/Office displaying a blank password screen
Outlook/Office activation issues

To avoid these issues being caused by non-persistent VDI, we will discuss best practices. There are a lot of unsupported scenarios when it comes to using VDIs with Azure. To check supported scenarios please see the following link – VDI Supported Scenarios. There are some preparations that must be made for your users to have the best Microsoft 365 experience with Outlook. Currently, Microsoft only supports Hybrid Azure AD Join for VDIs. This means that you must follow the prerequisites and planning that is laid out here.

Not planning on hybrid Azure AD joining?

To prevent machines from performing workplace and Azure AD Join use the following registry keys: (Note: You may also have to delete the computer/device object from Azure AD devices if these computers have already been joined.)

Create a new DWORDs in this path HKEY_LOCAL_MACHINESoftwarePoliciesMicrosoftWindowsWorkplaceJoin

DWORD: “BlockAADWorkplaceJoin”, Value=1
DWORD: “autoWorkplaceJoin”, Value=0

Requirements for all scenarios for non-persistent VDI

Ensure that you are NOT roaming your Identity hive located in ComputerHKEY_CURRENT_USERSoftwareMicrosoftOffice16.0CommonIdentity

This entire hive must be excluded from roaming profiles. There are several ways you can exclude this from roaming. Example, Citrix profile management or GPO and sometimes both need to be configured depending on your configuration. The reason for this is due to the ADAL process writes device information into this key and if you only have one host this is acceptable but most environments have multiple VDI hosts and the machine information will not match when that user logs into a different machine with another machines Identity hive information. This will cause a prompt for the user even on application hosts only.

Ensure that you have shared computer activation configured for your VD environment. (See here for more information on shared computer activation)

If shared computer activation is not configured for users, then users may be prompted to login to office to verify licensing.
If you don’t have Single Sign-on configured, you can now roam the license location for profiles or have them on a shared folder on your network as well. The location for licensing token is %localappdata%MicrosoftOffice16.0Licensing. (Note: This does not guarantee that your user will not be prompted for credentials.)

Ensure that Office and Windows are to the most recent updates. Please see here for necessary Windows and Office builds.

If you are using a non-persistent VDI and may already be Azure AD Domain joined the following steps should remove the device from being Azure AD joined:

Verify that machines are not Azure AD and/or Workplace joined

Verify the following registry keys are present to prevent the machine from rejoining Azure AD or Workplace join:

1. Create a new DWORDs in this path HKEY_LOCAL_MACHINESoftwarePoliciesMicrosoftWindowsWorkplaceJoin

DWORD: “BlockAADWorkplaceJoin”, Value=1
DWORD: “autoWorkplaceJoin”, Value=0

2. If you are Azure AD joined, run the following command in an elevated command prompt, DSRegCMD /Leave and then reboot the host. You can check the status of AAD join by running DSRegCMD /status in command prompt.

Azure AD join status showing that the machine is Azure AD joined.

3. If you are Workplace joined (this is harder to remove) you have to perform the below steps. Run DSRegCMD /Status to check status of workplace join in command prompt.