Technologies such as Intune and Endpoint Configuration Manager (used manage enterprise devices) are becoming more robust, and these tools can also now be used for virtual devices such as those used by Microsoft’s Windows Virtual Desktop service in Azure.
As a desktop and app virtualization service in Azure, Windows Virtual Desktop allows administrators to set up a scalable, multi-session Windows 10 deployments using virtualized desktops as well as virtualized Microsoft 365 and other apps in multi-user virtual scenarios.
Deploying and managing WVDs in Azure can also be accomplished with multiple options for management of host pools, app groups, user assignment and resource publishing.
The following requirements are needed to setup and connect WVDs and apps.
· Window 10 Enterprise (including multi-session)
· Windows 7 Enterprise
· Windows Server 2012 R2, 2016, 2019
Azure Active Directory (AAD)
Windows Server AD (in sync with AAD)
Only Hybrid Azure AD joins are supported
Parented to same AAD tenant and connected to the Windows Server AD or Azure AD DS instance
· Users must be sourced from same AD connected to AAD
· UPN to subscript to WVD must exist in the AD domain the VM is joined.
NOTE: WVDs do not support Azure AD guest user accounts
Azure WVDs (Intune prerequisites)
· Windows 10 (1809) or later
· Hybrid AD-joined (no AAD-joined)
· Configured as personal remote desktops in Azure
· Enrolled in Intune using either AD group policy to auto-enroll hybrid-AAD joined devices, ECM co-management or user self-enrollment via Azure AD join.
NOTE: Intune treats WVD personal VMs the same as physical Win10 Enterprise desktops.
Supported RD clients
· Windows Desktop
· macOS and iOS
· Microsoft Store Client
NOTE: RemoteApp, RADC or the Remote Desktop Connection (MSTSC) client are NOT supported
Windows 10 Enterprise multi-session is a new Remote Desktop Session Host that allows multiple concurrent interactive sessions. Multi-session varieties of Windows 10 also:
- Cannot run in on-premises production environments
- Will not activate against on-premises Key Management Services (KMS)
- Only support hybrid Azure AD joined configurations
Microsoft recommends Endpoint Configuration Manager (Current Branch, 1906/newer releases) when managing deployed multi-session WVDs.
One of the requirements for managing your Windows 10 WVD environment with Endpoint Manager is the use of Hybrid Azure AD join. When you configure your devices to Hybrid join Azure AD, these devices will be visible and manageable in both your on-premises AD as well in Azure AD.
- Credentials of a global administrator for the Azure AD tenant and an Enterprise Administrator account for the on-prem forest are required.
- Domain Controller should be at least Windows Server 2008 R2
- Server 2016 or Server 2019 are recommended
- Server Core does NOT support any type of device registration
NOTE: A single forest should sync identities to only one Azure tenant. Single forest syncing of identity data to multiple Azure AD tenants is NOT supported.
- Client devices as old as Windows 8.1 are supported
- Latest release of Windows 10 is recommended
- Older operating systems (pre-Windows 10 and pre-Server 2016) using credential roaming, user profile roaming, or mandatory profiles are NOT supported
- When using Sysprep for pre-Windows 10 1809 reference images that are used for deployments, make sure the image isn’t from a device that is already registered in Hybrid Azure AD.
- Ensure that VM snapshots, used to create new VMs, are not from a virtual machine that is already registered with Hybrid Azure AD.
- Enabling Unified Write Filter and similar technologies prior to Hybrid Azure AD join will result in the device getting unjoined on every reboot, so do not apply them until after the device is joined.
- Windows 10 releases older than 1803, which are already Azure AD registered, must have this registration removed before enabling Hybrid Azure AD; otherwise, a dual state condition will exist.
- Support for FIPS-compliant TPM 2.0
- TPM 1.2 is not supported and considered not existent.
Hybrid Azure AD join requires devices have access to the following Microsoft resources inside your organization’s network:
https://autologon.microsoftazuread-sso.com (seamless SSO)
NOTE: Azure AD Connect provides a wizard to configure hybrid Azure AD join, which significantly simplifies the configuration process.
In depth information for these two topics are out of the scope of this document; however, a few key components are worth mentioning, and exploring more for a full understanding of each.
- A managed environment can be deployed either through Password Hash Sync (PHS) or Pass Through Authentication (PTA) with Seamless Single Sign On. These configurations don’t require a federation server for authentication.
Note: Azure AD does not support smartcards or certificates in managed domains
- Federated Environments should have an identity provider that supports the following requirements, which are already supported by Active Directory Federated Services (AD FS).
- WIAORMULTIAUTHN claim: Needed for hybrid Azure AD join for Windows down-level devices.
- Down-level devices are pre-Windows 10 and pre Windows Server 2016
- WS-Trust protocol: Needed authentication between Windows current hybrid Azure AD joined devices and Azure AD. AD FS environments must enable the following WS-Trust endpoints:
Start Azure AD Connect and click the Configure button
Click Configure Device Options from the list of Additional Tasks
Review the Overview page and click Next
Enter the credentials for an Azure AD global administrator account, and click Next
Select Configure Hybrid Azure AD join and click Next.
Select the Device OS configuration (current Windows 10 or older “down-level” operating systems) which will be supported and click Next.
Service Connection Points (SCP) are used by devices to discover their Azure AD tenant information, and one must be configured for EACH forest.
Click on the Edit button and fill in your Enterprise Administrator credentials and click on Next.
NOTE: As stated in the Wizard, a configuration PowerShell script (ConfigureSCP.ps1) can be provided to, and run manually by, an Enterprise Administrator in the organization in the event that the person using AD Connect does not have the permissions.
Click on Configure to begin the process.
When the Configuration Complete message displays, the Wizard can be exited.
Computer accounts from the local Active Directory must synchronize with Azure AD before registration can be completed
Using the dsregcmd /status command line on a client is a quick way of verifying registration status. The AzureAdJoined attribute of Device State should be YES
NOTE: It can usually take 15 minutes or more for the registration process to complete.
When a device is enrolled, it is issued an MDM certificate. This certificate is used to communicate with the Intune service.
NOTE: Licenses must be assigned to an administrator’s account before that administrator can enroll devices to Intune. (more information)
Automatic enrollment allows users to enroll their Windows 10 devices in Intune by adding their work account to their personally owned devices, or join corporate-owned devices to Azure Active Directory. The device then registers, joins Azure AD and becomes managed with Intune.
From the Azure Portal, navigate to Azure Active Directory > Mobility (MDM and MDM).
Open the Microsoft Intune item
NOTE: Some tenants might have both Microsoft Intune and Microsoft Intune Enrollment under Mobility. Make sure that your auto-enrollment settings are configured under Microsoft Intune (not Microsoft Intune Enrollment).
Verify MDM discovery URL during auto-enrollment
· https://enrollment.manage.microsoft.com/enrollmentserver/discovery.svc (Home > Mobility (MDM and MAM))
Ensure automatic enrollment is enabled for the users (All or Some (group membership)) who will self-enroll devices into Intune.
Make any other desired changes and then apply the new settings.
Starting in Windows 10, version 1607, once the enterprise has registered its local Active Directory with Azure AD, a domain-joined Windows device will be automatically registered in Azure AD.
Once the group policy is created and enabled on the local Active Directory, a task is created in the background that initiates the enrollment using the existing MDM service configuration from the Azure AD information of the user, and without their interaction.
NOTE: If multi-factor authentication is enabled, the user will be prompted for additional authentication.
Example Group Policy Configuration (Single Device)
Complete the steps below to configure a group policy to enroll a single device into Intune.
Enter gpedit into the Windows Search bar to open the Group Policy Editor (Edit group policy)
Navigate to Administrative Templates > Windows Components > MDM in the Editor.
Open Enable automatic MDM enrollment using default Azure AD credentials (previously called Auto MDM Enrollment with AAD Token in Windows 10, version 1709).
Click Enable and select User Credential from the dropdown Select Credential Type to Use, then click OK.
Note: The MDM.admx file was updated in Windows 10 (1903) to include the Device Credential option, which only affects Windows 10, version 1903 clients.
Older Windows releases revert to User Credential, and Device Credential is not supported for enrollment type when you have an Endpoint Configuration Manager agent on the device.
After a group policy refresh, a scheduled task (Schedule created by enrollment client for automatically enrolling in MDM from AAD) will be created, and run every 5 minutes for the duration of one day.
If two-factor authentication is required, you will be prompted to complete the process.
Example Group Policy Configuration (Group)
Complete the steps below to configure a group policy for enrolling a group of devices into Intune.
Download Administrative Templates (.admx) for Windows 10:
Install the package on the Domain Controller.
Navigate to folder (depends on version):
C:Program Files (x86)Microsoft Group PolicyWindows 10…
Rename the extracted Policy Definitions folder to PolicyDefinitions.
Copy PolicyDefinitions folder to C:WindowsSYSVOLdomainPolicies
Restart the Domain Controller to make the policy available.
1. Create a Group Policy Object (GPO) and enable the Group Policy Computer Configuration > Policies > Administrative Templates > Windows Components > MDM > Enable automatic MDM enrollment using default Azure AD credentials.
2. Create a Security Group for the PCs.
3. Link the GPO and filter using security groups
Create a provisioning package to bulk enroll devices for the Azure AD tenant using the Windows Configuration Designer (WCD) app. When the package is applied to corporate-owned devices they join to the Azure AD tenant and enroll into Intune for management.
Create Provisioning Package
Open the Windows Configuration Designer (can be downloaded from the Microsoft Store), and select Provision desktop devices
Specify the following in the New project window:
· Name – A name for your project
Enter unique names for devices.
· Names can include a serial number (%SERIAL%) or a random set of characters.
Other configuration options include:
· Product key if upgrading the edition of Windows
· Configure the device for shared use
· Remove pre-installed software.
Optionally, you can configure the Wi-Fi network devices connect to when they first start. If the network devices aren’t configured, a wired network connection is required when the device is first started.
Select Enroll in Azure AD, enter a Bulk Token Expiry date, and then select Get Bulk Token.
Provide your Azure AD credentials to get a bulk token.
In the Stay signed in to all your apps page, select No, sign in to this app only.
Click Next when Bulk Token is fetched successfully.
Optionally, you can Add applications and Add certificates. These apps and certificates are provisioned on the device.
Optionally, you can password protect your provisioning package. Click Create.
The steps below will help provision devices using the bulk enrollment provisioning package. Detailed step-by-step instructions for applying these packages are out of the scope of this document, but can be found here (Apply a provisioning package)
Access the provisioning package in the location specified in Project folder specified in the app.
Choose how to apply the provisioning package to the device, which can be done one of the following ways:
After you apply the package, the device will automatically restart in one minute.
When the device restarts, it connects to the Azure Active Directory and enrolls in Microsoft Intune.
Complete the steps below to create the wrapper package that will be deployed to the necessary devices.
Download and unzip the Win32 Content Prep Tool from GitHub
Download the latest Windows Desktop Client
· Run the Win32 Content Prep tool to create the Win32 .Intunewin Package
o Source and Output folders = The directory/path containing the contents of the Win32 Content Prep tool Zip.
o Setup File = The directory/path to the RDC .msi file downloaded earlier
o Specify Catalog Folder? = N
NOTE: If successful, there will be a .intunewin file with the contents of the Win32 Content Prep tool.
Complete the steps below to create the app policy for the new WVD wrapper package created in the previous section.
From the MEM Admin Center, navigate to Apps > Windows
Click +Add button and select Windows app (Win32)
Click Select app package file, and browse to the .intunewin package created above.
Customize the App Information (name, desc., logo) as needed.
Configure the Program installation command lines and restart behavior
Configure the Requirements (architecture, OS).
Configure Detection Rules
Assign the app to the necessary AAD group(s)
Review the configuration and then Create the App policy
© 2021 Microsoft Corporation. All rights reserved. This document is provided “as-is.” Information and views expressed in this document, including URL and other Internet Web site references, may change without notice. You bear the risk of using it. This document does not provide you with any legal rights to any intellectual property in any Microsoft product. You may copy and use this document for your internal, reference purposes. You may modify this document for your internal, reference purposes.