Device identity and desktop virtualization

מאמר
08/27/2024

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
Non-persistent

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 Windows current¹ this change happens when a virtual machine goes through a shutdown/restart/OS reset process and in Windows down-level² this change happens when a user signs out.

It's important to ensure organizations manage stale devices that are created because frequent device registration without having a proper strategy for device lifecycle management.

Important

Failure to manage stale devices can lead to pressure increase on your tenant quota usage consumption and potential risk of service interruption, if you run out of tenant quota. Use the following guidance when deploying non persistent VDI environments to avoid this situation.

For successful execution of some scenarios, it's important to have unique device names in the directory. This can be achieved by proper management of stale devices, or you can guarantee device name uniqueness by using some pattern in device naming.

This article covers 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.

Supported scenarios

Before configuring device identities in Microsoft Entra ID for your VDI environment, familiarize yourself with the supported scenarios. The following table 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
Microsoft Entra hybrid joined	Federated³	Windows current and Windows down-level	Persistent	Yes
		Windows current	Non-persistent	Yes⁵
		Windows down-level	Non-persistent	Yes⁶
	Managed⁴	Windows current and Windows down-level	Persistent	Yes
		Windows current	Non-persistent	Limited⁶
		Windows down-level	Non-persistent	Yes⁷
Microsoft Entra joined	Federated	Windows current	Persistent	Limited⁸
			Non-persistent	No
	Managed	Windows current	Persistent	Limited⁸
			Non-persistent	No
Microsoft Entra registered	Federated/Managed	Windows current/Windows down-level	Persistent/Non-Persistent	Not Applicable

¹ Windows current devices represent Windows 10 or newer, Windows Server 2016 v1803 or higher, and Windows Server 2019 or higher.

² 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.

³ A Federated identity infrastructure environment represents an environment with an identity provider (IdP) such as AD FS or other third-party IdP. In a federated identity infrastructure environment, computers follow the managed device registration flow based on the Microsoft Windows Server Active Directory Service Connection Point (SCP) settings.

⁴ A Managed identity infrastructure environment represents an environment with Microsoft Entra ID as the identity provider deployed with either password hash sync (PHS) or pass-through authentication (PTA) with seamless single sign-on.

⁵ Non-Persistence support for Windows current requires other consideration as documented in the guidance section. This scenario requires Windows 10 1803 or newer, Windows Server 2019, or Windows Server (Semi-annual channel) starting version 1803

⁶ Non-Persistence support for Windows current in a Managed identity infrastructure environment is only available with Citrix on-premises customer managed and Cloud service managed. For any support related queries, contact Citrix support directly.

⁷ Non-Persistence support for Windows down-level requires other consideration as documented in the guidance section.

⁸ Microsoft Entra join support is available with Azure Virtual Desktop, Windows 365 and Amazon WorkSpaces. For any support related queries with Amazon WorkSpaces and Microsoft Entra integration, contact Amazon support directly.

Microsoft's guidance

Administrators should reference the following articles, based on their identity infrastructure, to learn how to configure Microsoft Entra hybrid join.

Non-persistent VDI

When deploying non-persistent VDI, Microsoft recommends organizations implement the following guidance. Failure to do so results in your directory having lots of stale Microsoft Entra hybrid joined devices that were registered from your non-persistent VDI platform. These stale devices result in increased pressure on your tenant quota and risk of service interruption because of running out of tenant quota.

If you're relying on the System Preparation Tool (sysprep.exe) and if you're using a pre-Windows 10 1809 image for installation, make sure that image isn't from a device that is already registered with Microsoft Entra ID as Microsoft Entra hybrid joined.
If you're relying on a Virtual Machine (VM) snapshot to create more VMs, make sure that snapshot isn't from a VM that is already registered with Microsoft Entra ID as Microsoft Entra hybrid join.
Active Directory Federation Services (AD FS) supports instant join for non-persistent VDI and Microsoft Entra hybrid join.
Create and use a prefix for the display name (for example, 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 executed before the user has logged off completely and network connectivity exists.
For Windows current in a Federated environment (for example, AD FS):
- Implement dsregcmd /join as part of VM boot sequence/order and before user signs in.
- 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 Microsoft Entra hybrid joined devices (such as using computer display name prefix), you should be more aggressive on the cleanup of these devices to ensure your directory doesn't 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.

Note

When using non-persistent VDI, if you want to prevent adding a work or school account ensure the following registry key is set: HKLM\SOFTWARE\Policies\Microsoft\Windows\WorkplaceJoin: "BlockAADWorkplaceJoin"=dword:00000001

Ensure you're running Windows 10, version 1803 or higher.

Roaming any data under the path %localappdata% is not supported. If you choose to move content under %localappdata%, make sure that the content of the following folders and registry keys never leaves the device under any condition. For example: Profile migration tools must skip the following folders and keys:

%localappdata%\Packages\Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy

%localappdata%\Packages\Microsoft.Windows.CloudExperienceHost_cw5n1h2txyewy

%localappdata%\Packages\<any app package>\AC\TokenBroker

%localappdata%\Microsoft\TokenBroker

%localappdata%\Microsoft\OneAuth

%localappdata%\Microsoft\IdentityCache

HKEY_CURRENT_USER\SOFTWARE\Microsoft\IdentityCRL

HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\AAD

HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows NT\CurrentVersion\WorkplaceJoin

Roaming of the work account's device certificate is not supported. The certificate, issued by "MS-Organization-Access", is stored in the Personal (MY) certificate store of the current user and on the local machine.

Persistent VDI

When deploying persistent VDI, Microsoft recommends that IT administrators implement the following guidance. Failure to do so results in deployment and authentication issues.

If you're relying on the System Preparation Tool (sysprep.exe) and if you're using a pre-Windows 10 1809 image for installation, make sure that image isn't from a device that is already registered with Microsoft Entra ID as Microsoft Entra hybrid joined.
If you're relying on a Virtual Machine (VM) snapshot to create more VMs, make sure that snapshot isn't from a VM that is already registered with Microsoft Entra ID as Microsoft Entra hybrid join.

We recommend you to implement process for managing stale devices. This process ensures your directory doesn't get consumed with lots of stale devices if you periodically reset your VMs.

Next steps

Configuring Microsoft Entra hybrid join for federated environment

שתף באמצעות