Device identity and desktop virtualization
Administrators commonly deploy virtual desktop infrastructure (VDI) platforms hosting Windows operating systems in their organizations. Administrators deploy VDI to:
- Streamline management.
- Reduce costs through consolidation and centralization of resources.
- Deliver end-users mobility and the freedom to access virtual desktops anytime, from anywhere, on any device.
There are two primary types of virtual desktops:
Persistent versions use a unique desktop image for each user or a pool of users. These unique desktops can be customized and saved for future use.
Non-persistent versions use a collection of desktops that users can access on an as needed basis. These non-persistent desktops are reverted to their original state, in case of Windows current1 this happens when a virtual machine goes through a shutdown/restart/OS reset process and in case of Windows down-level2 this happens when a user signs out.
There has been a rise in non-persistent VDI deployments as remote work continues to be the new norm. As customers deploy non-persistent VDI, it is important to ensure that you manage device churn that could be caused due to frequent device registration without having a proper strategy for device lifecycle management.
Failure to manage device churn, can lead to pressure increase on your tenant quota usage consumption and potential risk of service interruption, if you run out of tenant quota. You should follow the guidance documented below when deploying non persistent VDI environments to avoid this situation.
This article will cover Microsoft's guidance to administrators on support for device identity and VDI. For more information about device identity, see the article What is a device identity.
Before configuring device identities in Azure AD for your VDI environment, familiarize yourself with the supported scenarios. The table below illustrates which provisioning scenarios are supported. Provisioning in this context implies that an administrator can configure device identities at scale without requiring any end-user interaction.
|Device identity type||Identity infrastructure||Windows devices||VDI platform version||Supported|
|Hybrid Azure AD joined||Federated3||Windows current and Windows down-level||Persistent||Yes|
|Managed4||Windows current and Windows down-level||Persistent||Yes|
|Azure AD joined||Federated||Windows current||Persistent||No|
|Azure AD registered||Federated/Managed||Windows current/Windows down-level||Persistent/Non-Persistent||Not Applicable|
1 Windows current devices represent Windows 10, Windows Server 2016, and Windows Server 2019.
2 Windows down-level devices represent Windows 7, Windows 8.1, Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2. For support information on Windows 7, see Support for Windows 7 is ending. For support information on Windows Server 2008 R2, see Prepare for Windows Server 2008 end of support.
3 A Federated identity infrastructure environment represents an environment with an identity provider such as AD FS or other third-party IDP.
4 A Managed identity infrastructure environment represents an environment with Azure AD as the identity provider deployed with either password hash sync (PHS) or pass-through authentication (PTA) with seamless single sign-on.
5 Non-Persistence support for Windows current requires additional consideration as documented below in guidance section. This scenario requires Windows 10 1803, Windows Server 2019 or Windows Server (Semi-annual channel) starting version 1803
6 Non-Persistence support for Windows down-level requires additional consideration as documented below in guidance section.
Administrators should reference the following articles, based on their identity infrastructure, to learn how to configure hybrid Azure AD join.
- Configure hybrid Azure Active Directory join for federated environment
- Configure hybrid Azure Active Directory join for managed environment
When deploying non-persistent VDI, Microsoft recommends that IT administrators implement the guidance below. Failure to do so will result in your directory having lots of stale Hybrid Azure AD joined devices that were registered from your non-persistent VDI platform resulting in increased pressure on your tenant quota and risk of service interruption due to running out of tenant quota.
- If you are relying on the System Preparation Tool (sysprep.exe) and if you are using a pre-Windows 10 1809 image for installation, make sure that image is not from a device that is already registered with Azure AD as hybrid Azure AD joined.
- If you are relying on a Virtual Machine (VM) snapshot to create additional VMs, make sure that snapshot is not from a VM that is already registered with Azure AD as Hybrid Azure AD join.
- Create and use a prefix for the display name (e.g. NPVDI-) of the computer that indicates the desktop as non-persistent VDI-based.
- For Windows down-level:
- Implement autoworkplacejoin /leave command as part of logoff script. This command should be triggered in the context of the user and should be execute before the user has logged off completely and while there is still network connectivity.
- For Windows current in a Federated environment (e.g. AD FS):
- Implement dsregcmd /join as part of VM boot sequence.
- DO NOT execute dsregcmd /leave as part of VM shutdown/restart process.
- Define and implement process for managing stale devices.
- Once you have a strategy to identify your non-persistent Hybrid Azure AD joined devices (e.g. using computer display name prefix), you should be more aggressive on the clean-up of these devices to ensure your directory does not get consumed with lots of stale devices.
- For non-persistent VDI deployments on Windows current and down-level, you should delete devices that have ApproximateLastLogonTimestamp of older than 15 days.