About Azure Virtual Desktop

Tell us about your PDF experience.
Azure Virtual Desktop documentation

Securely deliver virtual desktops and remote apps with maximum control to any device
from a flexible cloud virtual desktop infrastructure (VDI) platform. Bring together
Microsoft 365 and Azure to provide users with the only multi-session Windows 11 and
Windows 10 experience, with exceptional scale and reduced IT costs.
About Azure Virtual Desktop
ｅ OVERVIEW
What is Azure Virtual Desktop?
What's new in Azure Virtual Desktop?
Terminology
Get started with Azure Virtual Desktop
ｇ TUTORIAL
Create and connect to a Windows 11 desktop with Azure Virtual Desktop
ｂ GET STARTED
Prerequisites
ｃ HOW-TO GUIDE
Create a host pool
Create an application group, a workspace, and assign users
Add session hosts to a host pool
Publish applications
Azure Virtual Desktop for users
ｅ OVERVIEW
Azure Virtual Desktop for users

ｃ HOW-TO GUIDE
Connect with the Windows Desktop client
Connect with the web client
Connect with macOS
Connect with iOS/iPadOS
Connect with Android/Chrome OS
Connect with thin clients
More information
ｄ TRAINING
Introduction to Azure Virtual Desktop
More Azure Virtual Desktop learning paths
ｉ REFERENCE
User experience estimator
Pricing calculator
Reference
ｉ REFERENCE
Azure CLI
PowerShell
REST API
Remote app streaming with Azure Virtual Desktop
ｅ OVERVIEW
Stream apps to your customers

What is Azure Virtual Desktop?
Article • 02/14/2023 • 2 minutes to read
Azure Virtual Desktop is a desktop and app virtualization service that runs on the cloud.
Here's what you can do when you run Azure Virtual Desktop on Azure:
Set up a multi-session Windows 11 or Windows 10 deployment that delivers a full

Windows experience with scalability
Present Microsoft 365 Apps for enterprise and optimize it to run in multi-user
virtual scenarios
Bring your existing Remote Desktop Services (RDS) and Windows Server desktops
and apps to any computer
Virtualize both desktops and apps
Manage desktops and apps from different Windows and Windows Server
operating systems with a unified management experience
Introductory video
Learn about Azure Virtual Desktop (formerly Windows Virtual Desktop), why it's unique,
and what's new in this video:
https://www.youtube-nocookie.com/embed/aPEibGMvxZw
For more videos about Azure Virtual Desktop, see our playlist .
Key capabilities
With Azure Virtual Desktop, you can set up a scalable and flexible environment:
Create a full desktop virtualization environment in your Azure subscription without

running any gateway servers.
Publish host pools as you need to accommodate your diverse workloads.
Bring your own image for production workloads or test from the Azure Gallery.
Reduce costs with pooled, multi-session resources. With the new Windows 11 and
Windows 10 Enterprise multi-session capability, exclusive to Azure Virtual Desktop
and the Remote Desktop Session Host (RDSH) role on Windows Server, you can
greatly reduce the number of virtual machines and operating system overhead
while still providing the same resources to your users.
Provide individual ownership through personal (persistent) desktops.
Use autoscale to automatically increase or decrease capacity based on time of day,
specific days of the week, or as demand changes, helping to manage cost.
You can deploy and manage virtual desktops:
Use the Azure portal, Azure CLI, PowerShell and REST API to configure the host
pools, create app groups, assign users, and publish resources.
Publish full desktop or individual remote apps from a single host pool, create
individual app groups for different sets of users, or even assign users to multiple
app groups to reduce the number of images.
As you manage your environment, use built-in delegated access to assign roles
and collect diagnostics to understand various configuration or user errors.
Use the new Diagnostics service to troubleshoot errors.
Only manage the image and virtual machines, not the infrastructure. You don't
need to personally manage the Remote Desktop roles like you do with Remote
Desktop Services, just the virtual machines in your Azure subscription.
You can also assign and connect users to your virtual desktops:
Once assigned, users can launch any Azure Virtual Desktop client to connect to
their published Windows desktops and applications. Connect from any device
through either a native application on your device or the Azure Virtual Desktop
HTML5 web client.
Securely establish users through reverse connections to the service, so you don't
need to open any inbound ports.
You can see a typical architectural setup of Azure Virtual Desktop for the enterprise in
our architecture documentation.
Next steps
Read through the prerequisites for Azure Virtual Desktop before getting started creating
a host pool.
Prerequisites
Additional resources
 Documentation
Prerequisites for Azure Virtual Desktop

Find what prerequisites you need to complete to successfully connect your users to their Windows
desktops and applications.
Deploy Azure Virtual Desktop with the getting started feature

A quickstart guide for how to quickly set up Azure Virtual Desktop with the Azure portal's getting
started feature.
Understanding total Azure Virtual Desktop deployment costs - Azure

How to estimate the total cost of your Azure Virtual Desktop deployment.
Create a tenant in Azure Virtual Desktop (classic) - Azure

Describes how to set up Azure Virtual Desktop (classic) tenants in Azure Active Directory.
Azure Virtual Desktop host pool Azure portal - Azure

How to create an Azure Virtual Desktop host pool by using the Azure portal.
What's new in Azure Virtual Desktop? - Azure

New features and product updates for Azure Virtual Desktop.
What is Azure Virtual Desktop remote app streaming? - Azure

An overview of Azure Virtual Desktop remote app streaming.
Azure Virtual Desktop terminology - Azure

Learn about the basic elements of Azure Virtual Desktop, like host pools, app groups, and
workspaces.
Show 5 more
 Training
Learning paths and modules

Deliver remote desktops and apps with Azure Virtual Desktop - Training
Azure Virtual Desktop on Microsoft Azure is a desktop and app virtualization service that runs on the
cloud. Azure Virtual Desktop works across devices – including Windows, Mac, iOS, and Android –
with full-featured apps that you can use to access remote desktops and apps.
Learning certificate
Microsoft Certified: Azure Virtual Desktop Specialty - Certifications
Candidates for this certification are server or desktop administrators with subject matter expertise in
designing, implementing, managing, and maintaining Microsoft Azure Virtual Desktop experiences
and remote apps for any device.
Prerequisites for Azure Virtual Desktop
There are a few things you need to start using Azure Virtual Desktop. Here you can find
what prerequisites you need to complete to successfully provide your users with
desktops and applications.
At a high level, you'll need:
＂ An Azure account with an active subscription

＂ An identity provider
＂ A supported operating system
＂ Appropriate licenses
＂ Network connectivity
＂ A Remote Desktop client
Azure account with an active subscription

You'll need an Azure account with an active subscription to deploy Azure Virtual
Desktop. If you don't have one already, you can create an account for free . Your
account must be assigned the contributor or owner role on your subscription.
You also need to make sure you've registered the Microsoft.DesktopVirtualization

resource provider for your subscription. To check the status of the resource provider and
register if needed:
） Important
You must have permission to register a resource provider, which requires the
*/register/action operation. This is included if your account is assigned the
contributor or owner role on your subscription.
1. Sign in to the Azure portal .

2. Select Subscriptions.
3. Select the name of your subscription.
4. Select Resource providers.
5. Search for Microsoft.DesktopVirtualization.
6. If the status is NotRegistered, select Microsoft.DesktopVirtualization, and then
select Register.
7. Verify that the status of Microsoft.DesktopVirtualization is Registered.
Identity
To access virtual desktops and remote apps from your session hosts, your users need to
be able to authenticate. Azure Active Directory (Azure AD) is Microsoft's centralized
cloud identity service that enables this capability. Azure AD is always used to
authenticate users for Azure Virtual Desktop. Session hosts can be joined to the same
Azure AD tenant, or to an Active Directory domain using Active Directory Domain
Services (AD DS) or Azure Active Directory Domain Services (Azure AD DS), providing
you with a choice of flexible configuration options.
Session hosts
You need to join session hosts that provide virtual desktops and remote apps to an AD
DS domain, Azure AD DS domain, or the same Azure AD tenant as your users.
If you're joining session hosts to an AD DS domain and you want to manage them
using Intune, you'll need to configure Azure AD Connect to enable hybrid Azure
AD join.
If you're joining session hosts to an Azure AD DS domain, you can't manage them
using Intune.
Users
Your users need accounts that are in Azure AD. If you're also using AD DS or Azure AD
DS in your deployment of Azure Virtual Desktop, these accounts will need to be hybrid
identities, which means the user account is synchronized. You'll need to keep the
following things in mind based on which account you use:
If you're using Azure AD with AD DS, you'll need to configure Azure AD Connect to
synchronize user identity data between AD DS and Azure AD.
If you're using Azure AD with Azure AD DS, user accounts are synchronized one
way from Azure AD to Azure AD DS. This synchronization process is automatic.
Supported identity scenarios

The following table summarizes identity scenarios that Azure Virtual Desktop currently
supports:
Identity scenario Session hosts User accounts
Azure AD + AD DS Joined to AD DS In Azure AD and AD DS, synchronized

Identity scenario Session hosts User accounts
Azure AD + AD DS Joined to Azure AD In Azure AD and AD DS, synchronized
Azure AD + Azure AD DS Joined to Azure AD In Azure AD and Azure AD DS,

DS synchronized
Azure AD + Azure AD DS + AD Joined to Azure AD In Azure AD and AD DS, synchronized

DS DS
Azure AD + Azure AD DS Joined to Azure AD In Azure AD and Azure AD DS,

synchronized
Azure AD only Joined to Azure AD In Azure AD
７ Note
If you're planning on using Azure AD only with FSLogix Profile Container, you will
need to store profiles on Azure Files. In this scenario, user accounts must be
hybrid identities, which means you'll also need AD DS and Azure AD Connect. You
must create these accounts in AD DS and synchronize them to Azure AD. The
service doesn't currently support environments where users are managed with
Azure AD and synchronized to Azure AD DS.
） Important
The user account must exist in the Azure AD tenant you use for Azure Virtual
Desktop. Azure Virtual Desktop doesn't support B2B, B2C, or personal Microsoft
accounts.
When using hybrid identities, either the UserPrincipalName (UPN) or the Security
Identifier (SID) must match across Active Directory Domain Services and Azure
Active Directory. For more information, see Supported identities and
authentication methods.
Deployment parameters
You'll need to enter the following identity parameters when deploying session hosts:
Domain name, if using AD DS or Azure AD DS.

Credentials to join session hosts to the domain.
Organizational Unit (OU), which is an optional parameter that lets you place
session hosts in the desired OU at deployment time.
） Important
The account you use for joining a domain can't have multi-factor authentication
(MFA) enabled.
When joining an Azure AD DS domain, the account you use must be part of the
AAD DC administrators group.
Operating systems and licenses

You have a choice of operating systems that you can use for session hosts to provide
virtual desktops and remote apps. You can use different operating systems with different
host pools to provide flexibility to your users. We support the following 64-bit versions
of these operating systems, where supported versions and dates are inline with the
Microsoft Lifecycle Policy.
Operating system User access rights
Windows 11 License entitlement:

Enterprise Microsoft 365 E3, E5, A3, A5, F3, Business Premium, Student Use
multi-session Benefit
Windows 11 Windows Enterprise E3, E5
Enterprise Windows VDA E3, E5
Windows 10 Windows Education A3, A5
Enterprise
multi-session External users can use per-user access pricing instead of license
Windows 10 entitlement.
Enterprise
Windows License entitlement:

Server 2022 Remote Desktop Services (RDS) Client Access License (CAL) with
Windows Software Assurance (per-user or per-device), or RDS User
Server 2019 Subscription Licenses.
Windows
Server 2016 Per-user access pricing is not available for Windows Server operating
Windows systems.
Server 2012
R2
） Important
Azure Virtual Desktop doesn't support 32-bit operating systems or SKUs not
listed in the previous table.
Support for Windows 7 ended on January 10, 2023.
Ephemeral OS disks for Azure VMs are not supported.
You can use operating system images provided by Microsoft in the Azure
Marketplace , or your own custom images stored in an Azure Compute Gallery, as a
managed image, or storage blob. To learn more about how to create custom images,
see:
Store and share images in an Azure Compute Gallery.

Create a managed image of a generalized VM in Azure.
Prepare a Windows VHD or VHDX to upload to Azure.
You can deploy virtual machines (VMs) to be used as session hosts from these images
with any of the following methods:
Automatically, as part of the host pool setup process.

Manually, in the Azure portal and adding to a host pool after you've created it.
Programmatically, with Azure CLI, PowerShell, or REST API.
There are different automation and deployment options available depending on which
operating system and version you choose, as shown in the following table:
Operating Azure Manual VM Azure Resource Deploy host pools

system Image deployment Manager template from Azure
Gallery integration Marketplace
Windows 11 Yes Yes Yes Yes

Enterprise multi-
session
Windows 11 Yes Yes No No

Enterprise
Windows 10 Yes Yes Yes Yes

Enterprise multi-
session
Windows 10 Yes Yes No No

Enterprise
Windows Server Yes Yes No No

2022
Operating Azure Manual VM Azure Resource Deploy host pools
system Image deployment Manager template from Azure
Gallery integration Marketplace
Windows Server Yes Yes Yes Yes

2019

2016

2012 R2
 Tip
To simplify user access rights during initial development and testing, Azure Virtual
Desktop supports Azure Dev/Test pricing . If you deploy Azure Virtual Desktop in
an Azure Dev/Test subscription, end users may connect to that deployment without
separate license entitlement in order to perform acceptance tests or provide
feedback.
Network
There are several network requirements you'll need to meet to successfully deploy Azure
Virtual Desktop. This lets users connect to their virtual desktops and remote apps while
also giving them the best possible user experience.
Users connecting to Azure Virtual Desktop securely establish a reverse connection to the
service, which means you don't need to open any inbound ports. Transmission Control
Protocol (TCP) on port 443 is used by default, however RDP Shortpath can be used for
managed networks and public networks that establishes a direct User Datagram
Protocol (UDP)-based transport.
To successfully deploy Azure Virtual Desktop, you'll need to meet the following network
requirements:
You'll need a virtual network and subnet for your session hosts. If you create your
session hosts at the same time as a host pool, you must create this virtual network
in advance for it to appear in the drop-down list. Your virtual network must be in
the same Azure region as the session host.
Make sure this virtual network can connect to your domain controllers and relevant
DNS servers if you're using AD DS or Azure AD DS, since you'll need to join session
hosts to the domain.
Your session hosts and users need to be able to connect to the Azure Virtual
Desktop service. These connections also use TCP on port 443 to a specific list of
URLs. For more information, see Required URL list. You must make sure these URLs
aren't blocked by network filtering or a firewall in order for your deployment to
work properly and be supported. If your users need to access Microsoft 365, make
sure your session hosts can connect to Microsoft 365 endpoints.
Also consider the following:
Your users may need access to applications and data that is hosted on different
networks, so make sure your session hosts can connect to them.
Round-trip time (RTT) latency from the client's network to the Azure region that
contains the host pools should be less than 150 ms. Use the Experience
Estimator to view your connection health and recommended Azure region. To
optimize for network performance, we recommend you create session hosts in the
Azure region closest to your users.
Use Azure Firewall for Azure Virtual Desktop deployments to help you lock down
your environment and filter outbound traffic.
To help secure your Azure Virtual Desktop environment in Azure, we recommend

you don't open inbound port 3389 on your session hosts. Azure Virtual Desktop
doesn't require an open inbound port to be open. If you must open port 3389 for
troubleshooting purposes, we recommend you use just-in-time VM access. We
also recommend you don't assign a public IP address to your session hosts.
７ Note
To keep Azure Virtual Desktop reliable and scalable, we aggregate traffic patterns
and usage to check the health and performance of the infrastructure control plane.
We aggregate this information from all locations where the service infrastructure is,
then send it to the US region. The data sent to the US region includes scrubbed
data, but not customer data. For more information, see Data locations for Azure
Virtual Desktop.
To learn more, see Understanding Azure Virtual Desktop network connectivity.
Session host management

Consider the following when managing session hosts:
Don't enable any policies or configurations that disable Windows Installer. If you
disable Windows Installer, the service won't be able to install agent updates on
your session hosts, and your session hosts won't function properly.
If you're using Azure AD-join with Windows Server for your session hosts, you can't
enroll them in Intune as Windows Server is not supported with Intune. You'll need
to use hybrid Azure AD-join and Group Policy from an Active Directory domain, or
local Group Policy on each session host.
Remote Desktop clients

Your users will need a Remote Desktop client to connect to virtual desktops and remote
apps. The following clients support Azure Virtual Desktop:
Windows Desktop client

Web client
macOS client
iOS and iPadOS client
Android and Chrome OS client
Microsoft Store client
） Important
Azure Virtual Desktop doesn't support connections from the RemoteApp and
Desktop Connections (RADC) client or the Remote Desktop Connection (MSTSC)
client.
To learn which URLs clients use to connect and that you must allow through firewalls
and internet filters, see the Required URL list.
Next steps
Get started with Azure Virtual Desktop by creating a host pool. Head to the following
tutorial to find out more.
Create a host pool with the Azure portal
 Documentation
Deploy Azure Virtual Desktop with the getting started feature

A quickstart guide for how to quickly set up Azure Virtual Desktop with the Azure portal's getting
started feature.
Azure Virtual Desktop host pool service updates - Azure

How to create a validation host pool to monitor service updates before rolling out updates to
production.


Manage app groups for Azure Virtual Desktop portal - Azure

How to manage Azure Virtual Desktop app groups with the Azure portal.
Migrate manually from Azure Virtual Desktop (classic) - Azure

How to migrate manually from Azure Virtual Desktop (classic) to Azure Virtual Desktop.
Azure Virtual Desktop FAQ - Azure

Frequently asked questions and best practices for Azure Virtual Desktop.
Migrate automatically from Azure Virtual Desktop (classic) - Azure

How to migrate automatically from Azure Virtual Desktop (classic) to Azure Virtual Desktop by using
the migration module.
Show 5 more
 Training
Module
Deploy Azure Virtual Desktop - Training
Learn how to deploy Azure Virtual Desktop and customize the workspace for your users.
Certification
What's new in Azure Virtual Desktop?
Azure Virtual Desktop updates regularly. This article is where you'll find out about:
The latest updates

New features
Improvements to existing features
Bug fixes
Make sure to check back here often to keep up with new updates.
February 2023
Here's what changed in February 2023:
Symmetric NAT support for RDP Shortpath in public

preview
This feature is an extension of the generally available Remote Desktop Protocol (RDP)
Shortpath feature that allows us to establish a User Datagram Platform (UDP)
connection indirectly using a relay with the TURN (Traversal Using Relays around NAT)
protocol for symmetric NAT (Network Address Translation). For more information, see
our blog post or RDP Shortpath for Azure Virtual Desktop.
Multimedia redirection enhancements now generally

available
Multimedia Redirection (MMR) is now generally available. MMR enables smooth video
playback while viewing videos in a browser running on Azure Virtual Desktop. For more
information, see our blog post or Understanding multimedia redirection for Azure
Virtual Desktop.
New User Interface for Azure Virtual Desktop web client

now in public preview
The Azure Virtual Desktop web client has a new user interface (UI) that's now in public
preview. This new UI gives the web client a cleaner, more modern look and feel. For
more information, see our blog post or Use features of the Remote Desktop Web
client.
January 2023
Here's what changed in January 2023:
Watermarking for Azure Virtual Desktop now in public

preview
Watermarking for Azure Virtual Desktop is now in public preview for the Windows
Desktop client. This feature protects sensitive information from being captured on client
endpoints by adding watermarks to remote desktops. For more information, see our
blog post or Watermarking in Azure Virtual Desktop.
Give or Take Control for macOS Teams on Azure Virtual

Desktop now generally available
Version 1.31.2211.15001 of the WebRTC Redirector service includes support for Give or
Take Control for macOS users. This version includes performance improvements for Give
or Take Control on Windows. For more information, see Updates for version
1.31.2211.15001.
Microsoft Teams application window sharing on Azure

Virtual Desktop now generally available
Previously, users could only share their full desktop windows or a Microsoft PowerPoint
Live presentation during Teams calls. With application window sharing, users can now
choose a specific window to share from their desktop screen and help reduce the risk of
displaying sensitive content during meetings or calls. For more information, see our blog
post .
Windows 7 End of Support

Starting January 10, 2023, Azure Virtual Desktop no longer supports Windows 7 as a
client or host. We recommend upgrading to a supported Windows release. For more
information, see our blog post .
December 2022
Here's what changed in December 2022:
FSLogix 2210 now generally available

FSLogix version 2210 is now generally available. This version introduces new features
like VHD Disk Compaction, a new process that improves user experience with AppX
applications like built-in Windows apps (inbox apps) and Recycle Bin roaming. For more
information, see our blog post or What’s new in FSLogix.
India metadata service now generally available

The Azure Virtual Desktop region in India is now generally available. Customers can now
store their Azure Virtual Desktop objects and metadata within a database located in the
India geography. For more information, see our blog post .
Confidential Virtual Machine support for Azure Virtual

Desktop now in public preview
Azure Confidential Virtual Machine (VM) support is now in public preview. Azure
Confidential VMs increase data privacy and security by protecting data in use. The public
preview update also adds support for Windows 11 22H2 to Confidential VMs. For more
November 2022
Here's what changed in November 2022:
RDP Shortpath for public networks now generally

available
Remote Desktop Protocol (RDP) Shortpath for public networks is now generally
available. RDP Shortpath improves the transport reliability of Azure Virtual Desktop
connections by establishing a direct User Datagram Protocol (UDP) data flow between
the Remote Desktop client and session hosts. This feature will be enabled by default for
all customers. For more information, see our blog post .
Azure Virtual Desktop Insights at Scale in public preview

The ability to review performance and diagnostic information across multiple host pools
in one view with Azure Virtual Desktop Insights at Scale is now in public preview. For
more information, see our blog post or Use Azure Virtual Desktop Insights to monitor
your deployment.
Intune user configuration for Windows 11 Enterprise

multi-session VMs now generally available
Microsoft Intune user scope configuration for Azure Virtual Desktop multi-session
Virtual Machines (VMs) on Windows 11 is now generally available. With this feature,
you’ll be able to:
Configure user scope policies using the Settings catalog and assign them to
groups of users.
Configure user certificates and assign them to users.
Configure PowerShell scripts to install in the user context and assign them to users.
For more information, see Azure Virtual Desktop multi-session with Intune or our blog
post .
Azure Active Directory Join VMs with FSLogix profiles on

Azure Files now generally available
FSLogix profiles with Azure Active Directory (AD)-joined Windows 10, 11, and Windows
Server 2022 VMs for hybrid users in Azure Virtual Desktop are now generally available.
These FSLogix profiles let you seamlessly access file shares from Azure AD-joined VMs
and use them to store your FSLogix profile containers. For more information, see our
blog post .
Private Link for Azure Virtual Desktop now in public

preview
Private endpoints from Azure Private Link for Azure Virtual Desktop are now in public
preview. Private Link can enable traffic between session hosts, clients, and the Azure
Virtual Desktop service to flow through a private endpoint within your virtual network
instead of the public internet. For more information, see our blog post , read our
overview at Use Azure Private Link with Azure Virtual Desktop (preview), or get started
at Set up Private Link for Azure Virtual Desktop (preview).
October 2022
Here's what changed in October 2022:
Background effects for macOS Teams on Azure Virtual

Desktop now generally available
Background effects for Teams on Azure Virtual Desktop is now generally available for
the macOS version of Teams on Azure Virtual Desktop. This feature lets meeting
participants select an available image in Teams to change their background or choose to
blur their background. Background effects are only compatible with version 10.7.10 or
later of the Azure Virtual Desktop macOS client. For more information, see What’s new
in the macOS client.
Host pool deployment support for Azure availability

zones now generally available
We've improved the host pool deployment process. You can now deploy host pools into
up to three availability zones in supported Azure regions. For more information, see our
blog post .
FSLogix version 2210 now in public preview

FSLogix version 2210 is now public preview. This new version includes new features, bug
fixes, and other improvements. One of the new features is Disk Compaction, which lets
you remove white space in a disk to shrink the disk size. Disk Compaction will save you
significant amounts of storage capacity in the storage spaces where you keep your
FSLogix disks. For more information, see What’s new in FSLogix or the FSLogix Disk
Compaction blog post .
Universal Print for Azure Virtual Desktop now generally

available
The release of Windows 11 22H2 includes an improved printing experience that
combines the benefits of Azure Virtual Desktop and Universal Print for Windows 11
multi-session users. Learn more at Printing on Azure Virtual Desktop using Universal
Print.
September 2022
Here's what changed in September 2022:
Single sign-on and passwordless authentication now in
public preview
The ability to enable an Azure Active Directory (AD)-based single sign-on experience
and support for passwordless authentication, using Windows Hello and security devices
(like FIDO2 keys) is now in public preview. This feature is available for Windows 10,
Windows, 11 and Windows Server 2022 session hosts with the September Cumulative
Update Preview installed. The single sign-on experience is currently compatible with the
Windows Desktop and web clients. For more information, see our blog post .
Connection graphics data logs for Azure Virtual Desktop

now in public preview
The ability to collect graphics data for your Azure Virtual Desktop connections through
Azure Log Analytics is now in public preview. This data can help administrators
understand factors across the server, client, and network that contribute to slow or
choppy experiences for a user. For more information, see our blog post .
Multimedia redirection enhancements now in public

preview
An upgraded version of multimedia redirection (MMR) for Azure Virtual Desktop is now
in public preview. We've made various improvements to this version, including more
supported websites, remote app browser support, and enhancements to media controls
for better clarity and one-click tracing. Learn more at Use multimedia redirection on
Azure Virtual Desktop (preview) and our blog post .
Grouping costs by Azure Virtual Desktop host pool now

in public preview
Microsoft Cost Management has a new feature in public preview that lets you group
Azure Virtual Desktop costs with Azure tags by using the cm-resource-parent tag key.
Cost grouping makes it easier to understand and manage costs by host pool. Learn
more at Tag Azure Virtual Desktop resources to manage costs and our blog post .
August 2022
Here's what changed in August 2022:
Azure portal updates
We've made the following updates to the Azure portal:
Improved search, filtering, and performance.

Added Windows Server 2022 images to the image selection list.
Added "Preferred group type" to the "Basics" tab in the host pool creation process.
Enabled custom images for trusted launch VMs.
New selectable cards, including the following:
Unavailable machines.
User session.
Removed the "Advanced" tab for the process to add a VM to the host pool.
Removed the storage blob image option from the host pool creation and adding
VM processes.
Bug fixes.
Made the following improvements to the "getting started" setup process:
Unchecked link Azure template.
Removed validation on existing domain admins.
Updates to the preview version of FSLogix profiles for

Azure AD-joined VMs
We've updated the public preview version of the Azure Files integration with Azure AD
Kerberos for hybrid identities so that it's now simpler to deploy and manage. The
update should give users using FSLogix user profiles on Azure AD-joined session host
an overall better experience. For more information, see the Azure Files blog post .
Single sign-on and passwordless authentication now in

Windows Insider preview
In the Windows Insider build of Windows 11 22H2, you can now enable a preview
version of the Azure AD-based single sign-on experience. This Windows Insider build
also supports passwordless authentication with Windows Hello and security devices like
FIDO2 keys. For more information, see our blog post .
Universal Print for Azure Virtual Desktop now in Windows

Insider preview
The Windows Insider build of Windows 11 22H2 also includes a preview version of the
Universal Print for Azure Virtual Desktop feature. We hope this feature will provide an
improved printing experience that combines the benefits of Azure Virtual Desktop and
Universal Print for Windows 11 multi-session users. Learn more at Printing on Azure
Virtual Desktop using Universal Print and our blog post .
Autoscale for pooled host pools now generally available

Autoscale on Azure Virtual Desktop for pooled host pools is now generally available.
This feature is a native automated scaling solution that automatically turns session host
virtual machines on and off according to the schedule and capacity thresholds that you
define to fit your workload. Learn more at How autoscale works and our blog post .
Azure Virtual Desktop with Trusted Launch update

Azure Virtual Desktop now supports provisioning Trusted Launch virtual machines with
custom images stored in an Azure Compute Gallery. For more information, see our blog
post .
July 2022
Here's what changed in July 2022:
Scheduled agent updates now generally available

Scheduled agent updates on Azure Virtual Desktop are now generally available. This
feature gives IT admins control over when the Azure Virtual Desktop agent, side-by-side
stack, and Geneva Monitoring agent get updated. For more information, see our blog
post .
FSLogix 2201 hotfix 2

The FSLogix 2201 hotfix 2 update includes fixes to multi-session VHD mounting, Cloud
Cache meta tracking files, and registry cleanup operations. This update doesn't include
new features. Learn more at What’s new in FSLogix and our blog post .
Japan and Australia metadata service now generally

available
The Azure Virtual Desktop metadata database located in Japan and Australia is now
generally available. This update allows customers to store their Azure Virtual Desktop
objects and metadata within a database located within that geography. For more
Azure Virtual Desktop moving away from Storage Blob

image type
Storage Blob images are created from unmanaged disks, which means they lack the
availability, scalability, and frictionless user experience that managed images and Shared
Image Gallery images offer. As a result, Azure Virtual Desktop will be deprecating
support for Storage Blobs image types by August 22, 2022. For more information, see
our blog post .
Azure Virtual Desktop Custom Configuration changing to

PowerShell
Starting July 21, 2022, Azure Virtual Desktop will replace the Custom Configuration
Azure Resource Manager template parameters for creating host pools, adding session
hosts to host pools, and the Getting Started feature with a PowerShell script URL
parameter stored in a publicly accessible location. This replacement includes the
parameters' respective Azure Resource Manager templates. For more information, see
our blog post .
June 2022
Here's what changed in June 2022:
Australia metadata service in public preview

The Azure Virtual Desktop metadata database located in Australia is now in public
preview. This allows customers to store their Azure Virtual Desktop objects and
metadata within a database located within our Australia geography, ensuring that the
data will only reside within Australia. For more information, see our blog post .
Intune user configuration for Windows 11 Enterprise

multi-session VMs in public preview
Deploying Intune user configuration policies from the Microsoft Intune admin center to
Windows 11 Enterprise multi-session virtual machines (VMs) on Azure Virtual Desktop is
now in public preview. In this preview, you can configure the following features:
User scope policies using the Settings catalog.
User certificates via Templates.
PowerShell scripts to run in the user context.
For more information, see our blog post .
Teams media optimizations for macOS now generally

available
Teams media optimizations for redirecting audio and video during calls and meetings to
a local macOS machine is now generally available. To use this feature, you'll need to
update or install, at a minimum, version 10.7.7 of the Azure Virtual Desktop macOS
client. Learn more at Use Microsoft Teams on Azure Virtual Desktop and our blog
post .
May 2022
Here's what changed in May 2022:
Background effects with Teams on Azure Virtual Desktop

now generally available
Users can now make meetings more personalized and avoid unexpected distractions by
applying background effects. Meeting participants can select an available image in
Teams to change their background or choose to blur their background. For more
Multi-window and "Call me with Teams" features now

generally available
The multi-window feature gives users the option to pop out chats, meetings, calls, or
documents into separate windows to streamline their workflow. The "Call me with
Teams" feature lets users transfer a Teams call to their phone. Both features are now
generally available in Teams on Azure Virtual Desktop. For more information, see our
blog post .
Japan metadata service in public preview

The Azure Virtual Desktop metadata database located in Japan is now in public preview.
This allows customers to store their Azure Virtual Desktop objects and metadata within a
database located within our Japan geography, ensuring that the data will only reside
within Japan. For more information, see our blog post .
FSLogix 2201 hotfix

The latest update for FSLogix 2201 includes fixes to Cloud Cache and container
redirection processes. No new features are included with this update. Learn more at
What’s new in FSLogix and our blog post .
April 2022
Here's what changed in April 2022:
Intune device configuration for Windows multi-session

now generally available
Deploying Intune device configuration policies from the Microsoft Intune admin center
to Windows multi-session VMs on Azure Virtual Desktop is now generally available.
Learn more at Using Azure Virtual Desktop multi-session with Intune and our blog
post .
Scheduled Agent Updates public preview

Scheduled Agent Updates is a new feature in public preview that lets IT admins specify
the time and day the Azure Virtual Desktop agent, side-by-side stack, and Geneva
Monitoring agent will update. For more information, see our blog post .
RDP Shortpath for public networks now in public preview

A new feature for RDP Shortpath is now in public preview. With this feature, RDP
Shortpath can provide a direct UDP-based network transport for user sessions over
public networks. Learn more at Azure Virtual Desktop RDP Shortpath for public
networks (preview) and our blog post .
The Azure Virtual Desktop web client has a new URL

Starting April 18, 2022, the Azure Virtual Desktop and Azure Virtual Desktop (classic)
web clients will redirect to a new URL. For more information, see our blog post .
March 2022
Here's what changed in March 2022:
Live Captions with Teams on Azure Virtual Desktop now

generally available
Accessibility has always been important to us, so we're pleased to announce that Teams
for Azure Virtual Desktop now supports real-time captions. Learn how to use live
captions at Use live captions in a Teams meeting . For more information, see our blog
post .
Multimedia redirection enhancements now in public

preview
An upgraded version of multimedia redirection (MMR) for Azure Virtual Desktop is now
in public preview. We've made various improvements to this version, including more
supported websites and media controls for our users. Learn more at Multimedia
redirection for Azure Virtual Desktop and our blog post .
FSLogix version 2201 is now generally available

FSLogix version 2201 is now generally available. This version includes improved sign-in
and sign-out times, cloud cache performance improvements, and accessibility updates.
For more information, see the FSLogix release notes and our blog post .
February 2022
Here's what changed in February 2022:
Network data for Azure Virtual Desktop user connections

You now collect network data (both round trip time and available bandwidth)
throughout a user’s connection in Azure Virtual Desktop with Azure Log Analytics. For
more information, see our blog post .
Unassigning and reassigning personal desktops now

generally available
The feature that lets you reassign or unassign personal desktops is now generally
available. You can unassign or reassign desktops using the Azure portal or REST API. For
more information, see our blog post .
Teams media optimizations for macOS now in public

preview
Teams media optimizations for redirecting audio and video during calls and meetings to
a local macOS machine are now in public preview. To use this feature, you'll need to
update your Azure Virtual Desktop macOS client to version 10.7.7 or later. For more
information, see our blog post or Use Microsoft Teams on Azure Virtual Desktop.
January 2022
FSLogix version 2201 public preview

FSLogix version 2201 is now in public preview. For more information, see our blog
post or the FSLogix release notes.
Migration tool now generally available

The PowerShell commands that migrate metadata from Azure Virtual Desktop (classic)
to Azure Virtual Desktop are now generally available. To learn more about migrating
your existing deployment, see Migrate automatically from Azure Virtual Desktop (classic)
or our blog post .
Increased application group limit

We've increased number of Azure Virtual Desktop application groups you can have on
each Azure Active Directory tenant from 200 to 500. For more information, see our blog
post .
Updates to required URLs

We've updated the required URL list for Azure Virtual Desktop to accommodate Azure
Virtual Desktop agent traffic. For more information, see our blog post .
December 2021

You can now automatically create trusted launch virtual machines through the host pool
creation process instead of having to manually create and add them to a host pool after
deployment. To access this feature, select the Virtual machines tab while creating a host
pool. Learn more at Trusted launch for Azure virtual machines.
Azure Active Directory Join VMs with FSLogix profiles on

Azure Files
Azure Active Directory-joined session hosts for FSLogix profiles on Azure Files in
Windows 10 and 11 multi-session is now in public preview. We've updated Azure Files to
use a Kerberos protocol for Azure Active Directory that lets you secure folders in the file
share to individual users. This new feature also allows FSLogix to function within your
deployment without an Active Directory Domain Controller. For more information, check
out our blog post .
Azure Virtual Desktop pricing calculator updates

We've made some significant updates to improve the Azure Virtual Desktop pricing
experience on the Azure pricing calculator, including the following:
You can now calculate costs for any number of users greater than zero.
The calculator now includes storage and networking or bandwidth costs.
We've added new info messages for clarity.
Fixed bugs that affected storage configuration.
For more information, see the pricing calculator .
November 2021
Here's what changed in November 2021:
Azure Virtual Desktop for Azure Stack HCI

Azure Virtual Desktop for Azure Stack HCI is now in public preview. This feature is for
customers who need desktop virtualization for apps that have to stay on-premises for
performance and data security reasons. To learn more, see our blog post and the
Azure Virtual Desktop for Azure Stack HCI documentation.
Autoscale public preview

We're pleased to introduce the new autoscale feature, which lets you stop or start
session hosts automatically based on a schedule you set. Autoscale lets you optimize
infrastructure costs by configuring your shared or pooled desktops to only charge for
the resources you actually use. You can learn more about the autoscale feature by
reading our documentation and watching our Azure Academy video .
Azure Virtual Desktop starter kit for Power Automate

Your organization can now use the Azure Virtual Desktop starter kit to manage its
robotic process automation (RPA) workloads. Learn more by reading our
documentation.
Tagging with Azure Virtual Desktop

We recently released new documentation about how to configure tags for Azure Virtual
Desktop to track and manage costs. For more information, see Tag Azure Virtual
Desktop resources.
October 2021
Azure Virtual Desktop support for Windows 11

Azure Virtual Desktop support for Windows 11 is now generally available for single and
multi-session deployments. You can now use Windows 11 images when creating host
pools in the Azure portal. For more information, see our blog post .
RDP Shortpath now generally available

Remote Desktop Protocol (RDP) Shortpath for managed networks is now generally
available. RDP Shortpath establishes a direct connection between the Remote Desktop
client and the session host. This direct connection reduces dependency on gateways,
improves the connection's reliability, and increases the bandwidth available for each
user session. For more information, see our blog post .
Screen capture protection updates

Screen capture protection is now supported on the macOS client and the Azure
Government and Azure China clouds. For more information, see our blog post .
Azure Active Directory domain join

Azure Active Directory domain join for Azure Virtual Desktop VMs is now available in the
Azure Government and Azure China clouds. Microsoft Intune is currently only supported
in the Azure Public cloud. Learn more at Deploy Azure AD-joined virtual machines in
Azure Virtual Desktop.
Breaking change in Azure Virtual Desktop Azure Resource

Manager template
A breaking change has been introduced into the Azure Resource Manager template for
Azure Virtual Desktop. If you're using any code that depends on the change, then you'll
need to follow the directions in our blog post to address the issue.
Autoscale (preview) public preview

Autoscale for Azure Virtual Desktop is now in public preview. This feature natively turns
your virtual machines (VMs) in pooled host pools on or off based on availability needs.
Scheduling when your VMs turn on and off optimizes deployment costs, and this feature
also offers flexible scheduling options based on your needs. Once you've configured the
required custom Role-Based Access Control (RBAC) role, you can start configuring your
scaling plan. For more information, see Autoscale (preview) for Azure Virtual Desktop
host pools.
September 2021
Here's what changed in September 2021.

You can now use Azure Resource Manager templates for any update you want to apply
to your session hosts after deployment. You can access this feature by selecting the
Virtual machines tab while creating a host pool.
You can also now set host pool, app group, and workspace diagnostic settings while
creating host pools instead of afterwards. Configuring these settings during the host
pool creation process also automatically sets up reporting data for Azure Virtual
Desktop Insights.
Azure Active Directory domain join

Azure Active Directory domain join is now generally available. This service lets you join
your session hosts to Azure Active Directory (Azure AD). Domain join also lets you
autoenroll into Microsoft Intune. You can access this feature in the Azure public cloud,
but not the Government cloud or Azure China. For more information, see our blog
post .
Azure China
Azure Virtual Desktop is now generally available in the Azure China cloud. For more
Automatic migration module tool

With the automatic migration tool, you can move your organization from Azure Virtual
Desktop (classic) to Azure Virtual Desktop with just a few PowerShell commands. This
feature is currently in public preview, and you can find out more at Automatic migration.
August 2021
Windows 11 (Preview) for Azure Virtual Desktop

Windows 11 (Preview) images are now available in the Azure Marketplace for customers
to test and validate with Azure Virtual Desktop. For more information, see our
announcement .
Multimedia redirection is now in public preview

Multimedia redirection gives you smooth video playback while watching videos in your
Azure Virtual Desktop web browser and works with Microsoft Edge and Google Chrome.
Learn more at our blog post .
Windows Defender Application Control and Azure Disk

Encryption support
Azure Virtual Desktop now supports Windows Defender Application Control to control
which drivers and applications are allowed to run on Windows virtual machines (VMs),
and Azure Disk Encryption, which uses Windows BitLocker to provide volume encryption
for the OS and data disks of your VMs. For more information, see our announcement .
Signing into Azure Active Directory using smart cards are

now supported in Azure Virtual Desktop
While this isn't a new feature for Azure Active Directory, Azure Virtual Desktop now
supports configuring Active Directory Federation Services to sign in with smart cards.
For more information, see our announcement .
Screen capture protection is now generally available

Prevent sensitive information from being screen captured by software running on the
client endpoints with screen capture protection in Azure Virtual Desktop. Learn more at
our blog post .
July 2021
Here's what changed in July 2021:
Azure Virtual Desktop images now include optimized

Teams
All available images in the Azure Virtual Desktop image gallery that include Microsoft
365 Apps for Enterprise now have the media-optimized version of Teams for Azure
Virtual Desktop pre-installed. For more information, see our announcement .
Azure Active Directory Domain Join for Session hosts is in

public preview
You can now join your Azure Virtual Desktop virtual machines (VMs) directly to Azure
Active Directory (Azure AD). This feature lets you connect to your VMs from any device
with basic credentials. You can also automatically enroll your VMs with Microsoft Intune.
For certain scenarios, this will help eliminate the need for a domain controller, reduce
costs, and streamline your deployment. Learn more at Deploy Azure AD joined virtual
machines in Azure Virtual Desktop.
FSLogix version 2105 is now available

FSLogix version 2105 is now generally available. This version includes improved sign-in
times and bug fixes that weren't available in the public preview version (version 2105).
For more detailed information, you can see the FSLogix release notes and our blog
post .
Azure Virtual Desktop in China has entered public

preview
With Azure Virtual Desktop available in China, we now have more rounded global
coverage that helps organizations support customers in this region with improved
performance and latency. Learn more at our announcement page .
The getting started feature for Azure Virtual Desktop

This feature offers a streamlined onboarding experience in the Azure portal to set up
your Azure Virtual Desktop environment. You can use this feature to create deployments
that meet system requirements for automated Azure Active Directory Domain Services
the simple and easy way. For more information, check out our blog post .
Start VM on connect is now generally available

The start VM on connect feature is now generally available. This feature helps you
optimize costs by letting you turn off deallocated or stopped VMs, letting your
deployment be flexible with user demands. For more information, see Start Virtual
Machine on Connect.
Remote app streaming documentation

We recently announced a new pricing option for remote app streaming for using Azure
Virtual Desktop to deliver apps as a service to your customers and business partners. For
example, software vendors can use remote app streaming to deliver apps as a software
as a service (SaaS) solution that's accessible to their customers. To learn more about
remote app streaming, check out our documentation.
From July 14, 2021 to December 31, 2021, we're giving customers who use remote app
streaming a promotional offer that lets their business partners and customers access
Azure Virtual Desktop for no charge. This offer only applies to external user access
rights. Regular billing will resume on January 1, 2022. In the meantime, you can continue
to use your existing Windows license entitlements found in licenses like Microsoft 365
E3 or Windows E3. To learn more about this offer, see the Azure Virtual Desktop pricing
page .
New Azure Virtual Desktop handbooks

We recently released four new handbooks to help you design and deploy Azure Virtual
Desktop in different scenarios:
Application Management will show you how to modernize application delivery

and simplify IT management.
In Disaster Recovery , learn how to strengthen business resilience by developing
a disaster recovery strategy.
Get more value from Citrix investments with the Citrix Cloud with Azure Virtual
Desktop migration guide.
Get more value from existing VMware investments with the VMware Horizon with
Azure Virtual Desktop migration guide.
June 2021
Here's what changed in June 2021:
Windows Virtual Desktop is now Azure Virtual Desktop

To better align with our vision of a flexible cloud desktop and remote application
platform, we've renamed Windows Virtual Desktop to Azure Virtual Desktop. Learn more
at the announcement post in our blog .
EU, UK, and Canada geographies are now generally

available
Metadata service for the European Union, UK, and Canada is now in general availability.
These new locations are very important to data sovereignty outside the US. For more
The Getting Started tool is now in public preview

We created the Azure Virtual Desktop Getting Started tool to make the deployment
process easier for first-time users. By simplifying and automating the deployment
process, we hope this tool will help make adopting Azure Virtual Desktop faster and
more accessible to a wider variety of users. Learn more at our blog post .
Azure Virtual Desktop pricing calculator updates

We've made some significant updates to improve the Azure Virtual Desktop pricing
experience on the Azure pricing calculator, including the following:
We've updated the service name to Azure Virtual Desktop

We also updated the layout with the following new items:
A Storage section with both managed disk and file storage bandwidth
A custom section that shows cost-per-user
You can access the pricing calculator at this page .
Single Sign-on (SSO) using Active Directory Federation

Services (AD FS)
The AD FS single-sign on feature is now generally available. This feature lets customers
use AD FS to give a single sign-on experience for users on the Windows and web clients.
For more information, see Configure AD FS single sign-on for Azure Virtual Desktop.
May 2021
Here's what's new for May 2021:
Smart card authentication

We've now officially released the Key Distribution Center (KDC) Proxy Remote Desktop
Protocol (RDP) properties. These properties enable Kerberos authentication for the RDP
portion of an Azure Virtual Desktop session, which includes permitting Network Level
Authentication without a password. Learn more at our blog post .
The web client now supports file transfer

Starting with the public preview version of the web client, version 1.0.24.7 (preview),
users can now transfer files between their remote session and local computer. To upload
files to the remote session, select the upload icon in the menu at the top of the web
client page. To download files, search for Remote Desktop Virtual Drive in the Start
menu on your remote session. After you've opened your virtual drive, just drag and drop
your files into the Downloads folder and the browser will begin downloading the files to
your local computer.
Start VM on connect support updates

Start VM on connect (preview) now supports pooled host pools and the Azure
Government Cloud. To learn more, read our blog post .
Latency improvements for the United Arab Emirates

region
We've expanded our Azure control plane presence to the United Arab Emirates (UAE), so
customers in that region can now experience improved latency. Learn more at our Azure
Virtual Desktop roadmap .
Ending Internet Explorer 11 support

On September 30, 2021, the Azure Virtual Desktop web client will no longer support
Internet Explorer 11. We recommend you start using the Microsoft Edge browser for
your web client and remote sessions instead. For more information, see the
announcement in this blog post .
Microsoft Intune public preview

We've started the public preview for Microsoft Intune support in Windows 10 Enterprise
multi-session. This new feature will let you manage your Windows 10 VMs with the
same tools as your local devices. Learn more at our Microsoft Endpoint Manger
documentation.
FSLogix version 2105 public preview

We have released a public preview of the latest version of the FSLogix agent. Check out
our blog post for more information and to submit the form you'll need to access the
preview.
May 2021 updates for Teams for Azure Virtual Desktop

For this update, we resolved an issue that caused the screen to remain black while
sharing video. We also fixed a mismatch in video resolutions between the session client
and the Teams server. Teams on Azure Virtual Desktop should now change resolution
and bit rates based on input from the Teams server.
Azure portal deployment updates

We've made the following updates to the deployment process in the Azure portal:
Added new images (including GEN2) to the drop-down list box of "image" when
creating a new Azure Virtual Desktop session host VM.
You can now configure boot diagnostics for virtual machines when creating a host
pool.
Added a tool tip to the RDP proxy in the advanced host pool RDP properties tab.
Added an information bubble for the icon path when adding an application from
an MSIX package.
You can no longer do managed boot diagnostics with an unmanaged disk.
Updated the template for creating a host pool in Azure Resource Manager so that
the Azure portal can now support creating host pools with third-party marketplace
images.
Single sign-on using Active Directory Federation Services

public preview
We've started a public preview for Active Directory Federation Services (AD FS) support
for single sign-on (SSO) per host pool. Learn more at Configure AD FS single sign-on for
Enterprise-scale support
We've released an updated section of the Cloud Adoption framework for Enterprise-
scale support for Azure Virtual Desktop. For more information, see Enterprise-scale
support for the Azure Virtual Desktop construction set.
Customer adoption kit

We've recently released the Azure Virtual Desktop Customer adoption kit to help
customers and partners set up Azure Virtual Desktop for their customers. You can
download the kit here .
April 2021
Here's what's new for April:
Use the Start VM on Connect feature (preview) in the

Azure portal
You can now configure Start VM on Connect (preview) in the Azure portal. With this
update, users can access their VMs from the Android and macOS clients. To learn more,
see Start VM on Connect.
Required URL Check tool

The Azure Virtual Desktop agent, version 1.0.2944.400 includes a tool that validates
URLs and displays whether the virtual machine can access the URLs it needs to function.
If any required URLs are accessible, the tool will list them so you can unblock them, if
needed. Learn more at Required URL Check tool.
Updates to the Azure portal UI for Azure Virtual Desktop

Here's what changed in the latest update of the Azure portal UI for Azure Virtual
Desktop:
Fixed an issue that caused an error to appear when retrieving the session host
while drain mode is enabled.
Upgraded the Portal SDK to version 7.161.0.
Fixed an issue that caused the resource ID missing error message to appear in the
User Sessions tab.
The Azure portal now shows detailed sub-status messages for session hosts.
April 2021 updates for Teams on Azure Virtual Desktop

Here's what's new for Teams on Azure Virtual Desktop:
Added hardware acceleration for video processing of outgoing video streams for
Windows 10-based clients.
When joining a meeting with both a front facing camera and a rear facing or
external camera, the front facing camera will be selected by default.
Resolved an issue that made Teams crash on x86-based machines.
Resolved an issue that caused striations during screen sharing.
Resolved an issue that prevented meeting members from seeing incoming video
or screen sharing.
MSIX app attach is now generally available

MSIX app attach for Azure Virtual Desktop has now come out of public preview and is
available to all users. Learn more about MSIX app attach at our TechCommunity
announcement .
The macOS client now supports Apple Silicon and Big Sur
The macOS Azure Virtual Desktop client now supports Apple Silicon and Big Sur. The full
list of updates is available in What's new in the macOS client.
March 2021
Here's what changed in March 2021.
Updates to the Azure portal UI for Azure Virtual Desktop

We've made the following updates to Azure Virtual Desktop for the Azure portal:
We've enabled new availability options (availability set and zones) for the
workflows to create host pools and add VMs.
We've fixed an issue where a host with the "Needs assistance" status appeared as
unavailable. Now the host will have a warning icon next to it.
We've enabled sorting for active sessions.
You can now send messages to or sign out specific users on the host details tab.
We've changed the maximum session limit field.
We've added an OU validation path to the workflow to create a host pool.
You can now use the latest version of the Windows 10 image when you create a
personal host pool.
Generation 2 images and Trusted Launch

The Azure Marketplace now has Generation 2 images for Windows 10 Enterprise and
Windows 10 Enterprise multi-session. These images will let you use Trusted Launch VMs.
Learn more about Generation 2 VMs at Should I create a generation 1 or 2 virtual
machine. To learn how to provision Azure Virtual Desktop Trusted Launch VMs, see our
TechCommunity post .
FSLogix is now preinstalled on Windows 10 Enterprise
multi-session images
Based on customer feedback, we've released a new version of the Windows 10
Enterprise multi-session image that has an unconfigured version of FSLogix already
installed. We hope this makes your Azure Virtual Desktop deployment easier.
Azure Virtual Desktop Insights is now in General

Availability
Azure Virtual Desktop Insights is now generally available to the public. This feature is an
automated service that monitors your deployments and lets you view events, health,
and troubleshooting suggestions in a single place. For more information, see our
documentation or check out our TechCommunity post .
March 2021 updates for Teams on Azure Virtual Desktop

We've made the following updates for Teams on Azure Virtual Desktop:
We've improved video quality performance on calls and 2x2 mode.

We've reduced CPU utilization by 5-10% (depending on CPU generation) by using
hardware offload of video processing (XVP).
Older machines can now use XVP and hardware decoding to display more
incoming video streams smoothly in 2x2 mode.
We've updated the WebRTC stack from M74 to M88 for better AV sync
performance and fewer transient issues.
We've replaced our software H264 encoder with OpenH264 (OSS used in Teams on
the web), which increased the video quality of the outgoing camera.
We enabled 2x2 mode for Teams Server for the general public on March 30. 2x2
mode shows up to four incoming video streams at the same time.
Start VM on Connect public preview

The new host pool setting, Start VM on Connect, is now available in public preview. This
setting lets you turn on your VMs whenever you need them. If you want to save costs,
you'll need to deallocate your VMs by configuring your Azure Compute settings. For
more information, check out our blog post and our documentation.
Azure Virtual Desktop Specialty certification

We've released a beta version of the AZ-140 exam that will let you prove your expertise
in Azure Virtual Desktop in Azure. To learn more, check out our TechCommunity post .
February 2021
Here's what changed in February 2021.
Portal experience
We've improved the Azure portal experience in the following ways:
Bulk drain mode on hosts in the session host grid tab.

MSIX app attach is now available for public preview.
Fixed host pool overview info for dark mode.
EU metadata storage now in public preview

We're now hosting a public preview of the Europe (EU) geography as a storage option
for service metadata in Azure Virtual Desktop. Customers can choose between West or
North Europe when they create their service objects. The service objects and metadata
for the host pools will be stored in the Azure geography associated with each region. To
learn more, read our blog post announcing the public preview .
Teams on Azure Virtual Desktop plugin updates

We've improved video call quality on the Azure Virtual Desktop plugin by addressing
the most commonly reported issues, such as when the screen would suddenly go dark
or the video and sound desynchronized. These improvements should increase the
performance of single-video view with active speaker switching. We also fixed an issue
where hardware devices with special characters weren't available in Teams.
January 2021
New Azure Virtual Desktop offer

New customers save 30 percent on Azure Virtual Desktop computing costs for D-series
and Bs-series virtual machines for up to 90 days when using the native Microsoft
solution. You can redeem this offer in the Azure portal before March 31, 2021. Learn
more at our Azure Virtual Desktop offer page .
networkSecurityGroupRules value change

In the Azure Resource Manager nested template, we changed the default value for
networkSecurityGroupRules from an object to an array. This will prevent any errors if you
use managedDisks-customimagevm.json without specifying a value for
networkSecurityGroupRules. This wasn't a breaking change and is backward compatible.
FSLogix hotfix update

We’ve released FSLogix, version 2009 HF_01 (2.9.7654.46150) to solve issues in the
previous release (2.9.7621.30127). We recommend you stop using the previous version
and update FSLogix as soon as possible.
For more information, see the release notes in What's new in FSLogix.
Azure portal experience improvements

We've made the following improvements to the Azure portal experience:
You can now add local VM admin credentials directly instead of having to add a
local account created with the Active Directory domain join account credentials.
Users can now list both individual and group assignments in separate tabs for
individual users and groups.
The version number of the Azure Virtual Desktop Agent is now visible in the Virtual
Machine overview for host pools.
Added bulk delete for host pools and application groups.
You can now enable or disable drain mode for multiple session hosts in a host
pool.
Removed the public IP field from the VM details page.
Azure Virtual Desktop Agent troubleshooting

We recently set up the Azure Virtual Desktop Agent troubleshooting guide to help
customers who have encountered common issues.
Microsoft Defender for Endpoint integration

Microsoft Defender for Endpoint integration is now generally available. This feature
gives your Azure Virtual Desktop VMs the same investigation experience as a local
Windows 10 machine. If you're using Windows 10 Enterprise multi-session, Microsoft
Defender for Endpoint will support up to 50 concurrent user connections, giving you the
cost savings of Windows 10 Enterprise multi-session and the confidence of Microsoft
Defender for Endpoint. For more information, check out our blog post .
Azure Security baseline for Azure Virtual Desktop

We've recently published an article about the Azure security baseline for Azure Virtual
Desktop that we'd like to call your attention to. These guidelines include information
about how to apply the Microsoft cloud security benchmark to Azure Virtual Desktop.
The Microsoft cloud security benchmark describes the settings and practices we
recommend you use to secure your cloud solutions on Azure.
December 2020
Azure Virtual Desktop Insights

The public preview for Azure Virtual Desktop Insights is now available. This new feature
includes a robust dashboard built on top of Azure Monitor Workbooks to help IT
professionals understand their Azure Virtual Desktop environments. Check out the
announcement on our blog for more details.
Azure Resource Manager template change

In the latest update, we've removed all public IP address parameter from the Azure
Resource Manager template for creating and provisioning host pools. We highly
recommend you avoid using public IPs for Azure Virtual Desktop to keep your
deployment secure. If your deployment relied on public IPs, you'll need to reconfigure it
to use private IPs instead, otherwise your deployment won't work properly.
MSIX app attach public preview

MSIX app attach is another service that began its public preview this month. MSIX app
attach is a service that dynamically presents MSIX applications to your Azure Virtual
Desktop Session host VMs. Check out the announcement on our blog for more
details.
Screen capture protection
This month also marked the beginning of the public preview for screen capture
protection. You can use this feature to prevent sensitive information from being
captured on the client endpoints. Give screen capture protection a try by going to this
page .
Built-in roles
We've added new built-in roles for Azure Virtual Desktop for admin permissions. For
more information, see Built-in roles for Azure Virtual Desktop.
Application group limit increase

We've increased the default application group limit per Azure Active Directory tenant to
200 groups.
November 2020
Azure portal experience

We've fixed two bugs in the Azure portal user experience:
The Desktop application friendly name is no longer overwritten on the "Add VM"
workflow.
The session host tab will now load if session hosts are part of scale sets.
FSLogix client, version 2009

We've released a new version of the FSLogix client with many fixes and improvements.
Learn more at our blog post .
RDP Shortpath public preview

RDP Shortpath introduces direct connectivity to your Azure Virtual Desktop session host
using point-to-site and site-to-site VPNs and ExpressRoute. It also introduces the URCP
transport protocol. RDP Shortpath is designed to reduce latency and network hops in
order to improve user experience. Learn more at Azure Virtual Desktop RDP Shortpath.
Az.DesktopVirtualization, version 2.0.1
We've released version 2.0.1 of the Azure Virtual Desktop cmdlets. This update includes
cmdlets that will let you manage MSIX App Attach. You can download the new version
at the PowerShell gallery .
Azure Advisor updates

Azure Advisor now has a new recommendation for proximity guidance in Azure Virtual
Desktop, and a new recommendation for optimizing performance in depth-first load
balanced host pools. Learn more at the Azure website .
October 2020
Improved performance
We've optimized performance by reducing connection latency in the following Azure
geographies:
Switzerland
Canada
You can now use the Experience Estimator to estimate the user experience quality in
these areas.
Azure Government Cloud availability

The Azure Government Cloud is now generally available. Learn more at our blog post .
Azure Virtual Desktop Azure portal updates

We've made some updates to the Azure Virtual Desktop Azure portal:
Fixed a resourceID error that prevented users from opening the "Sessions" tab.
Streamlined the UI on the "Session hosts" tab.
Fixed the "Defaults," "Usability," and "Restore defaults" settings under RDP
properties.
Made "Remove" and "Delete" functions consistent across all tabs.
The portal now validates app names in the "Add an app" workflow.
Fixed an issue where the session host export data wasn't aligned in the columns.
Fixed an issue where the portal couldn't retrieve user sessions.
Fixed an issue in session host retrieval that happened when the virtual machine
was created in a different resource group.
Updated the "Session host" tab to list both active and disconnected sessions.
The "Applications" tab now has pages.
Fixed an issue where the "requires command line" text didn't display correctly in
the "Application list" tab.
Fixed an issue when the portal couldn't deploy host pools or virtual machines while
using the German-language version of the Shared Image Gallery.
September 2020
Here's what changed in September 2020:
We've optimized performance by reducing connection latency in the following

Azure geographies:
Germany
South Africa (for validation environments only)
You can now use the Experience Estimator to estimate the user experience quality in
these areas.
We released version 1.2.1364 of the Windows Desktop client for Azure Virtual
Desktop. In this update, we made the following changes:
Fixed an issue where single sign-on (SSO) didn't work on Windows 7.
Fixed an issue that caused the client to disconnect when a user who enabled
media optimization for Teams tried to call or join a Teams meeting while
another app had an audio stream open in exclusive mode.
Fixed an issue where Teams didn't enumerate audio or video devices when
media optimization for Teams was enabled.
Added a "Need help with settings?" link to the desktop settings page.
Fixed an issue with the "Subscribe" button that happened when using high-
contrast dark themes.
Thanks to the tremendous help from our users, we've fixed two critical issues for
the Microsoft Store Remote Desktop client. We'll continue to review feedback and
fix issues as we broaden our phased release of the client to more users worldwide.
We've added a new feature that lets you change VM location, image, resource
group, prefix name, network config as part of the workflow for adding a VM to
your deployment in the Azure portal.
IT Pros can now manage hybrid Azure Active Directory-joined Windows 10
Enterprise VMs using Microsoft Intune. To learn more, see our blog post .
August 2020
We've improved performance to reduce connection latency in the following Azure

regions:
United Kingdom
France
Norway
South Korea
You can use the Experience Estimator to get a general idea of how these
changes will affect your users.
The Microsoft Store Remote Desktop Client (v10.2.1522+) is now generally

available! This version of the Microsoft Store Remote Desktop Client is compatible
with Azure Virtual Desktop. We've also introduced refreshed UI flows for improved
user experiences. This update includes fluent design, light and dark modes, and
many other exciting changes. We've also rewritten the client to use the same
underlying remote desktop protocol (RDP) engine as the iOS, macOS, and Android
clients. This lets us deliver new features at a faster rate across all platforms.
Download the client and give it a try!
We fixed an issue in the Teams Desktop client (version 1.3.00.21759) where the
client only showed the UTC time zone in the chat, channels, and calendar. The
updated client now shows the remote session's time zone instead.
Azure Advisor is now a part of Azure Virtual Desktop. When you access Azure
Virtual Desktop through the Azure portal, you can see recommendations for
optimizing your Azure Virtual Desktop environment. Learn more at Introduction to
Azure Advisor.
Azure CLI now supports Azure Virtual Desktop ( az desktopvirtualization ) to help

you automate your Azure Virtual Desktop deployments. Check out
desktopvirtualization for a list of extension commands.
We've updated our deployment templates to make them fully compatible with the
Azure Virtual Desktop Azure Resource Manager interfaces. You can find the
templates on GitHub .
The Azure Virtual Desktop US Gov portal is now in public preview. To learn more,
see our announcement .
July 2020
July was when Azure Virtual Desktop with Azure Resource Management integration
became generally available.
Here's what changed with this new release:
The "Fall 2019 release" is now known as "Azure Virtual Desktop (classic)," while the
"Spring 2020 release" is now just "Azure Virtual Desktop." For more information,
check out this blog post .
To learn more about new features, check out this blog post .
Autoscaling tool update

The latest version of the autoscaling tool that was in preview is now generally available.
This tool uses an Azure Automation account and the Azure Logic App to automatically
shut down and restart session host VMs within a host pool, reducing infrastructure
costs. Learn more at Scale session hosts using Azure Automation.
Azure portal
You can now do the following things with the Azure portal in Azure Virtual Desktop:
Directly assign users to personal desktop session hosts

Change the validation environment setting for host pools
Diagnostics
We've released some new prebuilt queries for the Log Analytics workspace. To access
the queries, go to Logs and under Category, select Azure Virtual Desktop. Learn more
at Use Log Analytics for the diagnostics feature.
Update for Remote Desktop client for Android

The Remote Desktop client for Android now supports Azure Virtual Desktop
connections. Starting with version 10.0.7, the Android client features a new UI for
improved user experience. The client also integrates with Microsoft Authenticator on
Android devices to enable conditional access when subscribing to Azure Virtual Desktop
workspaces.
The previous version of Remote Desktop client is now called “Remote Desktop 8." Any
existing connections you have in the earlier version of the client will be transferred
seamlessly to the new client. The new client has been rewritten to the same underlying
RDP core engine as the iOS and macOS clients, faster release of new features across all
platforms.
Teams update
We've made improvements to Microsoft Teams for Azure Virtual Desktop. Most
importantly, Azure Virtual Desktop now supports audio and video optimization for the
Windows Desktop client. Redirection improves latency by creating direct paths between
users when they use audio or video in calls and meetings. Less distance means fewer
hops, which makes calls look and sound smoother. Learn more at Use Teams on Azure
Virtual Desktop.
June 2020
Last month, we introduced Azure Virtual Desktop with Azure Resource Manager
integration in preview. This update has lots of exciting new features we'd love to tell you
about. Here's what's new for this version of Azure Virtual Desktop.
Azure Virtual Desktop is now integrated with Azure

Resource Manager
Azure Virtual Desktop is now integrated into Azure Resource Manager. In the latest
update, all Azure Virtual Desktop objects are now Azure Resource Manager resources.
This update is also integrated with Azure role-based access control (Azure RBAC). See
What is Azure Resource Manager? to learn more.
Here's what this change does for you:
Azure Virtual Desktop is now integrated with the Azure portal. This means you can
manage everything directly in the portal, no PowerShell, web apps, or third-party
tools required. To get started, check out our tutorial at Create a host pool with the
Azure portal.
Before this update, you could only publish RemoteApps and Desktops to individual
users. With Azure Resource Manager, you can now publish resources to Azure
Active Directory groups.
The earlier version of Azure Virtual Desktop had four built-in admin roles that you
could assign to a tenant or host pool. These roles are now in Azure role-based
access control (Azure RBAC). You can apply these roles to every Azure Virtual
Desktop Azure Resource Manager object, which lets you have a full, rich delegation
model.
In this update, you no longer need to run Azure Marketplace or the GitHub
template repeatedly to expand a host pool. All you need to expand a host pool is
to go to your host pool in the Azure portal and select + Add to deploy additional
session hosts.
Host pool deployment is now fully integrated with the Azure Shared Image Gallery.
Shared Image Gallery is a separate Azure service that stores VM image definitions,
including image versioning. You can also use global replication to copy and send
your images to other Azure regions for local deployment.
Monitoring functions that used to be done through PowerShell or the Diagnostics

Service web app have now moved to Log Analytics in the Azure portal. You also
now have two options to visualize your reports. You can run Kusto queries and use
Workbooks to create visual reports.
You're no longer required to complete Azure Active Directory consent to use Azure
Virtual Desktop. In this update, the Azure Active Directory tenant on your Azure
subscription authenticates your users and provides Azure RBAC controls for your
admins.
PowerShell support
We've added new AzWvd cmdlets to the Azure Az PowerShell module with this update.
This new module is supported in PowerShell Core, which runs on .NET Core.
To install the module, follow the instructions in Set up the PowerShell module for Azure
Virtual Desktop.
You can also see a list of available commands at the AzWvd PowerShell reference.
For more information about the new features, check out our blog post .
Additional gateways
We've added a new gateway cluster in South Africa to reduce connection latency.
Microsoft Teams on Azure Virtual Desktop (Preview)
We've made some improvements to Microsoft Teams for Azure Virtual Desktop. Most
importantly, Azure Virtual Desktop now supports audio and visual redirection for calls.
Redirection improves latency by creating direct paths between users when they call
using audio or video. Less distance means fewer hops, which makes calls look and
sound smoother.
To learn more, see our blog post .
 Documentation

Configure a host pool as a validation environment - Azure

How to configure a host pool as a validation environment to test service updates before they roll out
to production.
Set up service alerts for Azure Virtual Desktop - Azure

How to set up Azure Service Health to receive service notifications for Azure Virtual Desktop.
What's new in Azure Virtual Desktop Insights?

New features and product updates in Azure Virtual Desktop Insights.
What's new in multimedia redirection MMR? - Azure Virtual Desktop

New features and product updates for multimedia redirection for Azure Virtual Desktop.
Data locations for Azure Virtual Desktop - Azure

A brief overview of which locations Azure Virtual Desktop's data and metadata are stored in.
Administrative template for Azure Virtual Desktop

Learn how to use the administrative template for Azure Virtual Desktop with Group Policy to
configure settings.
Publish built-in apps in Azure Virtual Desktop - Azure

How to publish built-in apps in Azure Virtual Desktop.
Show 5 more
 Training
Learning path
Certification
What's new in the Azure Virtual Desktop
Agent?
The Azure Virtual Desktop Agent updates regularly. This article is where you'll find out
about:
The latest updates

New features
Improvements to existing features
Bug fixes
Make sure to check back here often to keep up with new updates.
Latest agent versions

New versions of the Azure Virtual Desktop Agent are installed automatically. When new
versions are released, they are rolled out progressively to all session hosts. This process
is called flighting and it enables Microsoft to monitor the rollout. The following table
lists the version that is in-flight and the version that is generally available.
Release Latest version
Generally available 1.0.6129.9100
In-flight N/A
Version 1.0.6129.9100
This update was released in March 2023 and includes the following changes:
General improvements and bug fixes.
Version 1.0.6028.2200
This update was released in February 2023 and includes the following changes:
Domain Trust health check is now enabled. When virtual machines (VMs) fail the
Domain Trust health check, they're now given the Unavailable status.
Version 1.0.5739.9000/1.0.5739.9800
７ Note
You may see version 1.0.5739.9000 or 1.0.5739.9800 installed on session hosts

depending on whether the host pool is configured to be a validation environment.
Version 1.0.5739.9000 was released to validation environments and version
1.0.5739.9800 was released to all other environments.
Normally, all environments receive the same version. However, for this release, we
had to adjust certain parameters unrelated to the Agent to allow this version to roll
out to non-validation environments, which is why the non-validation version
number is higher than the validation version number. Besides those changes, both
versions are the same.
This update was released in January 2023 and includes the following changes:
Added the RDGateway URL to URL Access Check.

Introduced RD Agent provisioning state for new installations.
Fixed error reporting in MSIX App Attach for apps with expired signatures.
Version 1.0.5555.1010
This update was released in December 2022. There are no changes to the agent in this
version.
Version 1.0.5555.1008
This update was released in November 2022 and includes the following changes:
Increased sensitivity of AppAttachRegister monitor for improved results.

Fixed an error that slowed down Geneva Agent installation.
Version updates for Include Stack.
Version 1.0.5388.1701
This update was released in August 2022 and includes the following changes:
Fixed a bug that prevented the Agent MSI from downloading on the first try.
Modified app attach on-demand registration.
Enhanced the AgentUpdateTelemetry parameter to help with StackFlighting data.
Removed unnecessary WebRTC health check.
Fixed an issue with the RDAgentMetadata parameter.
Version 1.0.5100.1100
This update was released in August 2022 and includes the following changes:
Agent first-party extensions architecture completed.

Fixed Teams error related to Azure Virtual Desktop telemetry.
RDAgentBootloader - revision update to 1.0.4.0.
SessionHostHealthCheckReport is now centralized in a NuGet package to be
shared with first-party Teams.
Fixes to AppAttach.
Version 1.0.4739.1000
This update was released in July 2022 and includes the following changes:
Report session load to Log Analytics for admins to get information on when
MaxSessionLimit is reached.
Adding AADTenant ID claim to the registration token.
Report closing errors to diagnostics explicitly.
Version 1.0.4574.1600
This update was released in June 2022 and includes the following changes:
Fixed broker URL cache to address Agent Telemetry calls.

Fixed some network-related issues.
Created two new mechanisms to trigger health checks.
Additional general bug fixes and agent upgrades.
Version 1.0.4230.1600
This update was released in March 2022 and includes the following changes:
Fixes an issue with the agent health check result being empty for the first agent
heart beat.
Added Azure VM ID to the WVDAgentHealthStatus Log Analytics table.
Updated the agent's update logic to install the Geneva Monitoring agent sooner.
Version 1.0.4119.1500
This update was released in February 2022 and includes the following changes:
Fixes an issue with arithmetic overflow casting exceptions.

Updated the agent to now start the Azure Instance Metadata Service (IMDS) when
the agent starts.
Fixes an issue that caused Sandero name pipe service start ups to be slow when
the VM has no registration information.
General bug fixes and agent improvements.
Version 1.0.4009.1500
This update was released in January 2022 and includes the following changes:
Added logging to better capture agent update telemetry.

Updated the agent's Azure Instance Metadata Service health check to be Azure
Stack HCI-friendly.
Version 1.0.3855.1400
This update was released December 2021 and has the following changes:
Fixes an issue that caused an unhandled exception.

This version now supports Azure Stack HCI by retrieving VM metadata from the
Azure Arc service.
This version now allows built-in stacks to be automatically updated if its version
number is beneath a certain threshold.
The UrlsAccessibleCheck health check now only gets the URL until the path
delimiter to prevent 404 errors.
Version 1.0.3719.1700
This update was released November 2021 and has the following changes:
Updated agent error messages.

Fixes an issue with the agent restarting every time the side-by-side stack was
updated.
General agent improvements.
Version 1.0.3583.2600
This update was released October 2021 and it fixes an issue where upgrading from
Windows 10 to Windows 11 disabled the side-by-side stack.
Version 1.0.3373.2605
This update was released September 2021 and it fixes an issue with package
deregistration getting stuck when using MSIX App Attach.
Version 1.0.3373.2600
This update was released September 2021 and has the following changes:
General agent improvements.

Fixes issues with restarting the agent on Windows 7 VMs.
Fixes an issue with fields in the WVDAgentHealthStatus table not showing up
correctly.
Version 1.0.3130.2900
This update was released July 2021 and has the following changes:

Fixes an issue with getting the host pool path for Intune registration.
Added logging to better diagnose agent issues.
Fixes an issue with orchestration timeouts.
Version 1.0.3050.2500
Updated internal monitors for agent health.

Updated retry logic for stack health.
Version 1.0.2990.1500
This update was released April 2021 and has the following changes:
Updated agent error messages.

Added an exception that prevents you from installing non-Windows 7 agents on
Windows 7 VMs.
Has updated heartbeat service logic.
Version 1.0.2944.1400
This update was released April 2021 and has the following changes:
Placed links to the Azure Virtual Desktop Agent troubleshooting guide in the event
viewer logs for agent errors.
Added an additional exception for better error handling.
Added the WVDAgentUrlTool.exe that allows customers to check which required
URLs they can access.
Version 1.0.2866.1500
This update was released March 2021 and it fixes an issue with the stack health check.
Version 1.0.2800.2802
This update was released March 2021 and it has general improvements and bug fixes.
Version 1.0.2800.2800
This update was released March 2021 and it fixes a reverse connection issue.
Version 1.0.2800.2700
This update was released February 2021 and it fixes an access denied orchestration
issue.
 Documentation
Azure Virtual Desktop autoscale FAQ - Azure



Troubleshoot service connection Azure Virtual Desktop - Azure

How to resolve issues while setting up service connections in a Azure Virtual Desktop tenant
environment.
Get started with the Azure Virtual Desktop Agent

An overview of the Azure Virtual Desktop Agent and update processes.

Azure Virtual Desktop Scheduled Agent Updates

How to use the Scheduled Agent Updates feature to choose a date and time to update your Azure
Virtual Desktop agent components.

Show 5 more
What's new in Azure Virtual Desktop
Insights?
This article describes the changes we make to each new version of Azure Virtual
Desktop Insights.
If you're not sure which version of Azure Virtual Desktop Insights you're currently using,
you can find it in the bottom-right corner of your Insights page or configuration
workbook. To access your workbook, go to https://aka.ms/azmonwvdi .
How to read version numbers

There are three numbers in each version of Azure Virtual Desktop Insights. Here's what
each number means:
The first number is the major version, and is usually used for major releases.
The second number is the minor version. Minor versions are for backwards-
compatible changes such as new features and deprecation notices.
The third number is the patch version, which is used for small changes that fix
incorrect behavior or bugs.
For example, a release with a version number of 1.2.31 is on the first major release, the
second minor release, and patch number 31.
When one of the numbers is increased, all numbers after it must change, too. One
release has one version number. However, not all version numbers track releases. Patch
numbers can be somewhat arbitrary, for example.
Version 2.0.0
This update was released on March 6, 2023 and had the following change:
The Azure Virtual Desktop Insights at scale feature is now generally available.
Version 1.6.1
This update was released in February 27, 2023 and had the following changes:
The Azure Virtual Desktop Insights at scale feature is now generally available.
Added the version of the OS used on session hosts to the Overview tab.
Version 1.6.0
This update was released on January 30, 2023 and had the following change:
Added idle session reporting to the Utilization tab that visualizes sessions with no
active connections.
Version 1.5.0
This update was released on January 9, 2023 and had the following change:
Added FSLogix compaction information to the Utilization tab for reporting as well
as a User search capability to the at scale public preview.
Version 1.4.0
This update was released in October 2022 and has the following changes:
Added Windows 7 end-of-life reporting for client operating system and a dynamic
notification box as a reminder of the deprecation timeframe for Windows 7
support for Azure Virtual Desktop.
Version 1.3.0
This update was released in September 2022 and has the following changes:
Introduced a public preview of at scale reporting for Azure Virtual Desktop Insights
to allow the selection of multiple subscriptions, resource groups, and host pools.
Version 1.2.2
This update was released in July 2022 and has the following changes:
Updated checkpoint queries for LaunchExecutable.
Version 1.2.1
This update was released in June 2022 and has the following changes:
Updated templates for Configuration Workbook to be available at the gallery

instead of the external GitHub.
Version 1.2.0
This update was released in May 2022 and has the following changes:
Updated language for connection performance to "time to be productive" for

clarity.
Improved and expanded Connection Details flyout panel with additional

information on connection history for selected users.
Added a fix for duplication of some data.
Version 1.1.10
This update was released in February 2022 and has the following changes:
We added support for category groups for resource logs.
Version 1.1.8
This update was released in November 2021 and has the following changes:
We added a dynamic check for host pool and workspaces Log Analytics tables to
show instances where diagnostics may not be configured.
Updated the source table for session history and calculations for users per core.
Version 1.1.7
This update was released in November 2021 and has the following changes:
We increased the session host limit to 1000 for the configuration workbook to
allow for larger deployments.
Version 1.1.6
We updated contents to reflect change from Windows Virtual Desktop to Azure
Virtual Desktop.
Version 1.1.4
We updated data usage reporting in the configuration workbook to include the

agent health table.
Version 1.1.3
This update was released in September 2021 and has the following changes:
We updated filtering behavior to make use of resource IDs.
Version 1.1.2
This update was released in August 2021 and has the following changes:
We updated some formatting in the workbooks.
Version 1.1.1
This update was released in July 2021 and has the following changes:
We added the Workbooks gallery for quick access to Azure Virtual Desktop related
Azure workbooks.
Version 1.1.0
We added a Data Generated tab to the configuration workbook for detailed data
on storage space usage for Azure Virtual Desktop Insights to allow more insight
into Log Analytics usage.
Version 1.0.4
This update was released in June 2021 and has the following changes:
We made some changes to formatting and layout for better use of whitespace.
We changed the sort order for User Input Delay details in Host Performance to
descending.
Version 1.0.3
We updated formatting to prevent truncation of text.
Version 1.0.2
We resolved an issue with user per core calculation in the Utilization tab.
Version 1.0.1
This update was released in April 2021 and has the following changes:
We made a formatting update for columns containing sparklines.
Version 1.0.0
This update was released in March 2021 and has the following changes:
We introduced a new visual indicator for high-impact errors and warnings from the
Azure Virtual Desktop agent event log on the host diagnostics page.
We removed five expensive process performance counters from the default

configuration. For more information, see our blog post at Updated guidance on
Azure Virtual Desktop Insights .
The setup process for Windows Event Log for the configuration workbook is now
automated.
The configuration workbook now supports automated deployment of

recommended Windows Event Logs.
The configuration workbook can now install the Log Analytics agent and setting-
preferred workspace for session hosts outside of the resource group's region.
The configuration workbook now has a tabbed layout for the setup process.
We introduced versioning with this update.
Next steps
For the general What's New page, see What's New in Azure Virtual Desktop.
To learn more about Azure Virtual Desktop Insights, see Use Azure Virtual Desktop
Insights to monitor your deployment.
 Documentation



Azure Virtual Desktop autoscale glossary for Azure Virtual Desktop - Azure
A glossary of terms and concepts for the Azure Virtual Desktop autoscale feature.
Azure Virtual Desktop Insights glossary - Azure

A glossary of terms and concepts related to Azure Virtual Desktop Insights.

What's new in the Azure Virtual Desktop Agent? - Azure

New features and product updates for the Azure Virtual Desktop Agent.
Estimate Azure Virtual Desktop Insights monitoring costs - Azure

How to estimate costs and pricing for using Azure Virtual Desktop Insights.
Show 5 more
 Training
Certification
What's new in FSLogix
This page lists the updates for each FSLogix release. We recommend following the
FSLogix installation instructions and always installing the latest release.
Download the latest FSLogix version here: https://aka.ms/fslogix-latest
FSLogix 2210 hotfix 1 (2.9.8440.42104)
Summary
This is a hotfix release to address known issues and other identified bugs.
） Important
Profile logs showing either:
[ERROR:00000005] Failed to empty user's RECYCLE.BIN on the SystemDrive
(Access is denied.)
[ERROR:00000003] Failed to manually empty user's RECYCLE.BIN:
C:\$RECYCLE.BIN\S-1-5-21-000000000-000000000-000000000-1234 (The system
cannot find the path specified.)
These errors should be treated as a WARNING and can be ignored. A user will not
have access to the system drive and in some cases, the Recycle Bin may not exist
when we try to empty it. This will be addressed in our next release.
Changes
Setting: Added new configuration setting (RoamIdentity). Allows legacy roaming
for credentials and tokens created by the Web Account Manager (WAM) system.
Fix: Resolved an issue where frxsvc.exe would crash when processing
AppXPackages.
Fix: Resolved issues in handling FileIds associated with OneDrive.
Fix: Resolved an issue with orphaned meta files on Cloud Cache SMB providers.
Fix: Resolved an issue where a pending rename operation would fail because the
target filename was invalid.
Fix: Resolved an issue where user sessions were cleaned up before a proper sign-
out.
Fix: Resolved an issue where ODFC incorrectly handled multiple VHDLocations.
Fix: Resolved an issue in how settings are applied for ObjectSpecific configurations.
Fix: Resolved an issue where an ODFC container would not correctly detach during
sign-out.
Fix: Resolved an issue where VHD Disk Compaction would fail to cancel correctly
when using Cloud Cache.
Fix: Resolved an issue where ODFC VHD Disk Compaction would fail when
RoamSearch was enabled.
Fix: Resolved an issue where users would be stuck at a black screen as a result of
attempting to empty the Recycle Bin prior to roaming.
Update: Added policy for new RoamIdentity setting.
File Information
Download the following package and follow the installation instructions
Download FSLogix 2210 hotfix 1 (2.9.8440.42104)
FSLogix 2210 (2.9.8361.52326)
Summary
This release is focused on three (3) core features, six (6) major bug fixes, and two (2)
updates.
Changes
Feature: Added the ability to compact the user's container during the sign-out
phase. For more information, see VHD Disk Compaction.
Feature: Added a new process during the sign-out phase which creates an AppX
package manifest for the user. This manifest is used at sign-in to re-register the
AppX applications for an improved user experience. This work is on-going as AppX
packages and applications continue to evolve. The focus for this work has been on
the built-in Windows apps (inbox apps).
Feature: We will now roam the users Recycle Bin within the user's container.
） Important
All three (3) of our new features are enabled by default, but have the option
to be disabled.
Fix: Added recursive checks as part of search clean up activities.
Fix: Registers all provisioned packages when AppxManifest.xml does not exist.
Fix: When OneDrive data is stored outside the user's profile, FSLogix will correctly
impersonate OneDrive for setting permissions.
Fix: Resolved junction point compatibility issues with App-V.
Fix: RW differencing disks will correctly handle disk expansion when SizeInMBs is
increased from a smaller value.
Fix: Cloud Cache will now properly honor lock retry count and intervals.
Update: Group Policy templates have new names that align with their registry
settings. New help information indicates where in the registry Group Policy will
make the change. Added version history for newly added settings.
Update: Ensure Azure Storage Account Blob container names correctly adhere to
Azure naming requirements.
File Information
Download FSLogix 2210 (2.9.8361.52326)
FSLogix 2201 hotfix 2 (2.9.8228.50276)
Summary
This update for FSLogix 2201 includes fixes to multi-session VHD mounting, Cloud
Cache meta tracking files, and registry cleanup operations.
Changes
） Important
This is a hotfix for FSLogix 2201 (2.9.8111.53415) and includes all previous changes
from v2201 hotfix 1 (2.9.8171.14983). It is recommended all customers update to
this version.
Resolved an issue that would cause a system crash while reading from meta
tracking files in a Cloud Cache configuration.
Resolved an issue where a logon would succeed even if when the disk failed to
attach. Most commonly occurs in multi-session environments.
Resolved an issue during profile cleanup where user registry hives would be
removed regardless of the FSLogix local group exclusions.
File Information
FSLogix 2201 hotfix 1 (2.9.8171.14983)
Summary
This update for FSLogix 2201 includes fixes to Cloud Cache and container redirection
processes. No new features are included with this update.
Changes
） Important
This is a hotfix for FSLogix 2201 (2.9.8111.53415). If you are using Cloud Cache or
have experienced intermittent system crashes as a result of FSLogix, it is
recommended to install this update.
Resolved an issue with Cloud Cache where disk read / write blocking could
potentially create a deadlock to the disk and cause the Virtual Machine to become
unresponsive.
Resolved an issue that would cause a Virtual Machine to crash while removing
profile redirections during the sign out process.
File Information
FSLogix 2201 (2.9.8111.53415)
Summary
This update for FSLogix is the latest full featured release. In this version there are over 30
accessibility related updates, new support for Windows Search in specific versions of
Windows, better handling and tracking of locked VHD(x) containers, and resolved a
variety of issues.
Changes
Fixed issue where the FSLogix Profile Service would crash if it was unable to
communicate with the FSLogix Cloud Cache Service.
The OfficeFileCache folder located at
%LOCALAPPDATA%\Microsoft\Office\16.0\OfficeFileCache is now machine specific
and encrypted so we exclude it from FSLogix containers. Office files located
outside this folder are not impacted by this update.
Windows Server 2019 version 1809, and newer versions of Windows Server,
natively support per-user search indexes and we recommend you leverage that
native search index capability. FSLogix Search Indexing is no longer available on
those versions of Windows Server.
Windows 10 Enterprise Multi-session and Windows 11 Enterprise Multi-session
natively support per-user search indexes and FSLogix Search Indexing is no longer
available on those operating systems.
FSLogix now correctly handles cases where the Windows Profile Service refCount
registry value is set to an unexpected value.
Over 30 accessibility related updates have been made to the FSLogix installer and
App Rules Editor.
A Windows event now records when a machine locks a container disk with a
message that looks like "This machine '[HOSTNAME]' is using [USERNAME]'s (SID=
[USER SID]) profile disk. VHD(x): [FILENAME]. This event is generated from the
METADATA file created in the user's profile directory. This file can be ignored, but
not deleted."
Resolved an issue where the DeleteLocalProfileWhenVHDShouldApply registry
setting was ignored in some cases.
Fixed an issue where active user session settings where not retained if the FSLogix
service was restarted. This was causing some logoffs to fail.
Fixed an issue where FSLogix did not properly handle logoff events if Profile or
ODFC containers were disabled during the session or per-user/per-group filters
were applied mid-session that excluded the user from the feature. Now FSLogix
logoff related events will always occur based off the FSLogix settings applied at
login.
FSLogix will no longer attempt to reattach a container disk when the user session is
locked.
Fixed an issue that caused the FSLogix service to crash when reattaching container
disks.
Fixed a Cloud Cache issue that caused IO failures if the session host's storage block
size was smaller than a cloud provider's block size. For optimal performance, we
recommend the session host disk hosting the CCD proxy directory has a physical
block size greater than or equal to the CCD storage provider with the largest block
size.
Fixed a Cloud Cache issue where a timed out read request (network outage,
storage outage, etc.) was not handled properly and would eventually fail.
Reduced the chance for a Cloud Cache container disk corruption if a provider is
experiencing connection issues.
Resolved an issue where temporary rule files were not deleted if rule compilation
failed.
Previously, the Application masking folder was only created for the user who ran
the installer. With this update, the rules folder is created when the Rules editor is
launched.
Resolved an interoperability issue with large OneDrive file downloads that was
causing some operations to fail.
Fixed an issue where per-user and per-group settings did not apply if the Profile or
ODFC container was not enabled for all users.
Resolved an issue where the Office container session configuration was not
cleaned up if a profile fails to load.
Fixed an issue where HKCU App Masking rules leveraging wildcards would fail to
apply.
Fixed an issue that caused some sessions configured with an ODFC container to fail
to login.
Resolved an issue where the App Rules editor would crash if no assignments were
configured.
File Information
Download FSLogix 2201 (2.9.8111.53415)
Provide feedback
Make Suggestions and vote on feature requests: AVD Ideas Board
Next steps
Review FSLogix Overview and Requirements
Install FSLogix
What's new in the Remote Desktop
WebRTC Redirector Service
This article provides information about the latest updates to the Remote Desktop
WebRTC Redirector Service for Teams for Azure Virtual Desktop, which you can
download at Remote Desktop WebRTC Redirector Service .
Latest versions of the Remote Desktop WebRTC

Redirector Service
The following sections describe what changed in each version of the Remote Desktop
WebRTC Redirector Service.
Updates for version 1.33.2302.07001

Date published: March 1, 2023
Download: MSI Installer
Support for non-Latin characters for window names in the application window
share tray.

Date published: January 19, 2023
Download: MSI Installer
Support for application window sharing for Windows users.

Support for Give and Take Control functionality for macOS users.
Latency and performance improvements for Give and Take Control on Windows.
Improved screen share performance.

Date published: June 20, 2022
Download: MSI installer

Fixed an issue that made the WebRTC redirector service disconnect from Teams on
Added keyboard shortcut detection for Shift+Ctrl+; that lets users turn on a
diagnostic overlay during calls on Teams for Azure Virtual Desktop. This feature is
supported in version 1.2.3313 or later of the Windows Desktop client.
Added further stability and reliability improvements to the service.

Date published: December 2, 2021
Download: MSI installer
Fixed a mute notification problem.

Multiple z-ordering fixes in Teams on Azure Virtual Desktop and Teams on
Microsoft 365.
Removed timeout that prevented the WebRTC redirector service from starting
when the user connects.
Fixed setup problems that prevented side-by-side installation from working.

Date published: October 15, 2021
Fixed an issue that caused the screen to turn black while screen sharing. If you've
been experiencing this issue, confirm that this update will resolve it by resizing the
Teams window. If screen sharing starts working again after resizing, the update will
resolve this issue.
You can now control the meeting, ringtone, and notification volume from the host
VM. You can only use this feature with version 1.2.2459 or later of the Windows
Desktop client.
The installer will now make sure that Teams is closed before installing updates.
Fixed an issue that prevented users from returning to full screen mode after
leaving the call window.

Date published: July 29, 2021
Increased the connection reliability between the WebRTC redirector service and the
WebRTC client plugin.
Fixed an issue where minimizing the Teams app during a call or meeting caused
incoming video to drop.
Added support for selecting one monitor to share in multi-monitor desktop
sessions.
Next steps
Learn more about how to set up Teams on Azure Virtual Desktop at Use Microsoft
Teams on Azure Virtual Desktop.
Learn about known issues, limitations, and how to log issues at Troubleshoot Teams on
 Documentation
Microsoft Teams on Azure Virtual Desktop - Azure

How to use Microsoft Teams on Azure Virtual Desktop.
Multimedia redirection on Azure Virtual Desktop - Azure

How to use multimedia redirection for Azure Virtual Desktop (preview).
Configure device redirections - Azure

How to configure device redirections for Azure Virtual Desktop.
Azure Virtual Desktop thin client support - Azure

A brief overview of thin client support for Azure Virtual Desktop.
What's new in multimedia redirection?
This article has the latest updates for multimedia redirection (MMR) for Azure Virtual
Desktop.

Date published: February 7, 2023
In this release, we've made the following changes:
Released general availability-compatible MMR host.

Fixed an issue where content can cause the service to stop working instead of just
giving a playback error.

Added telemetry for time to first frame rendered and detecting a possible stall
issue.
Added changes for calling redirection including dual-tone multiple-frequency
(DTMF) tones, and initial support for video.
Next steps
Learn more about MMR at Understanding multimedia direction for Azure Virtual
Desktop and Use multimedia redirection for Azure Virtual Desktop.
client for Windows
In this article you'll learn about the latest updates for the Remote Desktop client for
Windows. To learn more about using the Remote Desktop client for Windows with Azure
Virtual Desktop, see Connect to Azure Virtual Desktop with the Remote Desktop client
for Windows and Use features of the Remote Desktop client for Windows when
connecting to Azure Virtual Desktop.
Supported client versions

The following table lists the current versions available for the public and Insider releases.
To enable Insider releases, see Enable Windows Insider releases.
Release Latest version Download
Public 1.2.4065 Windows 64-bit (most common)
Windows 32-bit
Windows ARM64
Insider 1.2.4065 Windows 64-bit (most common)
Windows 32-bit
Windows ARM64
Updates for version 1.2.4065

Download: Windows 64-bit , Windows 32-bit , Windows ARM64
General improvements to Narrator experience.

Fixed a bug that caused the client to stop responding when disconnecting from
the session early.
Fixed a bug that caused duplicate error messages to appear while connected to an
Azure Active Directory-joined host using the new Remote Desktop Services (RDS)
Azure Active Directory (Azure AD) Auth protocol.
Fixed a bug that caused scale resolution options to not display in display settings
for session desktops.
Added support for Universal Plug and Play (UPnP) for improved User Datagram
Protocol (UDP) connectivity.
Improved client logging, diagnostics, and error classification to help admins
troubleshoot connection and feed issues.
Updates to MMR for Azure Virtual Desktop, including the following:
Fixed an issue that caused multimedia redirection (MMR) for Azure Virtual
Desktop to not load for the ARM64 version of the client.
Updates to Teams for Azure Virtual Desktop, including the following:
Fixed an issue that caused the application window sharing to freeze or show a
black screen in scenarios with Topmost window occlusions.
Fixed an issue that caused Teams media optimizations for Azure Virtual Desktop
to not load for the ARM64 version of the client.

Download: Windows 64-bit , Windows 32-bit , Windows ARM64
Fixed a bug where refreshes increased memory usage.

Bug fix for Background Effects persistence between Teams sessions.
Updates to MMR for Azure Virtual Desktop, including the following:
Various bug fixes for multimedia redirection (MMR) video playback redirection.
Multimedia redirection for Azure Virtual Desktop is now generally available.
） Important
This is the final version of the Remote Desktop client with Windows 7 support. After
this version, if you try to use the Remote Desktop client with Windows 7, it may not
work as expected. For more information about which versions of Windows the
Remote Desktop client currently supports, see Prerequisites.

Fixed an issue where the app sometimes entered an infinite loop while
disconnecting.
Fixed an issue that caused the incorrect rendering of an incoming screen share
when using an ultrawide (21:9) monitor.

Date published: November 30, 2022
Added User Datagram Protocol support to the client's ARM64 platform.

Fixed an issue where the tooltip didn't disappear when the user moved the mouse
cursor away from the tooltip area.
Fixed an issue where the application crashes when calling reset manually from the
command line.
Fixed an issue where the client stops responding when disconnecting, which
prevents the user from launching another connection.
Fixed an issue where the client stops responding when coming out of sleep mode.

In this release, we've made the following change:
Fixed a bug related to tracing that was blocking reconnections.

Fixed a bug that affected users of some third-party plugins.

Fixed an issue that caused unexpected disconnects in certain RemoteApp

scenarios.

Added banner warning users running client on Windows 7 that support for
Windows 7 will end starting January 10, 2023.
Added page to installer warning users running client on Windows 7 that support
for Windows 7 will end starting January 10, 2023.
Updates to multimedia redirection (MMR) for Azure Virtual Desktop, including the
following:
MMR now works on remote app browser and supports up to 30 sites. For more
information, see Understanding multimedia redirection for Azure Virtual
Desktop.
MMR introduces better diagnostic tools with the new status icon and one-click
Tracelog. For more information, see Multimedia redirection for Azure Virtual
Desktop.

Date published: September 20, 2022
Accessibility improvements through increased color contrast in the virtual desktop

connection blue bar.
Updated connection information dialog to distinguish between Websocket
(renamed from TCP), RDP Shortpath for managed networks, and RDP Shortpath for
public networks.
Fixed bugs.
Fixed an issue that caused calls to disconnect when using a microphone with a
high sample rate (192 kbps).
Resolved a connectivity issue with older RDP stacks.

Reverted to version 1.2.3401 build to avoid a connectivity issue with older RDP
stacks.

Date published: August 2, 2022
Fixed an issue where the narrator was announcing the Tenant Expander button as
"on" or "off" instead of "expanded" or “collapsed."
Fixed an issue where the text size didn't change when the user adjusted the text
size system setting.

Fixed the vulnerability known as CVE-2022-30221 .


Fixed an issue where the service couldn't render RemoteApp windows while
RemoteFX Advanced Graphics were disabled.
Fixed an issue that happened when a user tried to connect to an Azure Virtual
Desktop endpoint while using the Remote Desktop Services Transport Layer
Security protocol (RDSTLS) with CredSSP disabled, which caused the Windows
Desktop client to not prompt the user for credentials. Because the client couldn't
authenticate, it would get stuck in an infinite loop of failed connection attempts.
Fixed an issue that happened when users tried to connect to an Azure Active
Directory (Azure AD)-joined Azure Virtual Desktop endpoint from a client machine
joined to the same Azure AD tenant while the Credential Security Support Provider
protocol (CredSSP) was disabled.
Better noise suppression during calls.
A diagnostic overlay now appears when you press Shift+Ctrl+Semicolon (;)
during calls. The diagnostic overlay only works with version 1.17.2205.23001 or
later of the Remote Desktop WebRTC Redirector Service. You can download the
latest version of the service here .

Reduced flicker when application is restored to full-screen mode from minimized

state in single-monitor configuration.
The client now shows an error message when the user tries to open a connection
from the UI, but the connection doesn't launch.
The new hardware encoding feature increases the video quality (resolution and
framerate) of the outgoing camera during Teams calls. Because this feature uses
the underlying hardware on the PC and not just software, we're being extra
careful to ensure broad compatibility before turning the feature on by default
for all users. Therefore, this feature is currently off by default. To get an early
preview of the feature, you can enable it on your local machine by creating a
registry key at
Computer\HKEY_CURRENT_USER\SOFTWARE\Microsoft\Terminal Server
Client\Default\AddIns\WebRTC Redirector\(DWORD)UseHardwareEncoding
and setting it to 1. To disable the feature, set the key to 0.

Date published: May 10, 2022

Fixed an issue where the Class Identifier (CLSID)-based registration of the dynamic
virtual channel (DVC) plug-in wasn't working.

Improved Narrator application experience.

Accessibility improvements.
Fixed a regression that prevented subsequent connections after reconnecting to an
existing session with the group policy object (GPO) "User
Configuration\Administrative Templates\System\Ctrl+Alt+Del Options\Remove
Lock Computer" enabled.
Added an error message for when a user selects a credential type for smart card or
Windows Hello for Business but the required smart card redirection is disabled in
the RDP file.
Improved diagnostic for User Data Protocol (UDP)-based Remote Desktop Protocol
(RDP) transport protocols.
Updates to Teams for Azure Virtual Desktop, including updating the WebRTC stack
from version M88 to M98. M98 provides better reliability and performances when
making audio and video calls.

Fixed an issue where Narrator didn't announce grid or list views correctly.
Fixed an issue where the msrdc.exe process might take a long time to exit after
closing the last Azure Virtual Desktop connection if customers have set a very short
token expiration policy.
Updated the error message that appears when users are unable to subscribe to
their feed.
Updated the disconnect dialog boxes that appear when the user locks their remote
session or puts their local computer in sleep mode to be only informational.
Multimedia redirection for Azure Virtual Desktop now has an update that gives it
more site and media control compatibility.
Improved connection reliability for Teams on Azure Virtual Desktop.

Fixed an issue where the number pad didn't work on initial focus.


Fixed an issue where background updates could close active remote connections.

The Desktop client now supports Ctrl+Alt+arrow key keyboard shortcuts during
desktop sessions.
Improved graphics performance with certain mouse types.
Fixed an issue that caused the client to randomly crash when something ends a
RemoteApp connection.
The background blur feature is rolling out this week for Windows endpoints.
Fixed an issue that caused the screen to turn black during Teams video calls.

Improved stability of Azure Active Directory authentication.

Fixed an issue that was preventing users from opening multiple .RDP files from
different host pools.

Fixed an issue that caused a redirected camera to give incorrect error codes when
camera access was restricted in the Privacy settings on the client device. This
update should give accurate error messages in apps using the redirected camera.
Fixed an issue where the Azure Active Directory credential prompt appeared in the
wrong monitor.
Fixed an issue where the background refresh and update tasks were repeatedly
registered with the task scheduler, which caused the background and update task
times to change without user input.
In September 2021 we released a preview of our GPU render path optimizations
but defaulted them off. After extensive testing, we've now enabled them by
default. These GPU render path optimizations reduce endpoint-to-endpoint
latency and solve some performance issues. You can manually disable these
optimizations by setting the registry key HKEY_CURRENT_USER
\SOFTWARE\Microsoft\Terminal Server Client\IsSwapChainRenderingEnabled
to 00000000.



Fixed an issue where some users were unable to subscribe using the subscribe
with URL option after updating to version 1.2.2687.0.

Improved manual refresh functionality to acquire new user tokens, which ensures
the service can accurately update user access to resources.
Fixed an issue where the service sometimes pasted empty frames when a user tried
to copy an image from a remotely running Internet Explorer browser to a locally
running Word document.
Fixed a usability issue where the Windows Desktop client would sometimes
prompt for a password (Azure Active Directory prompt) after the device went into
sleep mode.
Fixed an issue where the client didn't automatically expand and display interactive
sign-in messages set by admins when a user signs in to their virtual machine.
Fixed a reliability issue that appeared in version 1.2.2686 where the client stopped
responding when users tried to launch new connections.
The notification volume level on the client device is now the same as the host
device.
Fixed an issue where the device volume was low in Azure Virtual Desktop
sessions
Fixed a multi-monitor screen sharing issue where screen sharing didn't appear
correctly when moving from one monitor to the other.
Resolved a black screen issue that caused screen sharing to incorrectly show a
black screen sometimes.
Increased the reliability of the camera stack when resizing the Teams app or
turning the camera on or off.
Fixed a memory leak that caused issues like high memory usage or video
freezing when reconnecting with Azure Virtual Desktop.
Fixed an issue that caused Remote Desktop connections to stop responding.


Fixed an issue where the service sometimes pasted empty frames when a user tried
to copy an image from a remotely running Internet Explorer browser to a locally
running Word document.

Updates to Teams for Azure Virtual Desktop, including improvements to camera

performance during video calls.


Fixed an issue that caused the client to prompt for credentials a second time after
closing a credential prompt window while subscribing.
Fixed an issue in that made the video screen turn black and crash during calls in
the Chrome browser.
Reduced E2E latency and some performance issues by optimizing the GPU
render path in the Windows Desktop client. To enable the new render path, add
the registry key HKEY_CURRENT_USER \SOFTWARE\Microsoft\Terminal Server
Client\IsSwapChainRenderingEnabled and set its value to 00000001. To disable
the new render path and revert to the original path, either set the key's value to
00000000 or delete the key.


Added updates to Teams on Azure Virtual Desktop, including:
Fixed an issue that caused the screen to turn black when Direct X wasn't
available for hardware decoding.
Fixed a software decoding and camera preview issue that happened when
falling back to software decode.
Multimedia redirection for Azure Virtual Desktop is now in public preview.

Fixed the security vulnerability known as CVE-2021-34535 .

The client also updates in the background when the auto-update feature is
enabled, no remote connection is active, and MSRDCW.exe isn't running.
Fixed an ICE inversion parameter issue that prevented some Teams calls from
connecting.

Windows Virtual Desktop has been renamed to Azure Virtual Desktop. Learn more
about the name change at our announcement on our blog .
Fixed an issue where the client would ask for authentication after the user ended
their session and closed the window.
Fixed an issue with Logitech C270 cameras where Teams only showed a black
screen in the camera settings and while sharing images during calls.


Updates to Teams on Azure Virtual Desktop, including the following:
Resolved a black screen video issue that also fixed a mismatch in video
resolutions with Teams Server.
Teams on Azure Virtual Desktop now changes resolution and bitrate in
accordance with what Teams Server expects.


Fixed an issue that caused the client to crash when users selected "Disconnect all
sessions" in the system tray.
Fixed an issue where the client wouldn't switch to full screen on a single monitor
with a docking station.
Updates to Teams on Azure Virtual Desktop, including the following:
Added hardware acceleration for video processing outgoing video streams for
Windows 10-based clients.
When joining a meeting with both a front-facing and rear-facing or external
camera, the front-facing camera will be selected by default.
Fixed an issue that made Teams on Azure Virtual Desktop crash while loading
on x86-based machines.
Fixed an issue that caused striations during screen sharing.
Fixed an issue that prevented some people in meetings from seeing incoming
video or screen sharing.


Updated background installation functionality to perform silently for the client
auto-update feature.
Fixed an issue where the client forwarded multiple attempts to launch a desktop to
the same session. Depending on your group policy configuration, the session host
can now allow the creation of multiple sessions for the same user on the same
session host or disconnect the previous connection by default. This behavior
wasn't consistent before version 1.2.1755.
Updates for Teams on Azure Virtual Desktop, including the following:
We've offloaded video processing (XVP) to reduce CPU utilization by 5-10%
(depending on CPU generation). Combined with the hardware decode feature
from February's update, we've now reduced the total CPU utilization by 10-20%
(depending on CPU generation).
We've added XVP and hardware decode, which allows older machines to display
more incoming video streams smoothly in 2x2 mode.
We've also updated the WebRTC stack from version M74 to M88. M88 has
better reliability, AV sync performance, and fewer transient issues.
We've replaced our software H264 encoder with OpenH264. OpenH264 is an
open-source codec that increases video quality of the outgoing camera stream.
The client now has simultaneous shipping with 2x2 mode. 2x2 mode shows up
to four incoming video streams simultaneously.

Added the Experience Monitor access point to the system tray icon.
Fixed an issue where entering an email address into the "Subscribe to a
Workplace" tab caused the application to stop responding.
Fixed an issue where the client sometimes didn't send Event Hubs and Diagnostics
events.
Updates to Teams on Azure Virtual Desktop, including:
Improved audio and video sync performance and added hardware accelerated
decode that decreases CPU utilization on the client.
Addressed the most prevalent causes of black screen issues when a user joins a
call or meeting with their video turned on, when a user performs screen sharing,
and when a user toggles their camera on and off.
Improved quality of active speaker switching in single video view by reducing
the time it takes for the video to appear and reducing intermittent black screens
when switching video streams to another user.
Fixed an issue where hardware devices with special characters would sometimes
not be available in Teams.

Added support for the screen capture protection feature for Windows 10
endpoints. To learn more, see Session host security best practices.
Added support for proxies that require authentication for feed subscription.
The client now shows a notification with an option to retry if an update didn't
successfully download.
Addressed some accessibility issues with keyboard focus and high-contrast mode.

Added List view for remote resources so that longer app names are readable.
Added a notification icon that appears when an update for the client is available.

Added the auto-update feature, which allows the client to install the latest updates
automatically.
The client now distinguishes between different feeds in the Connection Center.
Fixed an issue where the subscription account doesn't match the account the user
signed in with.
Fixed an issue where some users couldn't access remote apps through a
downloaded file.
Fixed an issue with Smartcard redirection.
Fixed an issue where single sign-on (SSO) didn't work on Windows 7.

Fixed the connection failure that happened when calling or joining a Teams call
while another app has an audio stream opened in exclusive mode and when media
optimization for Teams is enabled.
Fixed a failure to enumerate audio or video devices in Teams when media
optimization for Teams is enabled.
Added a "Need help with settings?" link to the desktop settings page.
Fixed an issue with the "Subscribe" button that happened when using high-
contrast dark themes.

Added functionality to auto-detect sovereign clouds from the user’s identity.

Added functionality to enable custom URL subscriptions for all users.
Fixed an issue with app pinning on the feed taskbar.
Fixed a crash when subscribing with URL.
Improved experience when dragging remote app windows with touch or pen.
Fixed an issue with localization.

You can now be subscribed to Workspaces with multiple user accounts, using the
overflow menu (...) option on the command bar at the top of the client. To
differentiate Workspaces, the Workspace titles now include the username, as do all
app shortcuts titles.
Added additional information to subscription error messages to improve
troubleshooting.
The collapsed/expanded state of Workspaces is now preserved during a refresh.
Added a Send Diagnostics and Close button to the Connection information
dialog.
Fixed an issue with the CTRL + SHIFT keys in remote sessions.

Updated the automatic discovery logic for the Subscribe option to support the
Azure Resource Manager-integrated version of Azure Virtual Desktop. Customers
with only Azure Virtual Desktop resources should no longer need to provide
consent for Azure Virtual Desktop (classic).
Improved support for high-DPI devices with scale factor up to 400%.
Fixed an issue where the disconnect dialog didn't appear.
Fixed an issue where command bar tooltips would remain visible longer than
expected.
Fixed a crash when you tried to subscribe immediately after a refresh.
Fixed a crash from incorrect parsing of date and time in some languages.

When subscribing, you can now choose your account instead of typing your email
address.
Added a new Subscribe with URL option that allows you to specify the URL of the
Workspace you are subscribing to or leverage email discovery when available in
cases where we can't automatically find your resources. This is similar to the
subscription process in the other Remote Desktop clients. This can be used to
subscribe directly to Azure Virtual Desktop workspaces.
Added support to subscribe to a Workspace using a new URI scheme that can be
sent in an email to users or added to a support website.
Added a new Connection information dialog that provides client, network, and
server details for desktop and app sessions. You can access the dialog from the
connection bar in full screen mode or from the System menu when windowed.
Desktop sessions launched in windowed mode now always maximize instead of
going full screen when maximizing the window. Use the Full screen option from
the system menu to enter full screen.
The Unsubscribe prompt now displays a warning icon and shows the workspace
names as a bulleted list.
Added the details section to additional error dialogs to help diagnose issues.
Added a timestamp to the details section of error dialogs.
Fixed an issue where the RDP file setting desktop size ID didn't work properly.
Fixed an issue where the Update the resolution on resize display setting didn't
apply after launching the session.
Fixed localization issues in the desktop settings panel.
Fixed the size of the focus box when tabbing through controls on the desktop
settings panel.
Fixed an issue causing the resource names to be difficult to read in high contrast
mode.
Fixed an issue causing the update notification in the action center to be shown
more than once a day.

Date published: April 28, 2020
Added new display settings options for desktop connections available when right-
clicking a desktop icon on the Connection Center.
There are now three display configuration options: All displays, Single display
and Select displays.
We now only show available settings when a display configuration is selected.
In Select display mode, a new Maximize to current displays option allows you
to dynamically change the displays used for the session without reconnecting.
When enabled, maximizing the session causes it to go full screen on all displays
touched by the session window.
We've added a new Single display when windowed option for all displays and
select displays modes. This option switches your session automatically to a
single display when you exit full screen mode, and automatically returns to
multiple displays when you maximize the window.
We've added a new Display settings group to the system menu that appears when
you right-click the title bar of a windowed desktop session. This will let you change
some settings dynamically during a session. For example, you can change the new
Single display mode when windowed and Maximize to current displays settings.
When you exit full screen, the session window will return to its original location
when you first entered full screen.
The background refresh for Workspaces has been changed to every four hours
instead of every hour. A refresh now happens automatically when launching the
client.
Resetting your user data from the About page now redirects to the Connection
Center when completed instead of closing the client.
The items in the system menu for desktop connections were reordered and the
Help topic now points to the client documentation.
Addressed some accessibility issues with tab navigation and screen readers.
Fixed an issue where the Azure Active Directory authentication dialog appeared
behind the session window.
Fixed a flickering and shrinking issue when dragging a desktop session window
between displays of different scale factors.
Fixed an error that occurred when redirecting cameras.
Fixed multiple crashes to improve reliability.

Renamed the "Update" action for Workspaces to "Refresh" for consistency with
other Remote Desktop clients.
You can now refresh a Workspace directly from its context menu.
Manually refreshing a Workspace now ensures all local content is updated.
You can now reset the client's user data from the About page without needing to
uninstall the app.
You can also reset the client's user data using msrdcw.exe /reset with an optional /f
parameter to skip the prompt.
We now automatically look for a client update when navigating to the About page.
Updated the color of the buttons for consistency.

Connections to Azure Virtual Desktop are now blocked if the RDP file is missing
the signature or one of the signscope properties has been modified.
When a Workspace is empty or has been removed, the Connection Center no
longer appears to be empty.
Added the activity ID and error code on disconnect messages to improve
troubleshooting. You can copy the dialog message with Ctrl+C.
Fixed an issue that caused the desktop connection settings to not detect displays.
Client updates no longer automatically restart the PC.
Windowless icons should no longer appear on the taskbar.

You can now select which displays to use for desktop connections. To change this
setting, right-click the icon of the desktop connection and select Settings.
Fixed an issue where the connection settings didn't display the correct available
scale factors.
Fixed an issue where Narrator couldn't read the dialogue shown while the
connection initiated.
Fixed an issue where the wrong user name displayed when the Azure Active
Directory and Active Directory names didn't match.
Fixed an issue that made the client stop responding when initiating a connection
while not connected to a network.
Fixed an issue that caused the client to stop responding when attaching a headset.

You can now access information about updates directly from the more options
button on the command bar at the top of the client.
You can now report feedback from the command bar of the client.
The Feedback option is now only shown if the Feedback Hub is available.
Ensured the update notification is not shown when notifications are disabled
through policy.
Fixed an issue that prevented some RDP files from launching.
Fixed a crash on startup of the client caused by corruption of some persistent
settings.
The 32-bit and ARM64 versions of the client are now available!
The client now saves any changes you make to the connection bar (such as its
position, size, and pinned state) and applies those changes across sessions.
Updated gateway information and connection status dialogs.
Addressed an issue that caused two credentials to prompt at the same time while
trying to connect after the Azure Active Directory token expired.
On Windows 7, users are now properly prompted for credentials if they had saved
credentials when the server disallows it.
The Azure Active Directory prompt now appears in front of the connection window
when reconnecting.
Items pinned to the taskbar are now updated during a feed refresh.
Improved scrolling on the Connection Center when using touch.
Removed the empty line from the resolution drop-down menu.
Removed unnecessary entries in Windows Credential Manager.
Desktop sessions are now properly sized when exiting full screen.
The RemoteApp disconnection dialog now appears in the foreground when you
resume your session after entering sleep mode.
Addressed accessibility issues like keyboard navigation.

Improved the fallback languages for localized version. (For example, FR-CA will
properly display in French instead of English.)
When removing a subscription, the client now properly removes the saved
credentials from Credential Manager.
The client update process is now unattended once started and the client will
relaunch once completed.
The client can now be used on Windows 10 in S mode.
Fixed an issue that caused the update process to fail for users with a space in their
username.
Fixed a crash that happened when authenticating during a connection.
Fixed a crash that happened when closing the client.
 Documentation
Use features of the Remote Desktop client for Windows - Azure Virtual Desktop
Learn how to use features of the Remote Desktop client for Windows when connecting to Azure
Virtual Desktop.
Remote Desktop clients for Azure Virtual Desktop - Azure Virtual Desktop
Overview of the Remote Desktop clients you can use to connect to Azure Virtual Desktop.
Connect to Azure Virtual Desktop with the Remote Desktop Microsoft Store client -
Azure Virtual Desktop
Learn how to connect to Azure Virtual Desktop using the Remote Desktop Microsoft Store client.
Connect to Azure Virtual Desktop with the Remote Desktop client for iOS and iPadOS
- Azure Virtual Desktop
Learn how to connect to Azure Virtual Desktop using the Remote Desktop client for iOS and iPadOS.
Use features of the Remote Desktop Web client - Azure Virtual Desktop
Learn how to use features of the Remote Desktop Web client when connecting to Azure Virtual
Desktop.
Connect to Azure Virtual Desktop with the Remote Desktop Web client - Azure
Learn how to connect to Azure Virtual Desktop using the Remote Desktop web client.
Configure device redirection - Azure

How to configure device redirection for Azure Virtual Desktop.
Compare the features of the Remote Desktop clients for Azure Virtual Desktop -
Compare the features of the Remote Desktop clients when connecting to Azure Virtual Desktop.
Show 5 more
What's new in the Remote Desktop Web
client for Azure Virtual Desktop
We regularly update the Remote Desktop Web client for Azure Virtual Desktop, adding
new features and fixing issues. Here's where you'll find the latest updates.
You can find more detailed information about the Windows Desktop client at Connect to
Azure Virtual Desktop with the Remote Desktop Web client and Use features of the
Remote Desktop Web client when connecting to Azure Virtual Desktop.
７ Note
What's new information used to be combined for the Remote Desktop Web client
for Azure Virtual Desktop and Remote Desktop Services. You can find information
for versions earlier than 2.0.0.4 at What's new in the web client.
Updates for version 2.0.0.4 (preview)

Date published: January 26th 2023
A new user interface is available in preview, which has the following new functionality:
An updated design.
Switch between grid view and list view.
Switch between light mode and dark mode.
Reset user settings.
For more information and how to try the new user interface, see Preview user interface.
Next steps
Connect to Azure Virtual Desktop with the Remote Desktop Web client
Use features of the Remote Desktop Web client when connecting to Azure Virtual
Desktop
 Documentation
Connect to Azure Virtual Desktop with thin clients - Azure Virtual Desktop
Learn how to connect to Azure Virtual Desktop using thin clients.
Desktop.
Troubleshoot Multimedia redirection on Azure Virtual Desktop - Azure

Known issues and troubleshooting instructions for multimedia redirection for Azure Virtual Desktop
(preview).
Use features of the Remote Desktop Microsoft Store client - Azure Virtual Desktop
Learn how to use features of the Remote Desktop Microsoft Store client when connecting to Azure
Virtual Desktop.
Use multimedia redirection on Azure Virtual Desktop - Azure

How to use multimedia redirection on Azure Virtual Desktop (preview).
Supported RDP properties with Azure Virtual Desktop - Azure Virtual Desktop
Learn about the supported RDP properties you can use with Azure Virtual Desktop.
Limit the port range when using RDP Shortpath for public networks - Azure Virtual
Desktop
Learn how to limit the port range used by clients when using RDP Shortpath for public networks for
Azure Virtual Desktop, which establishes a UDP-based transport between a Remote Desktop client
and session host.
Show 5 more
client for macOS
macOS. To learn more about using the Remote Desktop client for macOS with Azure
Virtual Desktop, see Connect to Azure Virtual Desktop with the Remote Desktop client
for macOS and Use features of the Remote Desktop client for macOS when connecting
to Azure Virtual Desktop.
Latest client versions

The following table lists the current versions available for the public and beta releases:
Public 10.8.1 Mac App Store
Beta 10.8.1 Microsoft AppCenter
Updates for Version 10.8.1

Bug fixes and feature updates.

Teams redirection for Azure Virtual Desktop now supports Noise Cancellation and
Give/Take Control.
Fixed connection blocking issues that affected a small number of users.
Updated Azure Virtual Desktop diagnostics to address a reporting error.
New clipboard redirection options including bidirectional clipboard syncing, local
to remote, or remote to local.


Fixed a few bugs, cleaned up some underlying code, and made changes to prepare
for future updates.
Added a button to the General Preferences dialog that allows you to clear stored
PC thumbnails.

In this release, we've added some new features to Teams redirection for Azure Virtual
Desktop and Windows 365 scenarios:
Give/Take Control support.

Background blur support.
Background replacement support.
We've also made some additional fixes and performance improvements, including the
following:
We resolved some customer-reported time zone redirection mismatches.

We've improved smart card redirection performance.
We addressed overactive Azure Virtual Desktop diagnostics reporting.
We fixed a crash that happened when users moved hidden windows in RemoteApp
scenarios.

Date Published: August 11, 2022
In this release, we fixed some customer-reported bugs and issues reported by telemetry.
Two of the impacted feature areas include Teams redirection and multi-monitor support.

Date Published: July 25, 2022
Added thumbnail snapshots for published PC resources to the Workspaces tab of

the Connection Center.
Integrated logging support that you could previously only access with user
defaults to the UI. To access the logs, go to Help > Troubleshooting > Logging.
You can now reset all subscribed Azure Virtual Desktop workspaces.
Fixed a deadlock in the client logging infrastructure.
Improved diagnostic error reporting for Azure Active Directory authentication
failures in Azure Virtual Desktop scenarios.

Date Published: Jun 23, 2022
In this release we added the following new features:
A custom app switcher which spans multiple sessions for RemoteApp scenarios
(triggered by the Option+Tab keyboard combination).
Support for the in-session redirection of PIV smart cards (such as Yubikey).
We've also:
Added support for audio and video stream optimizations when connecting to
Azure Virtual Desktop session hosts that support Teams redirection. Learn more at
Use Microsoft Teams on Azure Virtual Desktop.
Made updates to improve connectivity, performance and diagnostic metrics when
connecting to Azure Virtual Desktop deployments.
With respect to bugs and smaller features, the following list summarizes some
highlights:
Added support for eTags in Azure Virtual Desktop workspace refresh scenarios to
improve sync times.
The read-only column in the folder redirection selection UI has been resized to
show the full column header.
Fixed an issue that resulted in the Outlook client showing the incorrect time or
time zone for certain calendar entries.
Resolved discrepancies with the reporting of device physical width and height
across Retina and non-Retina scenarios.
Updated the client to trigger an auto-reconnect in Azure Virtual Desktop scenarios
when a 0x3 error is generated by the Gateway.
Resolved an issue where the mouse cursor on a high DPI monitor is larger than a
regular monitor.
Updated the client to terminate auto-reconnect if the session window is closed
after waking from sleep.
Addressed an issue where the mapped hotkeys CMD+C , CMD+V , and CMD+F didn't
work in nested sessions.
Hid the "Import from Remote Desktop 8" option if there is no data to import.

Date Published: February 3, 2022
In this release, we made some changes to improve connection reliability for Azure
Virtual Desktop scenarios.

Fixed an issue that caused display configuration to not work properly when using
the client on 2021 MacBook Pro 14" and 16" devices with multiple monitors. This
issue mainly affected devices with external monitors positioned above the
MacBook display.
Fixed an issue that caused the client to crash when used on earlier versions of
macOS 12
Fixed customer-reported smart card and folder redirection issues.

Addressed full screen display issues with 2021 MacBook Pro 14" and 16" models.
Better handle load-balanced Remote Desktop Gateway configurations.

Unfortunately, the 10.7.2 update disabled smart card redirection for some users when
they'd try to reconnect to their sessions. As a result, we've released this update to
address the issue.

Added support for the Touch Bar on MacBook Pro devices.

Refreshed the look and feel of the PCs and Apps tabs in the Connection Center.
Added a new SHIFT+COMMAND+K hotkey that opens the Connection Center.
Improved compatibility with third-party network devices and load balancers for
workspace download and Remote Desktop Gateway-based connections.
Support for the ms-rd URI scheme.
Improved support for invertible mouse cursors that straddle the image boundary.
Support for .RDPW files produced by the Azure Virtual Desktop web client.
Fixed an issue that caused the workspace subfolder to remain expanded even if
you've collapsed the root folder.
Updates and enhancements to Teams redirection (only available in Azure Virtual
Desktop scenarios).
Addressed reliability issues identified through crash reporting and feedback.

Addressed issues brought up by users in crash reports and general feedback.

Invertible cursors, such as the text cursor, are now outlined to make them visible
on dark backgrounds.
Made improvements to the code for the Connection Center for both PCs and
workspaces.
Added support for moving the local window while using RemoteApps.
By default, local window movement in RemoteApp scenarios is disabled. To
enable local window movement, set the EnableRemoteAppLocalMove policy to
True.
Updated the Connection Information prompt that appears when you go to
Connections > Show Connection Information.
Added screen capture protection for Azure Virtual Desktop scenarios.
Addressed an issue that allowed folders to be redirected multiple times.
Added a link to the new support forum at Help > Submit feedback.
Updates improving security, connectivity and performance while connecting to
Addressed three connectivity errors that users reported to us:
Worked around a 0x907 (mismatched certificate) error code that was caused by
third-party infrastructure returning an incorrect certificate in redirection
scenarios.
Fixed the root cause of a 0x207 (handshake failure) error code that appeared
when users accidentally tried to connect with an incorrect password to a pre-
Windows 8 server with Network Level Authentication (NLA) enabled.
Resolved a 0x1107 (invalid workstation) error code that appeared when Active
Directory workstation logon restrictions were set.
Updated the default icon for published desktops and worked around an issue that
caused smart card redirection to stop working with recently patched versions of
Windows.
Made some updates to improve compatibility and performance metrics when


Enabled connections to Windows Server 2003 servers that have Transport Layer
Security (TLS) enabled for Remote Desktop connections.
Addressed a 0x3000066 error message that appeared in Remote Desktop Gateway
scenarios, and aligned TLS version usage with the Windows Remote Desktop client.


Fixed an issue that made the client return a 0x907 error code when connecting to a
server endpoint with a certificate that had a Remote Desktop Authentication EKU
property of 1.3.6.1.4.1.311.54.1.2 .
Updated the client to address a 0x2407 error code that prevented the client from
authorizing users for remote access.

Fixed an issue that caused the client to return a 0x907 error code when processing
a server authentication certificate with a validity lifetime of over 825 days.

Fixed an issue that caused the client to return a 0x507 error code.
Enabled support for the AVC420 codec on Apple Silicon.
Enabled Smart card redirection (requires macOS 11.2 or later) on Apple Silicon.

Removed a double prompt for credentials that occurred in some scenarios when
users tried to connect with a Remote Desktop Gateway.

In this update, we fixed an issue that caused the client to stop responding when
connecting to a Remote Desktop Gateway.
In this release we've made some significant updates to the shared underlying code that
powers the Remote Desktop experience across all our clients. We've also added some
new features and addressed bugs and crashes that were showing up in error reports.
Added native support for Apple Silicon.

Added client-side IME support when using Unicode keyboard mode.
Integrated Kerberos support in the CredSSP security protocol sequence.
Addressed macOS 11 compatibility issues.
Made updates to improve interoperability with current and upcoming features in
the Azure Virtual Desktop service.
Fixed issues that caused mis-paints when decoding AVC data generated by a
server-side hardware encoder.
Addressed an issue that made remote Office app windows invisible even though
they appeared in the app switcher.
） Important
As of this update, the macOS client requires macOS version 10.14 or later to run.

Added HTTP proxy support for Remote Desktop Gateway connections.

Fixed an issue where a Remote Desktop Gateway connection would disconnect and
a message with error code 0x3000064 would appear.
Addressed a bug where workspace discovery and download wouldn't work if you
included the port number in HTTP GET requests.
Refreshed the application icon
７ Note
This release is the last release that will be compatible with macOS version 10.13.
Addressed an issue where the UI would stop resolving a workspace name during
subscription.
Fixed an in-session bug where graphics updates would stall while the client
continued to send input.
Resolved reliability issues identified through crash reporting.

You can now edit the display, device, and folder redirection settings of published
PC connections.
Remote app windows now shrink to the dock when minimized.
Added a Connection Information dialog that displays the current bandwidth and
round-trip time.
Added support for Remote Desktop Gateway consent and admin messages.
Fixed an issue where an RDP file specifying a gatewayusagemethod value of 0 or 4
was incorrectly imported.
The Edit Workspace sheet now shows the exact time at which the workspace was
last updated.
Removed trace spew that was output when using the --script parameter.
Addressed an issue where the client would return a 0x30000066 error when
connecting using a Remote Desktop Gateway server.
Fixed an issue that caused the client to repeatedly prompt users for credentials if
Extended Protection for Authentication was set on the server.
Addressed reliability issues that users identified through crash reporting.
Addressed keyboard and VoiceOver-related accessibility bugs.


Addressed several reliability issues identified through crash reporting.
Addressed keyboard and VoiceOver-related accessibility bugs.
Fixed an issue where the client would hang on reconnect when resuming from
sleep.
Fixed an audio artifact heard when playing back the first chunk of a redirected
audio stream.
Addressed an issue where the client would report a 0x5000007 error message
when connecting using a Remote Desktop Gateway server.
Corrected the aspect ratio of PC thumbnails displayed in the Connection Center.
Improved smart card redirection heuristics to better handle nested transactions.
Fixed a bug that prevented bookmark export if the bookmark's display name
contained the "/" character.
Resolved a bug that caused a 0xD06 protocol error when running Outlook as a
remote app.
Added support for a new integer RDP file property (ForceHiDpiOptimizations) to
enable Retina display optimization.

In this release, we've made substantial updates to the underlying code for the Remote
Desktop experience across all our clients. We've also added some new features and
addressed bugs and crashes that were showing up in error reporting. Here are some
changes you may notice:
PC Quick Connect (Cmd+K) allows you to connect to a PC without creating a

bookmark.
Auto-reconnect now recovers from transient network glitches for PC connections.
When resuming a suspended MacBook, you can use auto-reconnect to reconnect
to any disconnected PC connections.
Added support for HTTP proxies when subscribing and connecting to Azure Virtual
Desktop resources.
Implemented support for HTTP proxy automatic configuration with PAC files.
Integrated support for NETBIOS name resolution so you can connect to PCs on
your local network more easily.
Fixed an issue where the system menu bar wouldn't respond while the app was in
focus.
Fixed a client-side race condition that could cause decryption errors on the server.
Made improvements to monitor layout and geometry heuristics for multimon
scenarios involving Retina-class monitors.
Multimon layout configurations are now maintained across session redirection
scenarios.
Addressed an issue that prevented the menu bar from dropping in multimon
scenarios.
User account UI that interacts with the macOS keychain will now surface keychain
access errors.
Hitting cancel during workspace subscription will now result in nothing being
added to the Connection Center.
Added key mappings for Cmd+Z and Cmd+F to map to Ctrl+Z and Ctrl+F
respectively.
Fixed a bug that caused remote apps to open behind the Connection Center when
launched.
Worked around an issue in macOS 10.15 where AAC audio playback caused the
client to stall.
Shift+left-click now works in Unicode mode.
Fixed a bug where using the Shift key triggered the Sticky Keys alert in Unicode
mode.
Added a check for network availability before connection initiation.
Addressed pulsing of PC thumbnails that sometimes happened during the
connection sequence.
Fixed a bug where the password field in the Add/Edit User Account sheet become
multiline.
The "Collapse All" option is now greyed out if all workspaces are collapsed.
The "Expand All" option is now greyed out if all workspaces are expanded.
The first-run permissions UI is no longer shown on High Sierra.
Fixed an issue where users were unable to connect to Azure Virtual Desktop
endpoints using saved credentials in the DOMAIN\USERNAME format.
The username field in the credential prompt is now always prepopulated for Azure
Virtual Desktop connections.
Fixed a bug that clipped the Edit, Delete, and Refresh buttons for workspaces if the
Connection Center wasn't wide enough.
The "email or workspace URL" field in the Add Workspace sheet is no longer case-
sensitive.
Fixed accessibility issues that impacted VoiceOver and keyboard navigation
scenarios.
Lots of updates to improve interoperability with current and upcoming features in
You can now configure the AVC support level advertised by the client from a
terminal prompt. Here are the support levels you can configure:
Don't advertise AVC support to the server: defaults write
com.microsoft.rdc.macos AvcSupportLevel disabled
Advertise AVC420 support to the server: defaults write
com.microsoft.rdc.macos AvcSupportLevel avc420
Advertise support for AVC444 support to the server: defaults write
com.microsoft.rdc.macos AvcSupportLevel avc444

In this release, we've made some changes to improve interoperability with the Azure
Virtual Desktop service . In addition, we've included the following updates:
Control+Option+Delete now triggers the Ctrl+Alt+Del sequence (previously

required pressing the Fn key).
Fixed the keyboard mode notification color scheme for Light mode.
Addressed scenarios where connections initiated using the GatewayAccessToken
RDP file property didn't work.
７ Note
This is the last release that will be compatible with macOS 10.12.

With this update, you can switch between Scancode (Ctrl+Command+K) and Unicode
(Ctrl+Command+U) modes when entering keyboard input. Unicode mode allows
extended characters to be typed using the Option key on a Mac keyboard. For example,
on a US Mac keyboard, Option+2 will enter the trademark (™) symbol. You can also
enter accented characters in Unicode mode. For example, on a US Mac keyboard,
entering Option+E and the "A" key at the same time will enter the character "á" on your
remote session.
Other updates in this release include:
Cleaned up the workspace refresh experience and UI.

Addressed a smart card redirection issue that caused the remote session to stop
responding at the sign-in screen when the "Checking Status" message appeared.
Reduced time to create temporary files used for clipboard-based file copy and
paste.
Temporary files used for clipboard file copy and paste are now deleted
automatically when you exit the app, instead of relying on macOS to delete them.
PC bookmark actions are now rendered at the top-right corner of thumbnails.
Made fixes to address issues reported through crash telemetry.

Copying things from the remote session to a network share or USB drive no longer
creates empty files.
Specifying an empty password in a user account no longer causes a double
certificate prompt.

Addressed an issue that created zero-length files whenever you copied a folder
from the remote session to the local machine using file copy and paste.

Redirected folders can now be marked as read-only to prevent their contents from
being changed in the remote session.
We addressed a 0x607 error that appeared when connecting using RPC over
HTTPS Remote Desktop Gateway scenarios.
Fixed cases where users were double-prompted for credentials.
Fixed cases where users received the certificate warning prompt twice.
Added heuristics to improve trackpad-based scrolling.
The client no longer shows the "Saved Desktops" group if there are no user-
created groups.
Updated UI for the tiles in PC view.
Fixes to address crashes sent to us via application telemetry.

When connecting via a Remote Desktop Gateway with multi-factor authentication,

the gateway connection will be held open to avoid multiple MFA prompts.
All the client UI is now fully keyboard-accessible with Voiceover support.
Files copied to the clipboard in the remote session are now only transferred when
pasting to the local computer.
URLs copied to the clipboard in the remote session now paste correctly to the local
computer.
Scale factor remoting to support Retina displays is now available for multimonitor
scenarios.
Addressed a compatibility issue with FreeRDP-based RD servers that was causing
connectivity issues in redirection scenarios.
Addressed smart card redirection compatibility with future releases of Windows 10.
Addressed an issue specific to macOS 10.15 where the incorrect available space
was reported for redirected folders.
Published PC connections are represented with a new icon in the Workspaces tab.
"Feeds" are now called "Workspaces," and "Desktops" are now called "PCs."
Fixed inconsistencies and bugs in user account handling in the preferences UI.
Lots of bug fixes to make things run smoother and more reliably.

Added user defaults to disable smart card, clipboard, microphone, camera, and
folder redirection:
ClientSettings.DisableSmartcardRedirection
ClientSettings.DisableClipboardRedirection
ClientSettings.DisableMicrophoneRedirection
ClientSettings.DisableCameraRedirection
ClientSettings.DisableFolderRedirection
Resolved an issue that was causing programmatic session window resizes to not be
detected.
Fixed an issue where the session window contents appeared small when
connecting in windowed mode (with dynamic display enabled).
Addressed initial flicker that occurred when connecting to a session in windowed

mode with dynamic display enabled.
Fixed graphics mis-paints that occurred when connected to Windows 7 after

toggling fit-to-window with dynamic display enabled.
Fixed a bug that caused an incorrect device name to be sent to the remote session
(breaking licensing in some third-party apps).
Resolved an issue where remote app windows would occupy an entire monitor
when maximized.
Addressed an issue where the access permissions UI appeared underneath local

windows.
Cleaned up some shutdown code to ensure the client closes more reliably.

In this release, we fixed a bug that made the display low resolution while connecting to
a session

Addressed connectivity issues with Remote Desktop Gateway servers that were
using 4096-bit asymmetric keys.
Fixed a bug that caused the client to randomly stop responding when
downloading feed resources.
Fixed a bug that caused the client to crash while opening.
Fixed a bug that caused the client to crash while importing connections from
Remote Desktop, version 8.
Camera redirection is now possible when connecting to Windows 10 1809,

Windows Server 2019 and later.
On Mojave and Catalina we've added a new dialog that requests your permission
to use the microphone and camera for device redirection.
The feed subscription flow has been rewritten to be simpler and faster.
Clipboard redirection now includes the Rich Text Format (RTF).
When entering your password, you can now choose to reveal it by selecting the
"Show password" checkbox.
Addressed scenarios where the session window was jumping between monitors.
The Connection Center displays high-resolution remote app icons (when available).
Cmd+A maps to Ctrl+A when Mac clipboard shortcuts are being used.
Cmd+R now refreshes all of your subscribed feeds.
Added new secondary click options to expand or collapse all groups or feeds in the
Connection Center.
Added a new secondary click option to change the icon size in the Feeds tab of the
Connection Center.
A new, simplified, and clean app icon.

Fixed a hang that occurred when connecting via a Remote Desktop Gateway.
Added a privacy notice to the "Add Feed" dialog.

Resolved random disconnects (with error code 0x904) that took place when
connecting via a Remote Desktop Gateway.
Fixed a bug that caused the resolutions list in application preferences to be empty
after installation.
Fixed a bug that caused the client to crash if certain resolutions were added to the
resolutions list.
Addressed an ADAL authentication prompt loop when connecting to Azure Virtual
Desktop deployments.

Addressed instability caused by the recent macOS 10.14.4 update.

Fixed mis-paints that appeared when decoding AVC codec data encoded by a
server using NVIDIA hardware.

Fixed a Remote Desktop Gateway connectivity issue that can occur when server
redirection takes place.
We also addressed a Remote Desktop Gateway regression caused by the 10.2.8
update.

Resolved connectivity issues that surfaced when using a Remote Desktop Gateway.
Fixed incorrect certificate warnings that were displayed when connecting.
Addressed some cases where the menu bar and dock would needlessly hide when
launching remote apps.
Reworked the clipboard redirection code to address crashes and hangs that have
been plaguing some users.
Fixed a bug that caused the Connection Center to needlessly scroll when launching
a connection.
In this release, we addressed graphics mis-paints (caused by a server encoding bug) that
appeared when using AVC444 mode.

Added support for the AVC (420 and 444) codec, available when connecting to
current versions of Windows 10.
In Fit to Window mode, a window refresh now occurs immediately after a resize to
ensure that content is rendered at the correct interpolation level.
Fixed a layout bug that caused feed headers to overlap for some users.
Cleaned up the Application Preferences UI.
Polished the Add/Edit Desktop UI.
Made lots of fit and finish adjustments to the Connection Center tile and list views
for desktops and feeds.
７ Note
There is a bug in macOS 10.14.0 and 10.14.1 that can cause the
".com.microsoft.rdc.application-data_SUPPORT/_EXTERNAL_DATA" folder (nested
deep inside the ~/Library folder) to consume a large amount of disk space. To
resolve this issue, delete the folder content and upgrade to macOS 10.14.2. Note
that a side-effect of deleting the folder contents is that snapshot images assigned
to bookmarks will be deleted. These images will be regenerated when reconnecting
to the remote PC.

Added dark mode support for macOS Mojave 10.14.

An option to import from Microsoft Remote Desktop 8 now appears in the
Connection Center if it is empty.
Addressed folder redirection compatibility with some third-party enterprise
applications.
Resolved issues where users were getting a 0x30000069 Remote Desktop Gateway
error due to security protocol fallback issues.
Fixed progressive rendering issues some users were experiencing with fit to
window mode.
Fixed a bug that prevented file copy and paste from copying the latest version of a
file.
Improved mouse-based scrolling for small scroll deltas.

Added support for the "remoteapplicationcmdline" RDP file setting for remote app
scenarios.
The title of the session window now includes the name of the RDP file (and server
name) when launched from an RDP file.
Fixed reported Remote Desktop Gateway performance issues.
Fixed reported Remote Desktop Gateway crashes.
Fixed issues where the connection would hang when connecting through a Remote
Desktop Gateway.
Better handling of full-screen remote apps by intelligently hiding the menu bar
and dock.
Fixed scenarios where remote apps remained hidden after being launched.
Addressed slow rendering updates when using "Fit to Window" with hardware
acceleration disabled.
Handled database creation errors caused by incorrect permissions when the client
starts up.
Fixed an issue where the client was consistently crashing at launch and not starting
for some users.
Fixed a scenario where connections were incorrectly imported as full-screen from
Remote Desktop 8.

A brand new Connection Center that supports drag and drop, manual arrangement
of desktops, resizable columns in list view mode, column-based sorting, and
simpler group management.
The Connection Center now remembers the last active pivot (Desktops or Feeds)
when closing the app.
The credential prompting UI and flows have been overhauled.
Remote Desktop Gateway feedback is now part of the connecting status UI.
Settings import from the version 8 client has been improved.
RDP files pointing to RemoteApp endpoints can now be imported into the
Connection Center.
Retina display optimizations for single monitor Remote Desktop scenarios.
Support for specifying the graphics interpolation level (which affects blurriness)
when not using Retina optimizations.
256-color support to enable connectivity to Windows 2000.
Fixed clipping of the right and bottom edges of the screen when connecting to
Windows 7, Windows Server 2008 R2 and earlier.
Copying a local file into Outlook (running in a remote session) now adds the file as
an attachment.
Fixed an issue that was slowing down pasteboard-based file transfers if the files
originated from a network share.
Addressed a bug that was causing to Excel (running in a remote session) to hang
when saving to a file on a redirected folder.
Fixed an issue that was causing no free space to be reported for redirected folders.
Fixed a bug that caused thumbnails to consume too much disk storage on macOS
10.14.
Added support for enforcing Remote Desktop Gateway device redirection policies.
Fixed an issue that prevented session windows from closing when disconnecting
from a connection using Remote Desktop Gateway.
If Network Level Authentication (NLA) is not enforced by the server, you will now
be routed to the sign-in screen if your password has expired.
Fixed performance issues that surfaced when lots of data was being transferred
over the network.
Smart card redirection fixes.
Support for all possible values of the EnableCredSspSupport and Authentication
Level RDP file settings if the ClientSettings.EnforceCredSSPSupport user default
key (in the com.microsoft.rdc.macos domain) is set to 0.
Support for the "Prompt for Credentials on Client" RDP file setting when NLA is not
negotiated.
Support for smart card-based sign-in using smart card redirection at the Winlogon
prompt when NLA is not negotiated.
Fixed an issue that prevented downloading feed resources that have spaces in the
URL.

Enabled connectivity to Azure Active Directory (Azure AD) joined PCs. To connect
to an Azure AD joined PC, your username must be in one of the following formats:
"AzureAD\user" or "AzureAD\user@domain".
Addressed some bugs affecting the usage of smart cards in a remote session.

Incorporated updates for GDPR compliance.

MicrosoftAccount\username@domain is now accepted as a valid username.
Clipboard sharing has been rewritten to be faster and support more formats.
Copy and pasting text, images, or files between sessions now bypasses the local
machine's clipboard.
You can now connect via a Remote Desktop Gateway server with an untrusted
certificate (if you accept the warning prompts).
Metal hardware acceleration is now used (where supported) to speed up rendering
and optimize battery usage.
When using Metal hardware acceleration, we try to work some magic to make the
session graphics appear sharper.
Got rid of some instances where windows would hang around after being closed.
Fixed bugs that were preventing the launch of RemoteApp programs in some
scenarios.
Fixed a Remote Desktop Gateway channel synchronization error that was resulting
in 0x204 errors.
The mouse cursor shape now updates correctly when moving out of a session or
RemoteApp window.
Fixed a folder redirection bug that was causing data loss when copy and pasting
folders.
Fixed a folder redirection issue that caused incorrect reporting of folder sizes.
Fixed a regression that was preventing logging into an Azure AD-joined machine
using a local account.
Fixed bugs that were causing the session window contents to be clipped.
Added support for RD endpoint certificates that contain elliptic-curve asymmetric
keys.
Fixed a bug that was preventing the download of managed resources in some
scenarios.
Addressed a clipping issue with the pinned connection center.
Fixed the checkboxes in the Display tab of the Add a Desktop window to work
better together.
Aspect ratio locking is now disabled when dynamic display change is in effect.
Addressed compatibility issues with F5 infrastructure.
Updated handling of blank passwords to ensure the correct messages are shown
at connect-time.
Fixed mouse scrolling compatibility issues with MapInfra Pro.
Fixed some alignment issues in the Connection Center when running on Mojave.

Added support for changing the remote resolution by resizing the session window!
Fixed scenarios where remote resource feed download would take an excessively
long time.
Resolved the 0x207 error that could occur when connecting to servers not patched
with the CredSSP encryption oracle remediation update (CVE-2018-0886).

Made security fixes to incorporate CredSSP encryption oracle remediation updates

as described in CVE-2018-0886.
Improved RemoteApp icon and mouse cursor rendering to address reported
mispaints.
Addressed issues where RemoteApp windows appeared behind the Connection
Center.
Fixed a problem that occurred when you edit local resources after importing from
Remote Desktop 8.
You can now start a connection by pressing ENTER on a desktop tile.
When you're in full screen view, Cmd+M now correctly maps to WIN+M.
The Connection Center, Preferences, and About windows now respond to Cmd+M.
You can now start discovering feeds by pressing ENTER on the **Adding Remote
Resources*- page.
Fixed an issue where a new remote resources feed showed up empty in the
Connection Center until after you refreshed.

Fixed an issue where RemoteApp windows would reorder themselves.

Resolved a bug that caused some RemoteApp windows to get stuck behind their
parent window.
Addressed a mouse pointer offset issue that affected some RemoteApp programs.
Fixed an issue where starting a new connection gave focus to an existing session,
instead of opening a new session window.
We fixed an error with an error message - you'll see the correct message now if we
can't find your gateway.
The Quit shortcut (⌘ + Q) is now consistently shown in the UI.
Improved the image quality when stretching in "fit to window" mode.
Fixed a regression that caused multiple instances of the home folder to show up in
the remote session.
Updated the default icon for desktop tiles.
client for iOS and iPadOS
In this article you'll learn about the latest updates for the Remote Desktop client for iOS
and iPadOS. To learn more about using the Remote Desktop client for iOS and iPadOS
with Azure Virtual Desktop, see Connect to Azure Virtual Desktop with the Remote
Desktop client for iOS and iPadOS and Use features of the Remote Desktop client for
iOS and iPadOS when connecting to Azure Virtual Desktop.

Public 10.4.6 App Store
Beta 10.4.6 TestFlight

In this release, we've removed the global prompt for camera and microphone access
when you first open and run the iOS client. Instead, whenever a connection bookmark or
published resource requests access, you'll receive a prompt asking whether you want to
give permission.
We also fixed some bugs and added some small additional features:
Integrated privacy statement compliance flows for select geographical regions.

Added functionality to delete all Azure VIrtual Desktop workspaces and associated
keychain items.
Worked around an iOS 16 change that broke Korean language input.
Addressed a bug that stopped the Apple Pencil from working when connected to
Windows 8.1 and Windows Server 2012 R2 and earlier.
７ Note
This release removes support for iOS 14 and is only compatible with iOS 15 and 16.

Fixed a WebSocket transport bug that affected some Azure Virtual Desktop
deployments
Addressed accessibility compliance issues.

In this release, we've made targeted bug fixes and performance improvements, and also
added new features. Here's what we've included:
You can now use Apple Pencil to draw, write, and interact with remote sessions.
You can now see a live preview of the current active session when switching to the
Connection Center from a remote session.
Gather logs for troubleshooting by going to Settings > Troubleshooting.
Review app highlights from previous versions by going to Settings > About >
Version Highlights.
We've made some small appearance changes to the connection bar user interface.
We've fixed issues that affected locking to landscape or portrait on iOS 16.

In this release, we resolved a customer bug that impacted authentication when

connecting to Azure Virtual Desktop deployments.

In this release, we resolved some bugs that impacted Azure Virtual Desktop deployment
connectivity. We also fixed an issue that caused external keyboard input to stop working
when you press Command+Tab to switch out of and return to the app.

In this release, we added thumbnail snapshots for published PC resources to the

Workspaces tab of the Connection Center. We also created an in-app highlights user
interface (UI) to advertise new features. The UI automatically appears when you first turn
your machine on after an update. You can also access it by going to Settings > About >
Version Highlights. Finally, we fixed an issue where the mouse cursor would temporarily
get stuck at the bottom of the screen.
Updates for version 10.4.0 (5155)

This is a significant update with some new feature additions and lots of bug fixes and
improvements.
The biggest change in this release is that you can now dynamically change the
orientation of the remote session to either landscape or portrait mode while connected
to a machine running Windows 8.1, Windows Server 2012 R2 or later. You can set your
orientation preferences in Settings > Display.
To work seamlessly with dynamic orientation, we've made updates to the following
experiences:
The in-session immersive switcher has a revamped look and feel, and can
accommodate both landscape and portrait orientation.
The on-screen keyboard has been redesigned to support portrait orientation.
The connecting UI now supports for both landscape and portrait orientation.
The PC tab of the connection center now supports high-resolution thumbnails and
portrait snapshots.
In addition, we’ve made the following improvements:
Reworked the connection center to apply a consistent set of margins throughout

the UI.
Added the Shift-Command-Space key combo to toggle the visibility of the
connection bar.
Added the Command-Plus sign (+) and Command-Minus sign (-) key combos to
zoom in and out respectively.
Fixed RemoteApp resource launch and reconnect scenarios.
Updated the client to send the correct physical dimensions for the iPad Mini 6.
Added the username to PC bookmark thumbnails.
Updated the in-session connection bar to fade back after three seconds if you
minimize it.
Added support for smooth scrolling in the connection center on ProMotion-
compatible iPhones and iPads.
We've also made some updates to enhance Azure Virtual Desktop scenarios:
Integrated the Microsoft Authentication Library (MSAL) or OneAuth component to

improve current and future authentication scenarios.
Added eTag support to speed up Azure Virtual Desktop workspace refresh.
７ Note
This release removes support for iOS 13 and is only compatible with iOS 14 and 15.
Updates for version 10.3.6 (5090)

In this release we added support for the iPad Mini 6 and addressed an issue with Slide
Over windows and keyboard interaction. Thanks for all the feedback. We're working
hard to make this app great!

In this release, we've added support for time zone redirection. This new feature fixes an
issue in Windows 11 remote sessions that caused the screen to flicker, making the
session unusable.

In this release, we worked around a 0x907 (mismatched certificate) error code that was
caused by third-party infrastructure returning an incorrect certificate in redirection
scenarios. We also made some updates to improve compatibility and performance
metrics when connecting to Azure Virtual Desktop (formerly known as Windows Virtual
Desktop).

Date published: May 27, 2021*
In this release, we've made some significant updates to the shared underlying code that
powers the Remote Desktop experience across all our clients. We've also added some
new features and addressed bugs and crashes that were showing up in error reporting.
You can now drag IME candidate window in the client.

Integrated Kerberos support in the CredSSP security protocol sequence.
Added support for HTTP proxies in Azure Virtual Desktop and on-premises
scenarios.
Made updates to improve interoperability with current and upcoming features in

Date published: 03/29/2021
In this release, we made the following updates:
Fixed NETBIOS name resolution on iOS 14.

Updated the app to proactively request local network access to enable connections
to PCs around you.
Fixed an issue where an RD Gateway connection would fail with a 0x3000064 error
code.
Fixed a bug where workspace discovery and download would fail if the port
number was included in HTTP GET requests.
Added examples of PC host names to the PC Name page in the Add/Edit PC UX.
Addressed some VoiceOver accessibility issues.

In this release, we've made the following changes to the connection bar and in-session
user experience:
You can now collapse the connection bar by moving it into one of the four corners
of the screen.
On iPads and large iPhones you can dock the connection bar to the left or right
edge of the screen.
You can now see the zoom slider panel by pressing and holding the connection
bar magnification button. The new zoom slider controls the magnification level of
the session in both touch and mouse pointer mode.
We also addressed some accessibility bugs and the following two issues:
The client now validates the PC name in the Add/Edit PC UI to make sure the name
doesn't contain illegal characters.
Addressed an issue where the UI would stop resolving a workspace name during
subscription.

In this release, we've fixed issues that caused crashes and interfered with the "Display
Zoom View" setting. We've also tweaked the "Use Full Display" setting to only appear on
applicable iPads and adjusted the available resolutions for iPhones and iPads.

In this release, we've addressed some bugs affecting users running iOS 14 and iPadOS
14.

In this release, we made the following fixes:
Added support for newly released iPhone and iPad devices.

Addressed an issue where the client would return a 0x30000066 error when
connecting using an RD Gateway server.
In this release, we addressed some compatibility issues with iOS and iPadOS 14. In
addition, we made the following fixes and feature updates:
Addressed crashes on iOS and iPadOS 14 that happened when entering input on
keyboard.
Added the Cmd+S and Cmd+N shortcuts to access the "Add Workspace" and "Add
PC" processes, respectively.
Added the Cmd+F shortcut to invoke Search UI in the Connection Center.
Added the "Expand All" and "Collapse All" commands to the Workspaces tab.
Resolved a bug that caused a 0xD06 protocol error to happen while running
Outlook as a remote app.
The on-screen keyboard will now disappear when you scroll through search results
in the Connection Center.
Updated the animation used when hovering over workspace icons with a mouse or
trackpad pointer on iPadOS 14.

We've put together some bug fixes and small feature updates for this release. Here's
what's new:
Addressed an issue where the client would report a 0x5000007 error message
when trying to connect to an RD Gateway server.
User account passwords updated in the credential UI are now saved after
successfully signing in.
Addressed an issue where range and multi-select with the mouse or trackpad
(Shift+click and Ctrl+click) didn't work consistently.
Addressed a bug where apps displayed in the in-session switcher UI were out of
sync with the remote session.
Made some cosmetic changes to the layout of Connection Center workspace
headers.
Improved visibility of the on-screen keyboard buttons for dark backdrops.
Fixed a localization bug in the disconnect dialog.

We've put together some bug fixes and feature updates for this release. Here's what's
new:
The input mode (Mouse Pointer or Touch mode) is now global across all active PC
and remote app connections.
Fixed an issue that prevented microphone redirection from working consistently.
Fixed a bug that caused audio output to play from the iPhone earpiece instead of
the internal speaker.
The client now supports automatically switching audio output between the iPhone
or iPad internal speakers, bluetooth speakers, and AirPods.
Audio now continues to play in the background when switching away from the
client or locking the device.
The input mode automatically switches to Touch mode when using a SwiftPoint
mouse on iPhones or iPads (not running iPadOS, version 13.4 or later).
Addressed graphics output issues that occurred when the server was configured to
use AVC444 full screen mode.
Fixed some VoiceOver bugs.
Panning around a zoomed in session works when using an external mouse or
trackpad now works differently. To pan in a zoomed-in session with an external
mouse or trackpad, select the pan knob, then drag your mouse cursor away while
still holding the mouse button. To pan around in Touch mode, press on the pan
knob, then move your finger. The session will stick to your finger and follow it
around. In Mouse Pointer mode, push the virtual mouse cursor against the sides of
the screen.

Date published 8/17/2020
In this update, we've addressed issues that were reported in this release.
Fixed a crash that occurred for some users when subscribing to an Azure Virtual
Desktop feed using non-brokered authentication.
Fixed the layout of workspace icons on the iPhone X, iPhone XS, and iPhone 11
Pro.

Here’s what we've included in this release:
Fixed a bug that prevented typing in Korean.

Added support for F1 through F12, Home, End, PgUp and PgDn keys on hardware
keyboards.
Resolved a bug that made it difficult to move the mouse cursor to the top of the
screen in letterboxed mode on iPadOS devices.
Addressed an issue where pressing backspace after space deleted two characters.
Fixed a bug that caused the iPadOS mouse cursor to appear on top of the Remote
Desktop client mouse cursor in "Tap to Click" mode.
Resolved an issue that prevented connections to some RD Gateway servers (error
code 0x30000064).
Fixed a bug that caused the mouse cursor to be shown in the in-session switcher
UI on iOS devices when using a SwiftPoint mouse.
Resized the RD client mouse cursor to be consistent with the current client scale
factor.
The client now checks for network connectivity before launching a workspace
resource or PC connection.
Hitting the remapped Escape button or Cmd+. now cancels out of any credential
prompt.
We've added some animations and polish that appear when you move the mouse
cursor around on iPads running iPadOS 13.4 or later.

If you're using iPadOS 13.4 or later, can now control the remote session with a
mouse or trackpad.
The client now supports the following Apple Magic Mouse 2 and Apple Magic
Trackpad 2 gestures: left-click, left-drag, right-click, right-drag, horizontal and
vertical scrolling, and local zooming.
For external mice, the client now supports left-click, left-drag, right-click, right-
drag, middle-click, and vertical scrolling.
The client now supports keyboard shortcuts that use Ctrl, Alt, or Shift keys with the
mouse or trackpad, including multi-select and range-select.
The client now supports the "Tap-to-Click" feature for the trackpad.
We've updated the Mouse Pointer mode's right-click gesture to press-and-hold
(not press-and-hold-and-release). On the iPhone client we've thrown in some
taptic feedback when we detect the right-click gesture.
Added an option to disable NLA enforcement under iOS Settings > RD Client.
Mapped Control+Shift+Escape to Ctrl+Shift+Esc, where Escape is generated using
a remapped key on iPadOS or Command+.
Mapped Command+F to Ctrl+F.
Fixed an issue where the SwiftPoint middle mouse button didn't work in iPadOS
version 13.3.1 or earlier and iOS.
Fixed some bugs that prevented the client from recognizing the "rdp:" URI.
Addressed an issue where the in-session Immersive Switcher UI showed outdated
app entries if a disconnect was server-initiated.
The client now supports the Azure Resource Manager-integrated version of Azure
Virtual Desktop.

In this update we've added the ability to sort the PC list view (available on iPhone) by
name or time last connected.

Fixed a number of VoiceOver accessibility issues.

Fixed an issue where users couldn't connect with Turkish credentials.
Sessions displayed in the switcher UI are now ordered by when they were
launched.
Selecting the Back button in the Connection Center now takes you back to the last
active session.
Swiftpoint mice are now released when switching away from the client to another
app.
Improved interoperability with the Azure Virtual Desktop service.
Fixed crashes that were showing up in error reporting.

We've put together some bug fixes and feature updates for this release. Here's what's
new:
Launched RDP files are now automatically imported (look for the toggle in General
settings).
You can now launch iCloud-based RDP files that haven't been downloaded in the
Files app yet.
The remote session can now extend underneath the Home indicator on iPhones
(look for the toggle in Display settings).
Added support for typing composite characters with multiple keystrokes, such as é.
Added support for the iPad on-screen floating keyboard.
Added support for adjusting properties of redirected cameras from a remote
session.
Fixed a bug in the gesture recognizer that caused the client to become
unresponsive when connected to a remote session.
You can now enter App Switching mode with a single swipe up (except when
you're in Touch mode with the session extended into the Home indicator area).
The Home indicator will now automatically hide when connected to a remote
session, and will reappear when you tap the screen.
Added a keyboard shortcut to get to app settings in the Connection Center
(Command + ,).
Added a keyboard shortcut to refresh all workspaces in the Connection Center
(Command + R).
Hooked up the system keyboard shortcut for Escape when connected to a remote
session (Command + .).
Fixed scenarios where the Windows on-screen keyboard in the remote session was
too small.
Implemented auto-keyboard focus throughout the Connection Center to make
data entry more seamless.
Pressing Enter at a credential prompt now results in the prompt being dismissed
and the current flow resuming.
Fixed a scenario where the client would crash when pressing Shift + Option + Left,
Up, or Down arrow key.
Fixed a crash that occurred when removing a SwiftPoint device.
Fixed other crashes reported to us by users since the last release.


Confirmation UI is now shown when deleting user accounts and gateways.
The search UI in the Connection Center has been slightly reworked.
The username hint, if it exists, is now shown in the credential prompt UI when
launching from an RDP file or URI.
Fixed an issue where the extended on-screen keyboard would extend underneath
the iPhone notch.
Fixed a bug where external keyboards would stop working after being
disconnected and reconnected.
Added support for the Esc key on external keyboards.
Fixed a bug where English characters appeared when entering Chinese characters.
Fixed a bug where some Chinese input would remain in the remote session after
deletion.

Support for launching connections from RDP files and RDP URIs.
Workspace headers are now collapsible.
Zooming and panning at the same time is now supported in Mouse Pointer mode.
A press-and-hold gesture in Mouse Pointer mode will now trigger a right-click in
the remote session.
Removed force-touch gesture for right-click in Mouse Pointer mode.
The in-session switcher screen now supports disconnecting, even if no apps are
connected.
Light dismiss is now supported in the in-session switcher screen.
PCs and apps are no longer automatically reordered in the in-session switcher
screen.
Enlarged the hit test area for the PC thumbnail view ellipses menu.
The Input Devices settings page now contains a link to supported devices.
Fixed a bug that caused the Bluetooth permissions UI to repeatedly appear at
launch for some users.

We've been working hard to fix bugs and add useful features. Here's what's new in this
release:
Support for Japanese and Chinese input on hardware keyboards.

The PC list view now shows the friendly name of the associated user account, if
one exists.
The permissions UI in the first-run experience is now rendered correctly in Light
mode.
Fixed a crash that happened whenever someone pressed the Option and Up or
Down arrow keys at the same time on a hardware keyboard.
Updated the on-screen keyboard layout used in the password prompt UI to make
finding the Backslash key easier.

Here's what new in this release:
Support for the Azure Virtual Desktop service.

Updated Connection Center UI.
Updated in-session UI.

Support for the Azure Virtual Desktop service.

A new Connection Center UI.
A new in-session UI that can switch between connected PCs and apps.
New layout for the auxiliary on-screen keyboard.
Improved external keyboard support.
SwiftPoint Bluetooth mouse support.
Microphone redirection support.
Local storage redirection support.
Camera redirection support (only available for Windows 10, version 1809 or later).
Support for new iPhone and iPad devices.
Dark and light theme support.
Control whether your phone can lock when connected to a remote PC or app.
You can now collapse the in-session connection bar by pressing and holding the
Remote Desktop logo button.

Bug fixes and performance improvements.

Updates to address CredSSP encryption oracle remediation described in CVE-

2018-0886.
client for Android and Chrome OS
Android and Chrome OS. To learn more about using the Remote Desktop client for
Android and Chrome OS with Azure Virtual Desktop, see Connect to Azure Virtual
Desktop with the Remote Desktop client for Android and Chrome OS and Use features
of the Remote Desktop client for Android and Chrome OS when connecting to Azure
Virtual Desktop.

Public 10.0.15.1207 Google Play
Beta 10.0.15.1207 Google Play

Added support for camera redirection.

Bug fixes and improvements.

Bug fixes and improvements.

App localized into 16 languages.
Client-side time zone redirection.

HTTP proxy support.
Fixed an issue where input from the ENTER key was sent twice when using IME on
Samsung devices.
Updates to improve Azure Virtual Desktop connection reliability and performance.
UI fixes and fine-tuning.
Enhanced Chromebook experience:
Windowed mode support.
Support for launching connections in separate windows.
High DPI support.
Addressed Chromebook compatibility bugs.
Minimum required version of Android is now Android 9.

We've made an in-session UI that switches between remote apps and PCs.
Updated language support for Input Method Editors (IME) and external keyboards.
Added support for Azure Virtual Desktop workspace subscriptions that use
multiple identities for the same URL.
We added a warning message that says you shouldn't use the RD Gateway for local
addresses.
Added support for the NumLock and ScrLock keys on external keyboards.
Fixed bugs that appeared in dark mode.
The minimum required version of Android is now Android 8.

Bug fixes and performance improvements.

Added support for client-side IMEs when using built-in and onscreen keyboards.
Added a prompt for credentials when subscribing to a workflow.
Improved Azure Virtual Desktop workspace download performance to prevent
throttling.
Fixed an issue where incorrect command icons would appear in the UI.

Support for dark mode on Android 10 and later.

Fixed clipboard redirection synchronization issues.
Added clipboard redirection to the Add/Edit PC UI.
The Android client now supports the DEL key on external keyboards.
Fixed a bug that caused workspace URL auto-complete to stop responding.
Addressed keyboard and screen reader-related accessibility bugs.
Addressed reliability issues identified by user reports.

Client now supports microphone redirection.

New UI for subscribing to and editing workspaces.
Cleaned up existing UI throughout the client.
Fixed Samsung DeX keyboard input.
Addressed an issue where clients would report a 0x5000007 error when connecting
using an RD Gateway server.
Addressed several reliability issues identified by users through crash reporting.
Minimum required version of Android is now Android 6.
Fixed an issue where the client stopped responding while saving a file to redirected
storage.
Date Published: 07/24/2020
Implemented full support for Azure Virtual Desktop.

Rewrote the client to use the same underlying RDP core engine as the iOS and
macOS clients.
New Connection Center experience.
New Connection Progress UI.
New in-session Connection Bar.
Added support for Android TV devices.
Integration with Microsoft Authenticator to enable conditional access when
subscribing to Azure Virtual Desktop feeds.
Enabled the transfer of connections and settings from Remote Desktop 8.

Date Published: 05/26/2020
Changed the client icon to distinguish it from the new client currently in preview.
Prepared the client to support settings and connections transfer to the new client.

Fixed an issue where barcode scanners didn't work.

Improved accessibility for users of keyboard-only navigation.

Microsoft Store client
In this article you'll learn about the latest updates for the Remote Desktop Microsoft
Store client. To learn more about using the Remote Desktop Microsoft Store client with
Azure Virtual Desktop, see Connect to Azure Virtual Desktop with the Remote Desktop
Microsoft Store client and Use features of the Remote Desktop Microsoft Store client
when connecting to Azure Virtual Desktop.
） Important
We're no longer updating the Microsoft Store client with new features.
For the best Azure Virtual Desktop experience that includes the latest features and
fixes, we recommend you download the Remote Desktop client for Windows
instead.

The following table lists the current version available for the public release:
Public 10.2.3000.0 Microsoft Store

There are no changes to the client in this release.

Fixed an issue that caused crashes during clipboard scenarios.

Fixed an issue that happened when using the client with HoloLens.
Fixed an issue where the lock screen wasn't appearing in the remote session.
Fixed issues that happened when the client tried to connect to devices with the
“Always prompt for password upon connection” group policy set.
Added several stability improvements to the client.

Rewrote the client to use the same underlying RDP core engine as the iOS, macOS,
and Android clients.
Added support for the Azure Resource Manager-integrated version of Azure
Virtual Desktop.
Added support for x64 and ARM64.
Updated the side panel design to full screen.
Added support for light and dark modes.
Added functionality to subscribe and connect to sovereign cloud deployments.
Added functionality to enable backup and restore of workspaces (bookmarks) in
release to manufacturing (RTM).
Updated functionality to use existing Azure Active Directory (Azure AD) tokens
during the subscription process to reduce the number of times users must sign in.
Updated subscription can now detect whether you're using Azure Virtual Desktop
or Azure Virtual Desktop (classic).
Fixed issue with copying files to remote PCs.
Fixed commonly reported accessibility issues with buttons.
A limit of up to 20 credentials per app is allowed.

Updated the user agent string for Azure Virtual Desktop.

Audio from the session now continues to play even when the app is minimized or
in the background.
Fixed an issue where the toggle keys (caps lock, num lock, and so on) went out of
sync between the local and remote PCs.
Performance improvements on 64-bit devices.
Fixed a crash that occurred whenever the app was suspended.

You can now copy files between local and remote PCs.
You can now use your email address to access remote resources (if enabled by
your admin).
You can now change user account assignments for remote resource feeds.
The app now shows the proper icon for .rdp files assigned to this app in File
Explorer instead of a blank default icon.

You can now set a display name for user accounts so you can save the same
username with different passwords.
It's now possible to select an existing user account when adding Remote
Resources.
Fixed an issue where the client wasn't terminating correctly.
The client now properly handles being suspended when secondary windows are
open.
Additional bug fixes.


Connection display name is now more discoverable.
Fixed a crash when closing the client window while a connection is still active.
Fix a hang when reconnecting after the client is minimized.
Allow desktops to be dragged anywhere in a group.
Ensure launching a connection from the jump list results in a separate window
when needed.

Addressed an issue where double-clicking a desktop connection caused two

sessions to be launched.
Fixed a crash when switching between virtual desktops locally.
Moving a session to a different monitor now also updates the session scale factor.
Handle additional system keys like AltGr.

Bug fixes.

Updates to address CredSSP encryption oracle remediation described in CVE-

2018-0886.
Tutorial: Create a tenant in Azure Virtual
Desktop (classic)
） Important
This content applies to Azure Virtual Desktop (classic), which doesn't support Azure
Resource Manager Azure Virtual Desktop objects.
） Important
Starting July 28, 2022, you'll no longer be able to create new tenants in Azure
Virtual Desktop (classic). You can still manage your existing Azure Virtual Desktop
(classic) environments including adding new session hosts, but all new
environments must be done in Azure Virtual Desktop.
You can find more information about how to migrate from Azure Virtual Desktop
(classic) to Azure Virtual Desktop at Migrate automatically from Azure Virtual
Desktop (classic).
Learn about how to create a host pool in Azure Virtual Desktop at Tutorial: Create a
host pool.
Creating a tenant in Azure Virtual Desktop is the first step toward building your desktop
virtualization solution. A tenant is a group of one or more host pools. Each host pool
consists of multiple session hosts, running as virtual machines in Azure and registered to
the Azure Virtual Desktop service. Each host pool also consists of one or more app
groups that are used to publish remote desktop and remote application resources to
users. With a tenant, you can build host pools, create app groups, assign users, and
make connections through the service.
In this tutorial, learn how to:
＂ Grant Azure Active Directory permissions to the Azure Virtual Desktop service.
＂ Assign the TenantCreator application role to a user in your Azure Active Directory
tenant.
＂ Create a Azure Virtual Desktop tenant.
What you need to set up a tenant
Before you start setting up your Azure Virtual Desktop tenant, make sure you have these
things:
The Azure Active Directory tenant ID for Azure Virtual Desktop users.
A global administrator account within the Azure Active Directory tenant.
This also applies to Cloud Solution Provider (CSP) organizations that are
creating a Azure Virtual Desktop tenant for their customers. If you're in a CSP
organization, you must be able to sign in as global administrator of the
customer's Azure Active Directory instance.
The administrator account must be sourced from the Azure Active Directory
tenant in which you're trying to create the Azure Virtual Desktop tenant. This
process doesn't support Azure Active Directory B2B (guest) accounts.
The administrator account must be a work or school account.
An Azure subscription.
You must have the tenant ID, global administrator account, and Azure subscription
ready so that the process described in this tutorial can work properly.
Grant permissions to Azure Virtual Desktop

If you have already granted permissions to Azure Virtual Desktop for this Azure Active
Directory instance, skip this section.
Granting permissions to the Azure Virtual Desktop service lets it query Azure Active
Directory for administrative and end-user tasks.
To grant the service permissions:
1. Open a browser and begin the admin consent flow to the Azure Virtual Desktop
server app .
７ Note
If you manage a customer and need to grant admin consent for the
customer's directory, enter the following URL into the browser and replace
{tenant} with the Azure AD domain name of the customer. For example, if the
customer's organization has registered the Azure AD domain name of
contoso.onmicrosoft.com, replace {tenant} with contoso.onmicrosoft.com.
https://login.microsoftonline.com/{tenant}/adminconsent?
client_id=5a0aa725-4958-4b0c-80a9-
34562e23f3b7&redirect_uri=https%3A%2F%2Frdweb.wvd.microsoft.com%2FR
DWeb%2FConsentCallback
2. Sign in to the Azure Virtual Desktop consent page with a global administrator
account. For example, if you were with the Contoso organization, your account
might be admin@contoso.com or admin@contoso.onmicrosoft.com.
3. Select Accept.
4. Wait for one minute so Azure AD can record consent.
5. Open a browser and begin the admin consent flow to the Azure Virtual Desktop
client app .
７ Note
If you manage a customer and need to grant admin consent for the
customer's directory, enter the following URL into the browser and replace
{tenant} with the Azure AD domain name of the customer. For example, if the
customer's organization has registered the Azure AD domain name of
contoso.onmicrosoft.com, replace {tenant} with contoso.onmicrosoft.com.
https://login.microsoftonline.com/{tenant}/adminconsent?
client_id=fa4345a4-a730-4230-84a8-
7d9651b86739&redirect_uri=https%3A%2F%2Frdweb.wvd.microsoft.com%2FR
DWeb%2FConsentCallback
6. Sign in to the Azure Virtual Desktop consent page as global administrator, as you
did in step 2.
7. Select Accept.
Assign the TenantCreator application role

Assigning an Azure Active Directory user the TenantCreator application role allows that
user to create a Azure Virtual Desktop tenant associated with the Azure Active Directory
instance. You'll need to use your global administrator account to assign the
TenantCreator role.
To assign the TenantCreator application role:
1. Go to the Azure portal to manage the TenantCreator application role. Search for
and select Enterprise applications. If you're working with multiple Azure Active
Directory tenants, it's a best practice to open a private browser session and copy
and paste the URLs into the address bar.
2. Within Enterprise applications, search for Azure Virtual Desktop. You'll see the
two applications that you provided consent for in the previous section. Of these
two apps, select Azure Virtual Desktop.
3. Select Users and groups. You might see that the administrator who granted
consent to the application is already listed with the Default Access role assigned.
This is not enough to create a Azure Virtual Desktop tenant. Continue following
these instructions to add the TenantCreator role to a user.
4. Select Add user, and then select Users and groups in the Add Assignment tab.
5. Search for a user account that will create your Azure Virtual Desktop tenant. For
simplicity, this can be the global administrator account.
If you're using a Microsoft Identity Provider like contosoadmin@live.com or

contosoadmin@outlook.com, you might not be able to sign in to Azure
Virtual Desktop. We recommend using a domain-specific account like
admin@contoso.com or admin@contoso.onmicrosoft.com instead.
７ Note
You must select a user (or a group that contains a user) that's sourced from
this Azure Active Directory instance. You can't choose a guest (B2B) user or a
service principal.
6. Select the user account, choose the Select button, and then select Assign.
7. On the Azure Virtual Desktop - Users and groups page, verify that you see a new
entry with the TenantCreator role assigned to the user who will create the Azure
Virtual Desktop tenant.
Before you continue on to create your Azure Virtual Desktop tenant, you need two
pieces of information:
Your Azure Active Directory tenant ID (or Directory ID)

Your Azure subscription ID
To find your Azure Active Directory tenant ID (or Directory ID):
1. In the same Azure portal session, search for and select Azure Active Directory.
2. Scroll down until you find Properties, and then select it.
3. Look for Directory ID, and then select the clipboard icon. Paste it in a handy
location so you can use it later as the AadTenantId value.
To find your Azure subscription ID:

1. In the same Azure portal session, search for and select Subscriptions.
2. Select the Azure subscription you want to use to receive Azure Virtual Desktop
service notifications.
3. Look for Subscription ID, and then hover over the value until a clipboard icon
appears. Select the clipboard icon and paste it in a handy location so you can use it
later as the AzureSubscriptionId value.
Create a Azure Virtual Desktop tenant

Now that you've granted the Azure Virtual Desktop service permissions to query Azure
Active Directory and assigned the TenantCreator role to a user account, you can create a
Azure Virtual Desktop tenant.
First, download and import the Azure Virtual Desktop module to use in your PowerShell
session if you haven't already.
Sign in to Azure Virtual Desktop by using the TenantCreator user account with this
cmdlet:
PowerShell
Add-RdsAccount -DeploymentUrl "https://rdbroker.wvd.microsoft.com"
After that, create a new Azure Virtual Desktop tenant associated with the Azure Active
Directory tenant:
PowerShell
New-RdsTenant -Name <TenantName> -AadTenantId <DirectoryID> -

AzureSubscriptionId <SubscriptionID>
Replace the bracketed values with values relevant to your organization and tenant. The
name you choose for your new Azure Virtual Desktop tenant should be globally unique.
For example, let's say you're the Azure Virtual Desktop TenantCreator for the Contoso
organization. The cmdlet you'd run would look like this:
PowerShell
New-RdsTenant -Name Contoso -AadTenantId 00000000-1111-2222-3333-

444444444444 -AzureSubscriptionId 55555555-6666-7777-8888-999999999999
It's a good idea to assign administrative access to a second user in case you ever find
yourself locked out of your account, or you go on vacation and need someone to act as
the tenant admin in your absence. To assign admin access to a second user, run the
following cmdlet with <TenantName> and <Upn> replaced with your tenant name and the
second user's UPN.
PowerShell
New-RdsRoleAssignment -TenantName <TenantName> -SignInName <Upn> -

RoleDefinitionName "RDS Owner"
Next steps
After you've created your tenant, you'll need to create a service principal in Azure Active
Directory and assign it a role within Azure Virtual Desktop. The service principal will
allow you to successfully deploy the Azure Virtual Desktop Azure Marketplace offering
to create a host pool. To learn more about host pools, continue to the tutorial for
creating a host pool in Azure Virtual Desktop.
Create service principals and role assignments with PowerShell

Tutorial: Create and connect to a
Windows 11 desktop with Azure Virtual
Desktop
Azure Virtual Desktop is a desktop and app virtualization service that runs on the cloud.
This tutorial shows you a simple method to deploy a Windows 11 Enterprise desktop in
Azure Virtual Desktop using the Azure portal and how to connect to it. To learn more
about the terminology used for Azure Virtual Desktop, see Azure Virtual Desktop
terminology.
You will:
＂ Create a personal host pool.

＂ Create a session host virtual machine (VM) joined to your Azure Active Directory
tenant with Windows 11 Enterprise and add it to the host pool.
＂ Create a workspace and an application group that publishes a desktop to the
session host VM.
＂ Assign users to the application group.
＂ Connect to the desktop.
Prerequisites
You'll need:
An Azure account with an active subscription. If you don't have an Azure

subscription, create a free account before you begin.
The account must be assigned the Owner or Contributor built-in role-based access
control (RBAC) roles on the subscription.
A virtual network in the same Azure region you want to deploy your session hosts
to.
A user account in Azure Active Directory you can use for connecting to the
desktop. This account must be assigned the Virtual Machine User Login or Virtual
Machine Administrator Login RBAC role on the subscription. Alternatively you can
assign the role to the account on the session host VM or the resource group
containing the VM after deployment.
A Remote Desktop client installed on your device to connect to the desktop. You
can find a list of supported clients in Remote Desktop clients for Azure Virtual
Desktop. Alternatively you can use the Remote Desktop Web client, which you can
use through a supported web browser without installing any extra software.
Create a personal host pool, workspace,

application group, and session host VM
To create a personal host pool, workspace, application group, and session host VM
running Windows 11:
2. In the search bar, type Azure Virtual Desktop and select the matching service entry.
3. From the Azure Virtual Desktop overview page, select Create a host pool.
4. On the Basics tab, complete the following information:
Parameter Value/Description
Project
details
Subscription Select the subscription you want to deploy your host pool, session hosts,
workspace, and application group in from the drop-down list.
Resource Select an existing resource group or select Create new and enter a name.
group
Host pool Enter a name for the host pool, for example aad-hp01.
name
Location Select the Azure region from the list where the host pool, workspace, and
application group will be deployed.
Validation Select No. This setting enables your host pool to receive service updates
environment before all other production host pools, but isn't needed for this tutorial.
Preferred Select Desktop. This setting designates what type of resource users see in
app group their feed if they're assigned both Desktop and Remote App application
type groups in the same host pool.
Host pool
type
Host pool Select Personal. This means that end users have a dedicated assigned
type session host that they'll always connect to. Selecting Personal shows a new
option for Assignment type.
Assignment Select Automatic. Automatic assignment means that a user will

type automatically get assigned the first available session host when they first
sign in, which will then be dedicated to that user.
Once you've completed this tab, select Next: Virtual Machines.
5. On the Virtual machines tab, complete the following information:
Add Azure Select Yes. This shows several new options.

virtual
machines
Resource This automatically defaults to the resource group you chose your host pool
group to be in on the Basics tab.
Name prefix Enter a name for your session hosts, for example aad-hp01-sh.
This will be used as the prefix for your session host VMs. Each session host
has a hyphen and then a sequential number added to the end, for example
aad-hp01-sh-0. This name prefix can be a maximum of 11 characters and is
used in the computer name in the operating system.
Virtual Select the Azure region where your session host VMs will be deployed. This
machine must be the same region that your virtual network is in.
location
Availability Select No infrastructure dependency required. This means that your

options session host VMs won't be deployed in an availability set or in availability
zones.
Security type Select Standard.
Image Select Windows 11 Enterprise, version 22H2.
Virtual Accept the default SKU. If you want to use a different SKU, select Change
machine size size, then select from the list.
Number of Enter 1 as a minimum. You can deploy up to 400 session host VMs at this
VMs point if you wish, or you can add more later.
With a personal host pool, each session host can only be assigned to one
user, so you'll need one session host for each user connecting to this host
pool. Once you've completed this tutorial, you can create a pooled host
pool, where multiple users can connect to the same session host.
OS disk type Select Premium SSD for best performance.
Boot Select Enable with managed storage account (recommended).

Diagnostics
Network and
security
Virtual Select your virtual network.

network
Network Select Basic.

security
group
Public Select No.

inbound ports
Domain to
join
Select which Select Azure Active Directory.

directory you
would like to
join
Enroll VM Select No.

with Intune
Virtual
Machine
Administrator
account
Username Enter a name to use as the local administrator account for these session
host VMs.
Password Enter a password for the local administrator account.
Confirm Re-enter the password.

password
Custom
configuration
ARM Leave this blank.

template file
URL
ARM Leave this blank.

template
parameter file
URL
Once you've completed this tab, select Next: Workspace.
6. On the Workspace tab, complete the following information:
Register desktop Select Yes. This registers the default desktop application group to
app group the selected workspace.
To this workspace Select Create new and enter a name, for example aad-ws01.
Once you've completed this tab, select Next: Review + create.
7. On the Review + create tab, ensure validation passes and review the information
that will be used during deployment. If validation doesn't pass, review the error
message and check what you entered in each tab.
8. Select Create. A host pool, workspace, application group, and session host will be
created. Once your deployment is complete, select Go to resource. This goes to
the host pool overview.
Assign users to the application group

Once your host pool, workspace, application group, and session host VM(s) have been
deployed, you need to assign users to the application group that was automatically
created. After users are assigned to the application group, they'll automatically be
assigned to an available session host VM because Assignment type was set to Automatic
when the host pool was created.
1. From the host pool overview, select Application groups.
2. Select the application group from the list, for example aad-hp01-DAG.
3. From the application group overview, select Assignments.
4. Select + Add, then search for and select the user account you want to be assigned
to this application group.
5. Finish by selecting Select.
Enable connections from Remote Desktop

clients
 Tip
This section is optional if you're going to use a Windows device to connect to

Azure Virtual Desktop that is joined to the same Azure AD tenant as your session
host VMs and you're using the Remote Desktop client for Windows.
To enable connections from all of the Remote Desktop clients, you'll need to add an RDP
property to your host pool configuration.
1. Go back to the host pool overview, then select RDP Properties.
2. Select the Advanced tab.
3. In the RDP Properties box, add targetisaadjoined:i:1; to the start of the text in
the box.
4. Select Save.
Connect to the desktop

You're ready to connect to the desktop. The desktop takes longer to load the first time
as the profile is being created, however subsequent connections will be quicker.
） Important
Make sure the user account you're using to connect has been assigned the Virtual
Machine User Login or Virtual Machine Administrator Login RBAC role on the
subscription, session host VM, or the resource group containing the VM, as
mentioned in the prerequisites, else you won't be able to connect.
Select the relevant tab below and follow the steps, depending on which Remote
Desktop client you're using. We've only listed the steps here for Windows, Web and
macOS, but if you want to connect using one of our other Remote Desktop clients, see
Remote Desktop clients for Azure Virtual Desktop.
Windows
1. Open the Remote Desktop app on your device.
2. Select the three dots in the top right-hand corner, then select Subscribe with
URL.
3. In the Email or Workspace URL box, enter https://rdweb.wvd.microsoft.com .

After a few seconds, the message We found Workspaces at the following
URLs should be displayed.
4. Select Next.
5. Sign in with the user account you assigned to the application group. After a
few seconds, the workspace should show with an icon named
SessionDesktop.
6. Double-click SessionDesktop to launch a desktop session. You'll need to enter

the password for the user account again.
Next steps
Now that you've created and connected to a Windows 11 desktop with Azure Virtual
Desktop there's much more you can do. For example you can:
Create a pooled host pool, where multiple users can connect to the same session
host at the same time.
Manage user profiles using FSLogix profile containers and Azure Files.
Set up email discovery to subscribe to Azure Virtual Desktop.
Configure single sign-on for Azure Virtual Desktop using Azure AD Authentication.
Add session hosts to a host pool.
Learn about session host virtual machine sizing guidelines.
Use Microsoft Teams on Azure Virtual Desktop.
Monitor your deployment with Azure Virtual Desktop Insights.
Azure Virtual Desktop terminology
） Important
This content applies to Azure Virtual Desktop with Azure Resource Manager Azure
Virtual Desktop objects. If you're using Azure Virtual Desktop (classic) without
Azure Resource Manager objects, see this article.
Azure Virtual Desktop is a service that gives users easy and secure access to their
virtualized desktops and RemoteApps. This topic will tell you a bit more about the
terminology and general structure of Azure Virtual Desktop.
Host pools
A host pool is a collection of Azure virtual machines that register to Azure Virtual
Desktop as session hosts when you run the Azure Virtual Desktop agent. All session host
virtual machines in a host pool should be sourced from the same image for a consistent
user experience. You control the resources published to users through app groups.
A host pool can be one of two types:
Personal, where each session host is assigned to an individual user. Personal host
pools provide dedicated desktops to end-users that optimize environments for
performance and data separation.
Pooled, where user sessions can be load balanced to any session host in the host
pool. There can be multiple different users on a single session host at the same
time. Pooled host pools provide a shared remote experience to end-users, which
ensures lower costs and greater efficiency.
The following table goes into more detail about the differences between each type of
host pool:
Feature Personal host pools Pooled host pools
Load User sessions are always load balanced to User sessions are load balanced to
balancing the session host the user is assigned to. If session hosts in the host pool based
the user isn't currently assigned to a session on user session count. You can
host, the user session is load balanced to the choose which load balancing
next available session host in the host pool. algorithm to use: breadth-first or
depth-first.
Feature Personal host pools Pooled host pools
Maximum One. As configured by the Max session

session limit value of the properties of a
limit host pool.
User Users can either be directly assigned to Users aren't assigned to session
assignment session hosts or be automatically assigned hosts. After a user signs out and
process to the first available session host. Users signs back in, their user session
always have sessions on the session hosts might get load balanced to a
they are assigned to. different session host.
Scaling None. Autoscale for pooled host pools

turns VMs on and off based on the
capacity thresholds and schedules
the customer defines.
Windows Updated with Windows Updates, System Updated by redeploying session

Updates Center Configuration Manager (SCCM), or hosts from updated images instead
other software distribution configuration of traditional updates.
tools.
User data Each user only ever uses one session host, so Users can connect to different
they can store their user profile data on the session hosts every time they
operating system (OS) disk of the VM. connect, so they should store their
user profile data in FSLogix.
App groups
An app group is a logical grouping of applications installed on session hosts in the host
pool.
An app group can be one of two types:
RemoteApp, where users access the RemoteApps you individually select and
publish to the app group. Available with pooled host pools only.
Desktop, where users access the full desktop. Available with pooled or personal
host pools.
Pooled host pools have a preferred app group type that dictates whether users see
RemoteApp or Desktop apps in their feed if both resources have been published to the
same user. By default, Azure Virtual Desktop automatically creates a Desktop app group
with the friendly name Default Desktop whenever you create a host pool and sets the
host pool's preferred app group type to Desktop. You can remove the Desktop app
group at any time. If you want your users to only see RemoteApps in their feed, you
should set the preferred application group type value to RemoteApp. If you want your
users to only see session desktops in their feed, you should set the preferred
application group type value to Desktop. You can't create another Desktop app group
in a host pool while a Desktop app group exists.
To publish resources to users, you must assign them to app groups. When assigning
users to app groups, consider the following things:
We don't support assigning both the RemoteApp and desktop app groups in a
single host pool to the same user. Doing so will cause a single user to have two
user sessions in a single host pool. Users aren't supposed to have two active user
sessions at the same time, as this can cause the following things to happen:
The session hosts become overloaded
Users get stuck when trying to login
Connections won't work
The screen turns black
The application crashes
Other negative effects on end-user experience and session performance
A user can be assigned to multiple app groups within the same host pool, and
their feed will be an accumulation of both app groups.
Personal host pools only allow and support Desktop app groups.
７ Note
If your host pool’s preferred application group type is set to Undefined, that means
you haven’t set the value yet. You must finish configuring your host pool by setting
its preferred application group type before you start using it to prevent app
incompatibility and session host overload issues.
Workspaces
A workspace is a logical grouping of application groups in Azure Virtual Desktop. Each
Azure Virtual Desktop application group must be associated with a workspace for users
to see the remote apps and desktops published to them.
End users
After you've assigned users to their app groups, they can connect to an Azure Virtual
Desktop deployment with any of the Azure Virtual Desktop clients.
User sessions
In this section, we'll go over each of the three types of user sessions that end users can
have.
Active user session

A user session is considered "active" when a user signs in and connects to their remote
app or desktop resource.
Disconnected user session

A disconnected user session is an inactive session that the user hasn't signed out of yet.
When a user closes the remote session window without signing out, the session
becomes disconnected. When a user reconnects to their remote resources, they'll be
redirected to their disconnected session on the session host they were working on. At
this point, the disconnected session becomes an active session again.
Pending user session

A pending user session is a placeholder session that reserves a spot on the load-
balanced virtual machine for the user. Because the sign-in process can take anywhere
from 30 seconds to five minutes depending on the user profile, this placeholder session
ensures that the user won't be kicked out of their session if another user completes their
sign-in process first.
Next steps
Learn more about delegated access and how to assign roles to users at Delegated
Access in Azure Virtual Desktop.
To learn how to set up your Azure Virtual Desktop host pool, see Create a host pool with
the Azure portal.
To learn how to connect to Azure Virtual Desktop, see one of the following articles:
Connect with Windows

Connect with a web browser
Connect with the Android client
Connect with the macOS client
Connect with the iOS client
Deploy Azure AD-joined virtual
machines in Azure Virtual Desktop
This article will walk you through the process of deploying and accessing Azure Active
Directory joined virtual machines in Azure Virtual Desktop. Azure AD-joined VMs
remove the need to have line-of-sight from the VM to an on-premises or virtualized
Active Directory Domain Controller (DC) or to deploy Azure AD Domain services (Azure
AD DS). In some cases, it can remove the need for a DC entirely, simplifying the
deployment and management of the environment. These VMs can also be automatically
enrolled in Intune for ease of management.
Supported configurations
The following configurations are currently supported with Azure AD-joined VMs:
Personal desktops with local user profiles.

Pooled desktops used as a jump box. In this configuration, users first access the
Azure Virtual Desktop VM before connecting to a different PC on the network.
Users shouldn't save data on the VM.
Pooled desktops or apps where users don't need to save data on the VM. For
example, for applications that save data online or connect to a remote database.
Personal or pooled desktops with FSLogix user profiles.
User accounts can be cloud-only or synced users from the same Azure AD tenant.
Known limitations
The following known limitations may affect access to your on-premises or Active
Directory domain-joined resources and should be considered when deciding whether
Azure AD-joined VMs are right for your environment. We currently recommend Azure
AD-joined VMs for scenarios where users only need access to cloud-based resources or
Azure AD-based authentication.
Azure Virtual Desktop (classic) doesn't support Azure AD-joined VMs.

Azure AD-joined VMs don't currently support external identities, such as Azure AD
Business-to-Business (B2B) and Azure AD Business-to-Consumer (B2C).
Azure AD-joined VMs can only access Azure Files file shares for synced users using
Azure AD Kerberos.
The Windows Store client doesn't currently support Azure AD-joined VMs.
Deploy Azure AD-joined VMs

You can deploy Azure AD-joined VMs directly from the Azure portal when you create a
new host pool or expand an existing host pool. To deploy an Azure AD-joined VM, open
the Virtual Machines tab, then select whether to join the VM to Active Directory or
Azure Active Directory. Selecting Azure Active Directory gives you the option to enroll
VMs with Intune automatically, which lets you easily manage your session hosts. Keep in
mind that the Azure Active Directory option will only join VMs to the same Azure AD
tenant as the subscription you're in.
７ Note
Host pools should only contain VMs of the same domain join type. For
example, Azure AD-joined VMs should only be with other Azure AD VMs, and
vice-versa.
The VMs in the host pool must be Windows 11 or Windows 10 single-session
or multi-session, version 2004 or later, or Windows Server 2022 or Windows
Server 2019.
Assign user access to host pools

After you've created your host pool, you must assign users access to their resources. To
grant access to resources, add each user to the app group. Follow the instructions in
Manage app groups to assign user access to apps and desktops. We recommend that
you use user groups instead of individual users wherever possible.
For Azure AD-joined VMs, you'll need to do two extra things on top of the requirements
for Active Directory or Azure Active Directory Domain Services-based deployments:
Assign your users the Virtual Machine User Login role so they can sign in to the
VMs.
Assign administrators who need local administrative privileges the Virtual Machine
Administrator Login role.
To grant users access to Azure AD-joined VMs, you must configure role assignments for
the VM. You can assign the Virtual Machine User Login or Virtual Machine
Administrator Login role either on the VMs, the resource group containing the VMs, or
the subscription. We recommend assigning the Virtual Machine User Login role to the
same user group you used for the app group at the resource group level to make it
apply to all the VMs in the host pool.
Access Azure AD-joined VMs

This section explains how to access Azure AD-joined VMs from different Azure Virtual
Desktop clients.
Connect using the Windows Desktop client

The default configuration supports connections from Windows 11 or Windows 10 using
the Windows Desktop client. You can use your credentials, smart card, Windows Hello
for Business certificate trust or Windows Hello for Business key trust with certificates to
sign in to the session host. However, to access the session host, your local PC must meet
one of the following conditions:
The local PC is Azure AD-joined to the same Azure AD tenant as the session host
The local PC is hybrid Azure AD-joined to the same Azure AD tenant as the session
host
The local PC is running Windows 11 or Windows 10, version 2004 or later, and is
Azure AD registered to the same Azure AD tenant as the session host
If your local PC doesn't meet one of these conditions, add targetisaadjoined:i:1 as a

custom RDP property to the host pool. These connections are restricted to entering user
name and password credentials when signing in to the session host.
Connect using the other clients

To access Azure AD-joined VMs using the web, Android, macOS and iOS clients, you
must add targetisaadjoined:i:1 as a custom RDP property to the host pool. These
connections are restricted to entering user name and password credentials when
signing in to the session host.
Enforcing Azure AD Multi-Factor Authentication for Azure

AD-joined session VMs
You can use Azure AD Multi-Factor Authentication with Azure AD-joined VMs. Follow
the steps to Enforce Azure Active Directory Multi-Factor Authentication for Azure Virtual
Desktop using Conditional Access and note the extra steps for Azure AD-joined session
host VMs.
Single sign-on
You can enable a single sign-on experience using Azure AD authentication when
accessing Azure AD-joined VMs. Follow the steps to Configure single sign-on to provide
a seamless connection experience.
User profiles
You can use FSLogix profile containers with Azure AD-joined VMs when you store them
on Azure Files while using synced user accounts. For more information, see Create a
profile container with Azure Files and Azure AD.
Accessing on-premises resources

While you don't need an Active Directory to deploy or access your Azure AD-joined
VMs, an Active Directory and line-of-sight to it are needed to access on-premises
resources from those VMs. To learn more about accessing on-premises resources, see
How SSO to on-premises resources works on Azure AD joined devices.
Next steps
Now that you've deployed some Azure AD joined VMs, we recommend enabling single
sign-on before connecting with a supported Azure Virtual Desktop client to test it as
part of a user session. To learn more, check out these articles:
Configure single sign-on

Create a profile container with Azure Files and Azure AD
Troubleshoot connections to Azure AD-joined VMs
Session host virtual machine sizing
guidelines
Whether you're running your session host virtual machines (VM) on Remote Desktop
Services or Azure Virtual Desktop, different types of workloads require different VM
configurations. The examples in this article are generic guidelines and you should only
use them for initial performance estimates. For the best possible experience, you will
need to scale your deployment depending on your users' needs.
Workloads
Users can run different types of workloads on the session host virtual machines. The
following table provides examples of a range of workload types to help you estimate
what size your virtual machines need to be. After you set up your virtual machines, you
should continually monitor their actual usage and adjust their size accordingly. If you
end up needing a bigger or smaller virtual machine, you can easily scale your existing
deployment up or down in Azure.
The following table describes each workload. Example users are the types of users that
might find each workload most helpful. Example apps are the kinds of apps that work
best for each workload.
Workload type Example users Example apps
Light Users doing basic data entry Database entry applications, command-line
tasks interfaces
Medium Consultants and Database entry applications, command-line

market researchers interfaces, Microsoft Word, static web pages
Heavy Software engineers, Database entry applications, command-line

content creators interfaces, Microsoft Word, static web pages,
Microsoft Outlook, Microsoft PowerPoint,
dynamic web pages, software development
Power Graphic designers, Database entry applications, command-line

3D model makers, interfaces, Microsoft Word, static web pages,
machine learning researchers Microsoft Outlook, Microsoft PowerPoint,
dynamic web pages, photo and video editing,
computer-aided design (CAD), computer-aided
manufacturing (CAM)
Single-session recommendations
Single-session refers to when there is only one user logged on to a session host virtual
machine at any one time, such as when using personal host pools in Azure Virtual
Desktop. For VM sizing recommendations for single-session scenarios, we recommend
at least two physical CPU cores per VM (typically four vCPUs with hyper-threading). If
you need more specific VM sizing recommendations for single-session scenarios, ask
the software vendors specific to your workload. VM sizing for single-session VMs will
likely align with physical device guidelines.
The following table shows examples of typical workloads:
Workload vCPU/RAM/OS storage Example Azure Profile container storage

type minimum instances minimum
Light 2 vCPUs, 8 GB RAM, 32 GB D2s_v5, D2s_v4 30 GB

storage
Medium 4 vCPUs, 16 GB RAM, 32 GB D4s_v5, D4s_v4 30 GB

storage
Heavy 8 vCPUs, 32 GB RAM, 32 GB D8s_v5, D8s_v4 30 GB

storage
Multi-session recommendations
Multi-session refers to when there is more than one user logged on to a session host
virtual machine at any one time, such as when using pooled host pools in Azure Virtual
Desktop with the Windows 11 Enterprise multi-session operating system (OS). The
following tables list the maximum suggested number of users per virtual central
processing unit (vCPU) and the minimum VM configuration for each workload. If you
need more specific VM sizing recommendations for single-session scenarios, ask the
software vendors specific to your workload.
The following table shows examples of standard or larger user workloads:
Workload Maximum Minimum Example Azure instances Minimum

type users per vCPU/RAM/OS profile
vCPU storage storage
Light 6 8 vCPUs, 16 GB D8s_v5, D8s_v4, F8s_v2, D8as_v4, 30 GB

RAM, 32 GB D16s_v5, D16s_v4, F16s_v2,
storage D16as_v4
Workload Maximum Minimum Example Azure instances Minimum
type users per vCPU/RAM/OS profile
vCPU storage storage
Medium 4 8 vCPUs, 16 GB D8s_v5, D8s_v4, F8s_v2, D8as_v4, 30 GB

RAM, 32 GB D16s_v5, D16s_v4, F16s_v2,
storage D16as_v4
Heavy 2 8 vCPUs, 16 GB D8s_v5, D8s_v4, F8s_v2, D8as_v4, 30 GB

RAM, 32 GB D16s_v5, D16s_v4, F16s_v2,
storage D16as_v4
Power 1 6 vCPUs, 56 GB D16ds_v5, D16s_v4, D16as_v4, 30 GB

RAM, 340 GB NV6, NV16as_v4
storage
For multi-session, we recommend limiting VM size to between 4 vCPUs and 24 vCPUs

for the following reasons:
All VMs should have more than two cores: the UI components in Windows rely on
using at least two parallel threads for some of the heavier rendering operations.
For multi-session, having multiple users on a two-core VM will lead to the UI and
apps becoming unstable, which lowers the quality of user experience. Four cores is
the lowest recommended number of cores that a stable multi-session VM should
have.
VMs should not have more than 32 cores: as the number of cores increase, the
system's synchronization overhead also increases. For most workloads, at around
16 cores the return on investment gets lower, with most of the extra capacity being
offset by synchronization overhead. You are likely to have more users from two 16
core VMs as opposed to one 32 core one.
The recommended range between 4 and 24 cores will generally provide better capacity
returns for your users as you increase the number of cores. For example, let’s say you
have 12 users sign in at the same time to a VM with four cores. The ratio is three users
per core. Meanwhile, on a VM with eight cores and 14 users, the ratio is 1.75 users per
core. In this scenario, the latter configuration with a ratio of 1.75 offers greater burst
capacity for your applications that have short-term CPU demand.
This recommendation is true at a larger scale. For scenarios with 20 or more users
connected to a single VM, several smaller VMs would perform better than one or two
large VMs. For example, if you're expecting 30 or more users to simultaneously sign in
within 10 minutes on the same session host with 16 cores, two eight-core VMs will
handle the workload better. You can also use breadth-first load balancing to evenly
distribute users across different VMs, rather than depth-first where a session host is
saturated before using another one.
It's also better to use a large number of smaller VMs instead of a few large VMs because
it's easier to shut down VMs that need to be updated or aren't currently in use. With
larger VMs, you're more likely to have at least one user signed in at any time, which
prevents you from shutting down the VM. When you have many smaller VMs, it's more
likely you'll have some that don't have any users signed in. You can safely shut these
unused VMs to conserve resources (either automatically using autoscale in Azure Virtual
Desktop, or manually), making your deployment more resilient, easier to maintain, and
less expensive.
General virtual machine recommendations

In addition to the base requirements to run your chosen OS, in Azure we recommend
you use Premium SSD storage for your OS disk for production workloads that require a
service level agreement (SLA). For more details, see the SLA for virtual machines .
Graphics processing units (GPUs) are a good choice for users who regularly use
graphics-intensive programs for video rendering, 3D design, and simulations.. Azure has
several graphics acceleration deployment options and multiple available GPU VM sizes.
Learn more at GPU optimized virtual machine sizes. For more general information about
graphics acceleration in Remote Desktop Services, see Choose your graphics rendering
technology
B-series burstable VMs in Azure are a good choice for users who don't always need
maximum CPU performance. For more information about VM types and sizes, see Sizes
for Windows virtual machines in Azure and the pricing information on our Virtual
Machine series page .
Test your workload

Finally, we recommend you use simulation tools to test your deployment with both
stress tests and real-life usage simulations. Make sure your system is responsive and
resilient enough to meet user needs, and remember to vary the load size to avoid
surprises.
Windows 10 Enterprise multi-
session FAQ
FAQ
This article answers frequently asked questions and explains best practices for Windows
10 and Windows 11 Enterprise multi-session.
What is Windows 10 Enterprise multi-

session?
Windows 10 Enterprise multi-session, formerly known as Windows 10 Enterprise for
Virtual Desktops (EVD), is a new Remote Desktop Session Host that allows multiple
concurrent interactive sessions. Previously, only Windows Server could do this. This
capability gives users a familiar Windows 10 experience while IT can benefit from the
cost advantages of multi-session and use existing per-user Windows licensing instead of
RDS Client Access Licenses (CALs). For more information about licenses and pricing, see
Azure Virtual Desktop pricing .
How many users can simultaneously

have an interactive session on Windows
10 Enterprise multi-session?
How many interactive sessions that can be active at the same time relies on your
system's hardware resources (vCPU, memory, disk, and vGPU), how your users use their
apps while signed in to a session, and how heavy your system's workload is. We suggest
you validate your system's performance to understand how many users you can have on
Windows 10 Enterprise multi-session. To learn more, see Azure Virtual Desktop
pricing .
Why does my application report

Windows 10 Enterprise multi-session as
a Server operating system?
Windows 10 Enterprise multi-session is a virtual edition of Windows 10 Enterprise. One
of the differences is that this operating system (OS) reports the ProductType as having a
value of 3, the same value as Windows Server. This property keeps the OS compatible
with existing RDSH management tooling, RDSH multi-session-aware applications, and
mostly low-level system performance optimizations for RDSH environments. Some
application installers can block installation on Windows 10 multi-session depending on
whether they detect the ProductType is set to Client. If your app won't install, contact
your application vendor for an updated version.
Can I run Windows 10 or Windows 11

Enterprise multi-session outside of the
Azure Virtual Desktop service?
We don't allow customers to run Windows 10 or 11 Enterprise multi-session in
production environments outside of the Azure Virtual Desktop service. Only Microsoft or
the Azure Virtual Desktop Approved Providers, Citrix and VMware, can provide access to
the Azure Virtual Desktop service. It's against the licensing agreement to run Windows
10 or 11 multi-session outside of the Azure Virtual Desktop service for production
purposes. Windows 10 and 11 multi-session also won’t activate against on-premises Key
Management Services (KMS).
Can I upgrade a Windows 10 VM to

Windows 10 Enterprise multi-session?
No. It's not currently possible to upgrade an existing virtual machine (VM) that's running
Windows 10 Professional or Enterprise to Windows 10 Enterprise multi-session. Also, if
you deploy a Windows 10 Enterprise multi-session VM and then update the product key
to another edition, you won't be able to switch the VM back to Windows 10 Enterprise
multi-session and will need to redeploy the VM. Changing your Azure Virtual Desktop
VM SKU to another edition is not supported.
Does Windows 10 Enterprise multi-

session support Remote Desktop IP
Virtualization?
No. Azure Virtual Desktop supported virtual machine OS images do not support Remote
Desktop IP Virtualization.
How do I customize the Windows 10

Enterprise multi-session image for my
organization?
You can start a VM in Azure with Windows 10 Enterprise multi-session and customize it
by installing LOB applications, sysprep/generalize, and then create an image using the
Azure portal.
To get started, create a VM in Azure with Windows 10 Enterprise multi-session. Instead

of starting the VM in Azure, you can download the VHD directly. After that, you'll be
able to use the VHD you downloaded to create a new Generation 1 VM on a Windows
10 PC with Hyper-V enabled.
Customize the image to your needs by installing LOB applications and sysprep the
image. When you're done customizing, upload the image to Azure with the VHD inside.
After that, get Azure Virtual Desktop from the Azure Marketplace and use it to deploy a
new host pool with the customized image.
How do I manage Windows 10

Enterprise multi-session after
deployment?
You can use any supported configuration tool, but we recommend Configuration
Manager version 1906 because it supports Windows 10 Enterprise multi-session or
Microsoft Intune for Azure AD-joined or Hybrid Azure AD-joined session hosts.
Can Windows 10 Enterprise multi-

session be Azure Active Directory (Azure
AD)-joined?
Windows 10 Enterprise multi-session can be Azure AD-joined. To get started, follow the
steps to Deploy Azure AD-joined virtual machines.
Where can I find the Windows 10
Enterprise multi-session image?
Windows 10 Enterprise multi-session is in the Azure gallery. To find it, navigate to the
Azure portal and search for the Windows 10 Enterprise for Virtual Desktops release. For
an image integrated with Microsoft 365 Apps for enterprise, go to the Azure portal and
search for Microsoft Windows 10 + Microsoft 365 Apps for enterprise.
Which Windows 10 Enterprise multi-

session image should I use?
The Azure gallery has several releases, including Windows 10 Enterprise multi-session,
version 1909, and Windows 10 Enterprise multi-session, version 1903. We recommend
using the latest version for improved performance and reliability.
Which Windows 10 Enterprise multi-

session versions are supported?
Windows 10 Enterprise multi-session, versions 1909 and later are supported and are
available in the Azure gallery. These releases follow the same support lifecycle policy as
Windows 10 Enterprise, which means the March release is supported for 18 months and
the September release for 30 months.
Which profile management solution

should I use for Windows 10 Enterprise
multi-session?
We recommend you use FSLogix profile containers when you configure Windows 10
Enterprise in non-persistent environments or other scenarios that need a centrally
stored profile. FSLogix ensures the user profile is available and up-to-date for every user
session. We also recommend you use your FSLogix profile container to store a user
profile in any SMB share with appropriate permissions, but you can store user profiles in
Azure page blob storage if necessary. Azure Virtual Desktop users can use FSLogix at no
additional cost. FSLogix comes pre-installed on all Windows 10 Enterprise multi-session
images, but the IT admin is still responsible for configuring the FSLogix profile container.
For more information about how to configure an FSLogix profile container, see
Configure the FSLogix profile container.
Which license do I need to access

Windows 10 Enterprise multi-session?
For a full list of applicable licenses, see Azure Virtual Desktop pricing .
Why do my apps disappear after I sign

out?
This happens because you're using Windows 10 Enterprise multi-session with a profile
management solution like FSLogix. Your admin or profile solution configured your
system to delete user profiles when users sign out. This configuration means that when
your system deletes your user profile after you sign out, it also removes any apps you
installed during your session. If you want to keep the apps you installed, you'll need to
ask your admin to provision these apps for all users in your Azure Virtual Desktop
environment.
How do I make sure apps don't

disappear when users sign out?
Most virtualized environments are configured by default to prevent users from installing
additional apps to their profiles. If you want to make sure an app doesn't disappear
when your user signs out of Azure Virtual Desktop, you have to provision that app for all
user profiles in your environment. For more information about provisioning apps, check
out these resources:
Publish built-in apps in Azure Virtual Desktop

DISM app package servicing command-line options
Add-AppxProvisionedPackage
How do I make sure users don't

download and install apps from the
Microsoft Store?
You can disable the Microsoft Store app to make sure users don't download extra apps
beyond the apps you've already provisioned for them.
To disable the Store app:
1. Create and edit a new Group Policy Object.

2. Select Computer Configuration > Policies > Administrative Templates >
Windows Components > Store.
3. Open the Turn off the Store Application setting.
4. Select the Enabled option.
5. Click the Apply button.
6. Click the OK button.
Can Windows 10 Enterprise multi-

session and 11 Enterprise multi-session
receive feature updates through
Windows Server Update Services
(WSUS)?
Yes. You can update Windows 10 Enterprise multi-session and Windows 11 Enterprise
multi-session with the appropriate feature updates published to WSUS.
Next steps
To learn more about Azure Virtual Desktop and Windows 10 Enterprise multi-session:
Read our Azure Virtual Desktop documentation

Visit our Azure Virtual Desktop TechCommunity
Set up your Azure Virtual Desktop deployment with the Azure Virtual Desktop
tutorials
Fair Share technologies are enabled by
default in Remote Desktop Services
This article describes how a Remote Desktop Session Host (RDSH) server, Windows 10
Enterprise multi-session and Windows 11 Enterprise multi-session use Fair Share
technologies to balance CPU, disk, and network bandwidth resources among multiple
Remote Desktop sessions.
Applies to: Windows Server 2016, Windows Server 2012 R2, Windows 10 Enterprise
multi-session, Windows 11 Enterprise multi-session
Original KB number: 4494631
Introduction
Fair Share technologies for CPU resources were introduced in Windows Server 2008 R2.
Remote Desktop Services (RDS) server, Windows 10 Enterprise multi-session and
Windows 11 Enterprise multi-session use Fair Share technology to manage resources.
RDS builds on the Fair Share technologies to add features for allocating network
bandwidth and disk resources. Fair Share technologies are enabled by default, but you
can disable them using Windows PowerShell and WMI.
For more information about the related properties in WMI, see

Win32_TerminalServiceSetting class: Properties.
Fair Share CPU Scheduling

Fair Share CPU Scheduling dynamically distributes processor time across all RDS and
Azure Virtual Desktop (AVD) multi-session sessions on the same Session Host server,
based on the number of sessions and the demand for processor time within each
session. This process creates a consistent user experience across all of the active
sessions, while sessions are being created and deleted dynamically. This feature builds
on the Dynamic Fair Share Scheduling technology (DFSS) that was part of Windows
Server.
Dynamic Disk Fair Share

When disk-intensive processes run in one or more sessions, they can starve non-disk
intensive processes and prevent them from ever accessing disk resources. To fix this
issue, the Dynamic Disk Fair Share feature balances disk access among the different
sessions by balancing disk IO and throttling excess disk usage.
Dynamic Network Fair Share

When bandwidth-intensive applications run in one or more sessions, they can starve
applications in other sessions of bandwidth. To equalize network consumption among
the sessions, the Network Fair Share feature uses a round-robin approach to allocate
bandwidth for each session.
In a centralized computing scenario, the Dynamic Network Fair Share feature tries to
fairly distribute network interface bandwidth load among the sessions.
Feedback
Was this page helpful? ﾂ Yes ﾄ No
Provide product feedback

| Get help at Microsoft Q&A
Understanding Azure Virtual Desktop
network connectivity
Azure Virtual Desktop provides the ability to host client sessions on the session hosts
running on Azure. Microsoft manages portions of the services on the customer's behalf
and provides secure endpoints for connecting clients and session hosts. The diagram
below gives a high-level overview of the network connections used by Azure Virtual
Desktop
Azure Virtual Desktop Network Connections
Active Directory connectivity

Reverse Connect Transport (TCP
443)
Feed subscription (TCP 443)

Client Session Host
Azure AD Authentication (TCP 443)
RD Agent communication (TCP 443)

RD Agent communication
RDP data (TLS)

Reverse Connect Transport
Azure AD Authentication
Active Directory
Feed subscription
Internal service traffic

Domain Services
(TCP 443)
(TCP 443)
(TCP 443)
Azure AD Connect Sync (TCP 443)

RDP Data (TLS)
(TCP 443)
Local Active Directory connectivity

TCP 443
(various)
RD Web
Public Internet
Azure AD Connect sync
TCP 443
RD Gateway RD Broker

Infrastructure
Azure Active Directory 
Session connectivity
Azure Virtual Desktop uses Remote Desktop Protocol (RDP) to provide remote display
and input capabilities over network connections. RDP was initially released with
Windows NT 4.0 Terminal Server Edition and was continuously evolving with every
Microsoft Windows and Windows Server release. From the beginning, RDP developed to
be independent of its underlying transport stack, and today it supports multiple types of
transport.
Reverse connect transport
Azure Virtual Desktop is using reverse connect transport for establishing the remote
session and for carrying RDP traffic. Unlike the on-premises Remote Desktop Services
deployments, reverse connect transport doesn't use a TCP listener to receive incoming
RDP connections. Instead, it is using outbound connectivity to the Azure Virtual Desktop
infrastructure over the HTTPS connection.
Session host communication channel

Upon startup of the Azure Virtual Desktop session host, the Remote Desktop Agent
Loader service establishes the Azure Virtual Desktop broker's persistent communication
channel. This communication channel is layered on top of a secure Transport Layer
Security (TLS) connection and serves as a bus for service message exchange between
session host and Azure Virtual Desktop infrastructure.
Client connection sequence

Client connection sequence described below:
1. Using supported Azure Virtual Desktop client user subscribes to the Azure Virtual
Desktop Workspace
2. Azure Active Directory authenticates the user and returns the token used to
enumerate resources available to a user
3. Client passes token to the Azure Virtual Desktop feed subscription service
4. Azure Virtual Desktop feed subscription service validates the token
5. Azure Virtual Desktop feed subscription service passes the list of available
desktops and RemoteApps back to the client in the form of digitally signed
connection configuration
6. Client stores the connection configuration for each available resource in a set of
.rdp files
7. When a user selects the resource to connect, the client uses the associated .rdp file
and establishes the secure TLS 1.2 connection to the closest Azure Virtual Desktop
gateway instance and passes the connection information
8. Azure Virtual Desktop gateway validates the request and asks the Azure Virtual
Desktop broker to orchestrate the connection
9. Azure Virtual Desktop broker identifies the session host and uses the previously
established persistent communication channel to initialize the connection
10. Remote Desktop stack initiates the TLS 1.2 connection to the same Azure Virtual
Desktop gateway instance as used by the client
11. After both client and session host connected to the gateway, the gateway starts
relaying the raw data between both endpoints, this establishes the base reverse
connect transport for the RDP
12. After the base transport is set, the client starts the RDP handshake
Connection security
TLS 1.2 is used for all connections initiated from the clients and session hosts to the
Azure Virtual Desktop infrastructure components. Azure Virtual Desktop uses the same
TLS 1.2 ciphers as Azure Front Door. It's important to make sure both client computers
and session hosts can use these ciphers.
For reverse connect transport, both client and
session host connect to the Azure Virtual Desktop gateway. After establishing the TCP
connection, the client or session host validates the Azure Virtual Desktop gateway's
certificate.
After establishing the base transport, RDP establishes a nested TLS
connection between client and session host using the session host's certificates. By
default, the certificate used for RDP encryption is self-generated by the OS during the
deployment. If desired, customers may deploy centrally managed certificates issued by
the enterprise certification authority. For more information about configuring
certificates, see Windows Server documentation.
Next steps
To learn about bandwidth requirements for Azure Virtual Desktop, see
Understanding Remote Desktop Protocol (RDP) Bandwidth Requirements for Azure
Virtual Desktop.
To get started with Quality of Service (QoS) for Azure Virtual Desktop, see
Implement Quality of Service (QoS) for Azure Virtual Desktop.
RDP Shortpath for Azure Virtual
Desktop
） Important
Using RDP Shortpath for public networks with TURN for Azure Virtual Desktop is
currently in PREVIEW. See the Supplemental Terms of Use for Microsoft Azure
Previews for legal terms that apply to Azure features that are in beta, preview, or
otherwise not yet released into general availability.
Connections to Azure Virtual Desktop use Transmission Control Protocol (TCP) or User
Datagram Protocol (UDP). RDP Shortpath is a feature of Azure Virtual Desktop that
establishes a direct UDP-based transport between a supported Windows Remote
Desktop client and session host. By default, Remote Desktop Protocol (RDP) tries to
establish connection using UDP and uses a TCP-based reverse connect transport as a
fallback connection mechanism. TCP-based reverse connect transport provides the best
compatibility with various networking configurations and has a high success rate for
establishing RDP connections. UDP-based transport offers better connection reliability
and more consistent latency.
RDP Shortpath can be used in two ways:
1. Managed networks, where direct connectivity is established between the client

and the session host when using a private connection, such as a virtual private
network (VPN).
2. Public networks, where direct connectivity is established between the client and
the session host when using a public connection. There are two connection types
when using a public connection, which are listed here in order of preference:
a. A direct UDP connection using the Simple Traversal Underneath NAT (STUN)
protocol between a client and session host.
b. An indirect UDP connection using the Traversal Using Relay NAT (TURN)
protocol with a relay between a client and session host. This is in preview.
The transport used for RDP Shortpath is based on the Universal Rate Control Protocol
(URCP) . URCP enhances UDP with active monitoring of the network conditions and
provides fair and full link utilization. URCP operates at low delay and loss levels as
needed.
） Important
During the preview, TURN is only available for connections to session hosts in a
validation host pool. To configure your host pool as a validation environment, see
Define your host pool as a validation environment.
Key benefits
Using RDP Shortpath has the following key benefits:
Using URCP to enhance UDP achieves the best performance by dynamically

learning network parameters and providing the protocol with a rate control
mechanism.
The removal of extra relay points reduces round-trip time, which improves
connection reliability and user experience with latency-sensitive applications and
input methods.
In addition, for managed networks:
RDP Shortpath brings support for configuring Quality of Service (QoS) priority
for RDP connections through Differentiated Services Code Point (DSCP) marks.
The RDP Shortpath transport allows limiting outbound network traffic by

specifying a throttle rate for each session.
How RDP Shortpath works

To learn how RDP Shortpath works for managed networks and public networks, select
each of the following tabs.
Managed networks
You can achieve the direct line of sight connectivity required to use RDP Shortpath
with managed networks using the following methods.
ExpressRoute private peering
Site-to-site or Point-to-site VPN (IPsec), such as Azure VPN Gateway

Having direct line of sight connectivity means that the client can connect directly to
the session host without being blocked by firewalls.
７ Note
If you're using other VPN types to connect to Azure, we recommend using a

UDP-based VPN. While most TCP-based VPN solutions support nested UDP,
they add inherited overhead of TCP congestion control, which slows down RDP
performance.
To use RDP Shortpath for managed networks, you must enable a UDP listener on
your session hosts. By default, port 3390 is used, although you can use a different
port.
The following diagram gives a high-level overview of the network connections

when using RDP Shortpath for managed networks and session hosts joined to an
Active Directory domain.
RDP Shortpath Network Connections
RDP Shortpath (UDP 3390) Active Directory connectivity

Reverse Connect Transport (TCP
443)
Feed subscription (TCP 443)

Client Session Host
Azure AD Authentication (TCP 443)
RD Agent communication (TCP 443)

RD Agent communication
RDP Shortpath (UDP 3390)

Azure AD Authentication
Active Directory
Feed subscription
Internal service traffic

Domain Services
(TCP 443)
(TCP 443)
(TCP 443)
Azure AD Connect Sync (TCP 443)

(TCP 443)
Local Active Directory connectivity

TCP 443
(various)
RD Web
Public Internet
Azure AD Connect sync
TCP 443
RD Gateway RD Broker

Infrastructure
Azure Active Directory 
Connection sequence
All connections begin by establishing a TCP-based reverse connect transport over
the Azure Virtual Desktop Gateway. Then, the client and session host establish the
initial RDP transport, and start exchanging their capabilities. These capabilities are
negotiated using the following process:
1. The session host sends the list of its IPv4 and IPv6 addresses to the client.
2. The client starts the background thread to establish a parallel UDP-based

transport directly to one of the session host's IP addresses.
3. While the client is probing the provided IP addresses, it continues to establish

the initial connection over the reverse connect transport to ensure there's no
delay in the user connection.
4. If the client has a direct connection to the session host, the client establishes a
secure connection using TLS over reliable UDP.
5. After establishing the RDP Shortpath transport, all Dynamic Virtual Channels
(DVCs), including remote graphics, input, and device redirection, are moved to
the new transport. However, if a firewall or network topology prevents the
client from establishing direct UDP connectivity, RDP continues with a reverse
connect transport.
If your users have both RDP Shortpath for managed network and public networks
available to them, then the first-found algorithm will be used. The user will use
whichever connection gets established first for that session.
Connection security
RDP Shortpath extends RDP multi-transport capabilities. It doesn't replace the reverse
connect transport but complements it. Initial session brokering is managed through the
Azure Virtual Desktop service and the reverse connect transport. All connection
attempts are ignored unless they match the reverse connect session first. RDP Shortpath
is established after authentication, and if successfully established, the reverse connect
transport is dropped and all traffic flows over the RDP Shortpath.
RDP Shortpath uses a secure connection using TLS over reliable UDP between the client
and the session host using the session host's certificates. By default, the certificate used
for RDP encryption is self-generated by the operating system during the deployment.
You can also deploy centrally managed certificates issued by an enterprise certification
authority. For more information about certificate configurations, see Remote Desktop
listener certificate configurations.
７ Note
The security offered by RDP Shortpath is the same as that offered by TCP reverse
connect transport.
Example scenarios
Here are some example scenarios to show how connections are evaluated to decide
whether RDP Shortpath is used across different network topologies.
Scenario 1
A UDP connection can only be established between the client device and the session
host over a public network (internet). A direct connection, such as a VPN, isn't available.
UDP is allowed through firewall or NAT device.
Scenario 2
A firewall or NAT device is blocking a direct UDP connection, but an indirect UDP
connection can be relayed using TURN between the client device and the session host
over a public network (internet). Another direct connection, such as a VPN, isn't
available.
Scenario 3
A UDP connection can be established between the client device and the session host
over a public network or over a direct VPN connection, but RDP Shortpath for managed
networks isn't enabled. When the client initiates the connection, the ICE/STUN protocol
can see multiple routes and will evaluate each route and choose the one with the lowest
latency.
In this example, a UDP connection using RDP Shortpath for public networks over the
direct VPN connection will be made as it has the lowest latency, as shown by the green
line.
Scenario 4
Both RDP Shortpath for public networks and managed networks are enabled. A UDP
connection can be established between the client device and the session host over a
public network or over a direct VPN connection. When the client initiates the
connection, there are simultaneous attempts to connect using RDP Shortpath for
managed networks through port 3390 (by default) and RDP Shortpath for public
networks through the ICE/STUN protocol. The first-found algorithm will be used and the
user will use whichever connection gets established first for that session.
Since going over a public network has more steps, for example a NAT device, a load
balancer, or a STUN server, it's likely that the first-found algorithm will select the
connection using RDP Shortpath for managed networks and be established first.
Scenario 5
A UDP connection can be established between the client device and the session host
over a public network or over a direct VPN connection, but RDP Shortpath for managed
networks isn't enabled. To prevent ICE/STUN from using a particular route, an admin can
block one of the routes for UDP traffic. Blocking a route would ensure the remaining
path is always used.
In this example, UDP is blocked on the direct VPN connection and the ICE/STUN
protocol establishes a connection over the public network.
Scenario 6
Both RDP Shortpath for public networks and managed networks are configured,
however a UDP connection couldn't be established using direct VPN connection. A
firewall or NAT device is also blocking a direct UDP connection using the public network
(internet), but an indirect UDP connection can be relayed using TURN between the client
device and the session host over a public network (internet).
Scenario 7
Both RDP Shortpath for public networks and managed networks are configured,
however a UDP connection couldn't be established. In this instance, RDP Shortpath will
fail and the connection will fall back to TCP-based reverse connect transport.
Next steps
Learn how to Configure RDP Shortpath.
Learn more about Azure Virtual Desktop network connectivity at Understanding
Azure Virtual Desktop network connectivity.
Understand Azure egress network charges .
To understand how to estimate the bandwidth used by RDP, see RDP bandwidth
requirements.
 Documentation
Configure RDP Shortpath - Azure Virtual Desktop

Learn how to configure RDP Shortpath for Azure Virtual Desktop, which establishes a UDP-based
transport between a Remote Desktop client and session host.
Understanding Azure Virtual Desktop network connectivity - Azure

Learn about Azure Virtual Desktop network connectivity
Implement Quality of Service (QoS) for Azure Virtual Desktop - Azure

How to set up QoS for Azure Virtual Desktop.

Analyze connection quality in Azure Virtual Desktop - Azure

Connection quality for Azure Virtual Desktop users.
Required URLs for Azure Virtual Desktop

A list of URLs you must unblock to ensure your Azure Virtual Desktop deployment works as intended.
Set up Private Link for Azure Virtual Desktop preview - Azure

How to set up Private Link for Azure Virtual Desktop (preview).
Use the Required URL Check tool for Azure Virtual Desktop
The Required URL Check tool enables you to check your session host virtual machines can access the
required URLs to ensure Azure Virtual Desktop works as intended.
Show 5 more
 Training
Module
Implement and manage networking for Azure Virtual Desktop - Training
Implement and manage networking for Azure Virtual Desktop
Implement Quality of Service (QoS) for
RDP Shortpath for managed networks provides a direct UDP-based transport between
Remote Desktop Client and Session host. RDP Shortpath for managed networks enables
configuration of Quality of Service (QoS) policies for the RDP data.
QoS in Azure Virtual
Desktop allows real-time RDP traffic that's sensitive to network delays to "cut in line" in
front of traffic that's less sensitive. Example of such less sensitive traffic would be a
downloading a new app, where an extra second to download isn't a large deal. QoS uses
Windows Group Policy Objects to identify and mark all packets in real-time streams and
help your network to give RDP traffic a dedicated portion of bandwidth.
If you support a large group of users experiencing any of the problems described in this
article, you probably need to implement QoS. A small business with few users might not
need QoS, but it should be helpful even there.
Without some form of QoS, you might see the following issues:
Jitter – RDP packets arriving at different rates, which can result in visual and audio
glitches
Packet loss – packets dropped, which results in retransmission that requires
additional time
Delayed round-trip time (RTT) – RDP packets taking a long time to reach their
destinations, which result in noticeable delays between input and reaction from the
remote application.
The least complicated way to address these issues is to increase the data connections'
size, both internally and out to the internet. Since that is often cost-prohibitive, QoS
provides a way to manage the resources you have instead of adding bandwidth more
effectively. To address quality issues, we recommend that you first use QoS, then add
bandwidth only where necessary.
For QoS to be effective, you must apply consistent QoS settings throughout your
organization. Any part of the path that fails to support your QoS priorities can degrade
the quality RDP session.
Introduction to QoS queues

To provide QoS, network devices must have a way to classify traffic and must be able to
distinguish RDP from other network traffic.
When network traffic enters a router, the traffic is placed into a queue. If a QoS policy
isn't configured, there is only one queue, and all data is treated as first-in, first-out with
the same priority. That means RDP traffic might get stuck behind traffic where a few
extra milliseconds delay wouldn't be a problem.
When you implement QoS, you define multiple queues using one of several congestion
management features, such as Cisco’s priority queuing and Class-Based Weighted Fair
Queueing (CBWFQ) and congestion avoidance features, such as weighted random
early detection (WRED) .
A simple analogy is that QoS creates virtual "carpool lanes" in your data network. So
some types of data never or rarely encounter a delay. Once you create those lanes, you
can adjust their relative size and much more effectively manage the connection
bandwidth you have while still delivering business-grade experiences for your
organization's users.
QoS implementation checklist

At a high level, do the following to implement QoS:
1. Make sure your network is ready

2. Make sure that RDP Shortpath for managed networks is enabled - QoS policies are
not supported for reverse connect transport
3. Implement insertion of DSCP markers on session hosts
As you prepare to implement QoS, keep the following guidelines in mind:
The shortest path to session host is best

Any obstacles in between, such as proxies or packet inspection devices, aren't
recommended
Make sure your network is ready

If you're considering a QoS implementation, you should already have determined your
bandwidth requirements and other network requirements.
Traffic congestion across a network will significantly impact media quality. A lack of
bandwidth leads to performance degradation and a poor user experience. As Azure
Virtual Desktop adoption and usage grows, use Log Analytics to identify problems and
then make adjustments using QoS and selective bandwidth additions.
VPN considerations
QoS only works as expected when implemented on all links between clients and session
hosts. If you use QoS on an internal network and a user signs in from a remote location,
you can only prioritize within your internal, managed network. Although remote
locations can receive a managed connection by implementing a virtual private network
(VPN), a VPN inherently adds packet overhead and creates delays in real-time traffic.
In a global organization with managed links that span continents, we strongly

recommend QoS because bandwidth for those links is limited compared to the LAN.
Insert DSCP markers

You could implement QoS using a Group Policy Object (GPO) to direct session hosts to
insert a DSCP marker in IP packet headers identifying it as a particular type of traffic.
Routers and other network devices can be configured to recognize these markings and
put the traffic in a separate, higher-priority queue.
You can compare DSCP markings to postage stamps that indicate to postal workers how
urgent the delivery is and how best to sort it for speedy delivery. Once you've
configured your network to give priority to RDP streams, lost packets and late packets
should diminish significantly.
Once all network devices are using the same classifications, markings, and priorities, it's
possible to reduce or eliminate delays, dropped packets, and jitter. From the RDP
perspective, the essential configuration step is the classification and marking of packets.
However, for end-to-end QoS to be successful, you also need to align the RDP
configuration with the underlying network configuration carefully.
The DSCP value tells a
correspondingly configured network what priority to give a packet or stream.
We recommend using DSCP value 46 that maps to Expedited Forwarding (EF) DSCP
class.
Implement QoS on session host using Group Policy

You can use policy-based Quality of Service (QoS) within Group Policy to set the
predefined DSCP value.
To create a QoS policy for domain-joined session hosts, first, sign in to a computer on
which Group Policy Management has been installed. Open Group Policy Management
(select Start, point to Administrative Tools, and then select Group Policy Management),
and then complete the following steps:
1. In Group Policy Management, locate the container where the new policy should be
created. For example, if all your session hosts computers are located in an OU
named "session hosts", the new policy should be created in the Session Hosts OU.
2. Right-click the appropriate container, and then select Create a GPO in this
domain, and Link it here.
3. In the New GPO dialog box, type a name for the new Group Policy object in the
Name box, and then select OK.
4. Right-click the newly created policy, and then select Edit.
5. In the Group Policy Management Editor, expand Computer Configuration, expand

Windows Settings, right-click Policy-based QoS, and then select Create new
policy.
6. In the Policy-based QoS dialog box, on the opening page, type a name for the
new policy in the Name box. Select Specify DSCP Value and set the value to 46.
Leave Specify Outbound Throttle Rate unselected, and then select Next.
7. On the next page, select Only applications with this executable name and enter
the name svchost.exe, and then select Next. This setting instructs the policy to
only prioritize matching traffic from the Remote Desktop Service.
8. On the third page, make sure that both Any source IP address and Any
destination IP address are selected, and then select Next. These two settings
ensure that packets will be managed regardless of which computer (IP address)
sent the packets and which computer (IP address) will receive the packets.
9. On page four, select UDP from the Select the protocol this QoS policy applies to
drop-down list.
10. Under the heading Specify the source port number, select From this source port
or range. In the accompanying text box, type 3390. Select Finish.
The new policies you've created won't take effect until Group Policy has been refreshed
on your session host computers. Although Group Policy periodically refreshes on its
own, you can force an immediate refresh by following these steps:
1. On each session host for which you want to refresh Group Policy, open a
Command Prompt as administrator (Run as administrator).
2. At the command prompt, enter
Console
gpupdate /force
Implement QoS on session host using PowerShell

You can set QoS for RDP Shortpath for managed networks using the PowerShell cmdlet
below:
PowerShell
New-NetQosPolicy -Name "RDP Shortpath for managed networks" -

AppPathNameMatchCondition "svchost.exe" -IPProtocolMatchCondition UDP -
IPSrcPortStartMatchCondition 3390 -IPSrcPortEndMatchCondition 3390 -
DSCPAction 46 -NetworkProfile All
Related articles
Quality of Service (QoS) Policy
Next steps
Virtual Desktop.
To learn about Azure Virtual Desktop network connectivity, see Understanding
In order to deploy and make Azure Virtual Desktop available to your users, you must allow
specific URLs that your session host virtual machines (VMs) can access them anytime.
Users also need to be able to connect to certain URLs to access their Azure Virtual
Desktop resources. This article lists the required URLs you need to allow for your session
hosts and users. These URLs could be blocked if you're using Azure Firewall or a third-
party firewall or proxy service. Azure Virtual Desktop doesn't support deployments that
block the URLs listed in this article.
） Important
Proxy Services that perform the following are not recommended with Azure Virtual
Desktop. See the above link or Table of Contents regarding Proxy Support Guidelines
for further details.
1. SSL Termination (Break and Inspect)

2. Require Authentication
You can validate that your session host VMs can connect to these URLs by following the
steps to run the Required URL Check tool. The Required URL Check tool will validate each
URL and show whether your session host VMs can access them. You can only use for
deployments in the Azure public cloud, it does not check access for sovereign clouds.
Session host virtual machines

The following table is the list of URLs your session host VMs need to access for Azure
Virtual Desktop. Select the relevant tab based on which cloud you're using.
Azure cloud
Address Outbound Purpose Service tag

TCP port
login.microsoftonline.com 443 Authentication

to Microsoft
Online
Services
*.wvd.microsoft.com 443 Service traffic WindowsVirtualDesktop

Address Outbound Purpose Service tag
TCP port
*.prod.warm.ingest.monitor.core.windows.net 443 Agent traffic AzureMonitor
catalogartifact.azureedge.net 443 Azure AzureFrontDoor.Frontend

Marketplace
gcs.prod.monitoring.core.windows.net 443 Agent traffic AzureCloud
kms.core.windows.net 1688 Windows Internet

activation
azkms.core.windows.net 1688 Windows Internet

activation
mrsglobalsteus2prod.blob.core.windows.net 443 Agent and AzureCloud

side-by-side
(SXS) stack
updates
wvdportalstorageblob.blob.core.windows.net 443 Azure portal AzureCloud

support
169.254.169.254 80 Azure Instance N/A

Metadata
service
endpoint
168.63.129.16 80 Session host N/A

health
monitoring
oneocsp.microsoft.com 80 Certificates N/A
www.microsoft.com 80 Certificates N/A
） Important
We've finished transitioning the URLs we use for Agent traffic. We no longer
support the following URLs. To prevent your session host VMs from showing a
Needs Assistance status due to this, you must allow the URL
*.prod.warm.ingest.monitor.core.windows.net if you haven't already. You should
also remove the following URLs if you explicitly allowed them before the change:
Address Outbound TCP Purpose Service

port tag
Address Outbound TCP Purpose Service
port tag
production.diagnostics.monitoring.core.win 443 Agent AzureClo

dows.net traffic ud
*xt.blob.core.windows.net 443 Agent AzureClo

traffic ud
*eh.servicebus.windows.net 443 Agent AzureClo

traffic ud
*xt.table.core.windows.net 443 Agent AzureClo

traffic ud
*xt.queue.core.windows.net 443 Agent AzureClo

traffic ud
The following table lists optional URLs that your session host virtual machines might
also need to access for other services:
Address Outbound Purpose

TCP port
login.windows.net 443 Sign in to Microsoft Online Services and

Microsoft 365
*.events.data.microsoft.com 443 Telemetry Service
www.msftconnecttest.com 443 Detects if the session host is connected

to the internet
*.prod.do.dsp.mp.microsoft.com 443 Windows Update
*.sfx.ms 443 Updates for OneDrive client software
*.digicert.com 443 Certificate revocation check
*.azure-dns.com 443 Azure DNS resolution
*.azure-dns.net 443 Azure DNS resolution
 Tip
You must use the wildcard character (*) for URLs involving service traffic. If you prefer
not to use this for agent-related traffic, here's how to find those specific URLs to use
without specifying wildcards:
1. Ensure your session host virtual machines are registered to a host pool.
2. Open Event viewer, then go to Windows logs > Application > WVD-Agent and
look for event ID 3701.
3. Unblock the URLs that you find under event ID 3701. The URLs under event ID
3701 are region-specific. You'll need to repeat this process with the relevant
URLs for each Azure region you want to deploy your session host virtual
machines in.
This list doesn't include URLs for other services like Azure Active Directory or Office 365.
Azure Active Directory URLs can be found under ID 56, 59 and 125 in Office 365 URLs and
IP address ranges.
Service tags and FQDN tags

A virtual network service tag represents a group of IP address prefixes from a given Azure
service. Microsoft manages the address prefixes encompassed by the service tag and
automatically updates the service tag as addresses change, minimizing the complexity of
frequent updates to network security rules. Service tags can be used in both Network
Security Group (NSG) and Azure Firewall rules to restrict outbound network access. Service
tags can be also used in User Defined Route (UDR) to customize traffic routing behavior.
Azure Firewall supports Azure Virtual Desktop as a FQDN tag. For more information, see
Use Azure Firewall to protect Azure Virtual Desktop deployments.
We recommend you use FQDN tags or service tags instead of URLs to prevent service
issues. The listed URLs and tags only correspond to Azure Virtual Desktop sites and
resources. They don't include URLs for other services like Azure Active Directory. For other
services, see Available service tags.
Azure Virtual Desktop currently doesn't have a list of IP address ranges that you can
unblock to allow network traffic. We only support unblocking specific URLs. If you're using
a Next Generation Firewall (NGFW), you'll need to use a dynamic list specifically made for
Azure IPs to make sure you can connect.
Remote Desktop clients

Any Remote Desktop clients you use to connect to Azure Virtual Desktop must have
access to the following URLs. Select the relevant tab based on which cloud you're using.
Opening these URLs is essential for a reliable client experience. Blocking access to these
URLs is unsupported and will affect service functionality.
Azure cloud
Address Outbound Purpose Client(s)

TCP port
login.microsoftonline.com 443 Authentication to Microsoft All

Online Services
*.wvd.microsoft.com 443 Service traffic All
*.servicebus.windows.net 443 Troubleshooting data All
go.microsoft.com 443 Microsoft FWLinks All
aka.ms 443 Microsoft URL shortener All
learn.microsoft.com 443 Documentation All
privacy.microsoft.com 443 Privacy statement All
query.prod.cms.rt.microsoft.com 443 Client updates Windows

Desktop
These URLs only correspond to client sites and resources. This list doesn't include URLs for
other services like Azure Active Directory or Office 365. Azure Active Directory URLs can be
found under IDs 56, 59 and 125 in Office 365 URLs and IP address ranges.
Next steps
To learn how to unblock these URLs in Azure Firewall for your Azure Virtual Desktop
deployment, see Use Azure Firewall to protect Azure Virtual Desktop.
Remote Desktop Protocol (RDP)
bandwidth requirements
Remote Desktop Protocol (RDP) is a sophisticated technology that uses various

techniques to perfect the server's remote graphics' delivery to the client device.
Depending on the use case, availability of computing resources, and network
bandwidth, RDP dynamically adjusts various parameters to deliver the best user
experience.
Remote Desktop Protocol multiplexes multiple Dynamic Virtual Channels (DVCs) into a
single data channel sent over different network transports. There are separate DVCs for
remote graphics, input, device redirection, printing, and more. Azure Virtual Desktop
partners can also use their extensions that use DVC interfaces.
The amount of the data sent over RDP depends on the user activity. For example, a user
may work with basic textual content for most of the session and consume minimal
bandwidth, but then generate a printout of a 200-page document to the local printer.
This print job will use a significant amount of network bandwidth.
When using a remote session, your network's available bandwidth dramatically impacts
the quality of your experience. Different applications and display resolutions require
different network configurations, so it's essential to make sure your network
configuration meets your needs.
Estimating bandwidth utilization

RDP uses various compression algorithms for different types of data. The table below
guides estimating of the data transfers:
Type of Direction How to estimate

Data
Remote Session host See the detailed guidelines

Graphics to client
Heartbeats Both ~ 20 bytes every 5 seconds

directions
Input Client to Amount of data is based on the user activity, less than 100 bytes for
session Host most of the operations
Type of Direction How to estimate
Data
File Both File transfers are using bulk compression. Use .zip compression for
transfers directions approximation
Printing Session host Print job transfer depends on the driver and using bulk compression,
to client use .zip compression for approximation
Other scenarios can have their bandwidth requirements change depending on how you
use them, such as:
Voice or video conferencing

Real-time communication
Streaming 4K video
Estimating bandwidth used by remote graphics

It's tough to predict bandwidth use by the remote desktop. The user activities generate
most of the remote desktop traffic. Every user is unique, and differences in their work
patterns may significantly change network use.
The best way to understand bandwidth requirements is to monitor real user

connections. Monitoring can be performed by the built-in performance counters or by
the network equipment.
However, in many cases, you may estimate network utilization by understanding how
Remote Desktop Protocol works and by analyzing your users' work patterns.
The remote protocol delivers the graphics generated by the remote server to display it
on a local monitor. More specifically, it provides the desktop bitmap entirely composed
on the server.
While sending a desktop bitmap seems like a simple task at first
approach, it requires a significant amount of resources. For example, a 1080p desktop
image in its uncompressed form is about 8Mb in size. Displaying this image on the
locally connected monitor with a modest screen refresh rate of 30 Hz requires
bandwidth of about 237 MB/s.
To reduce the amount of data transferred over the network, RDP uses the combination
of multiple techniques, including but not limited to
Frame rate optimizations

Screen content classification
Content-specific codecs
Progressive image encoding
Client-side caching
To better understand remote graphics, consider the following:
The richer the graphics, more bandwidth it will take

Text, window UI elements, and solid color areas are consuming less bandwidth
than anything else.
Natural images are the most significant contributors to bandwidth use. But
client-side caching helps with its reduction.
Only changed parts of the screen are transmitted. If there are no visible updates on
the screen, no updates are sent.
Video playback and other high-frame-rate content are essentially an image
slideshow. RDP dynamically uses appropriate video codecs to deliver them with the
close to original frame rate. However, it's still graphics, and it's still the most
significant contributor to bandwidth utilization.
Idle time in remote desktop means no or minimal screen updates; so, network use
is minimal during idle times.
When remote desktop client window is minimized, no graphical updates are sent
from the session host.
Keep in mind that the stress put on your network depends on both your app workload's
output frame rate and your display resolution. If either the frame rate or display
resolution increases, the bandwidth requirement will also rise. For example, a light
workload with a high-resolution display requires more available bandwidth than a light
workload with regular or low resolution. Different display resolutions require different
available bandwidths.
The table below guides estimating of the data used by the different graphic scenarios.
These numbers apply to a single monitor configuration with 1920x1080 resolution and
with both default graphics mode and H.264/AVC 444 graphics mode.
Scenario Default H.264/AVC Thumbnail Description of the scenario

mode 444 mode
Idle 0.3 0.3 Kbps User is paused their work and there's no
Kbps active screen updates
Microsoft 100- 200-300 User is actively working with Microsoft

Word 150 Kbps Word, typing, pasting graphics and
Kbps switching between documents
Microsoft 150- 400-500 User is actively working with Microsoft

Excel 200 Kbps Excel, multiple cells with formulas and
Kbps charts are updated simultaneously
Scenario Default H.264/AVC Thumbnail Description of the scenario
mode 444 mode
Microsoft 4-4.5 1.6-1.8 User is actively working with Microsoft

PowerPoint Mbps Mbps PowerPoint, typing, pasting. User also
modifying rich graphics, and using slide
transition effects
Web 6-6.5 0.9-1 Mbps User is actively working with a graphically

Browsing Mbps rich website that contains multiple static
and animated images. User scrolls the
pages both horizontally and vertically
Image 3.3-3.6 0.7-0.8 User is actively working with the image

Gallery Mbps Mbps gallery application. browsing, zooming,
resizing and rotating images
Video 8.5-9.5 2.5-2.8 User is watching a 30 FPS video that

playback Mbps Mbps consumes 1/2 of the screen
Fullscreen 7.5-8.5 2.5-3.1 User is watching a 30 FPS video that

Video Mbps Mbps maximized to a fullscreen
playback
Dynamic bandwidth allocation

Remote Desktop Protocol is a modern protocol designed to adjust to the changing
network conditions dynamically.
Instead of using the hard limits on bandwidth
utilization, RDP uses continuous network detection that actively monitors available
network bandwidth and packet round-trip time. Based on the findings, RDP dynamically
selects the graphic encoding options and allocates bandwidth for device redirection and
other virtual channels.
This technology allows RDP to use the full network pipe when available and rapidly back
off when the network is needed for something else.
RDP detects that and adjusts image
quality, frame rate, or compression algorithms if other applications request the network.
Limit network bandwidth use with throttle rate

In most scenarios, there's no need to limit bandwidth utilization as limiting may affect
user experience. Yet in the constrained networks you may want to limit network
utilization. Another example is leased networks that are charged for the amount of
traffic used.
In such cases, you could limit an RDP outbound network traffic by specifying a throttle
rate in QoS Policy.
７ Note
Make sure that RDP Shortpath for managed networks is enabled - throttle rate-
limiting are not supported for reverse connect transport.
Implement throttle rate limiting on session host using

Group Policy
You can use policy-based Quality of Service (QoS) within Group Policy to set the
predefined throttle rate.
To create a QoS policy for domain-joined session hosts, first, sign in to a computer on
which Group Policy Management has been installed. Open Group Policy Management
(select Start, point to Administrative Tools, and then select Group Policy Management),
and then complete the following steps:
1. In Group Policy Management, locate the container where the new policy should be
created. For example, if all your session hosts computers are located in an OU
named Session Hosts, the new policy should be created in the Session Hosts OU.
2. Right-click the appropriate container, and then select Create a GPO in this
domain, and Link it here.
3. In the New GPO dialog box, type a name for the new Group Policy object in the
Name box, and then select OK.
4. Right-click the newly created policy, and then select Edit.
5. In the Group Policy Management Editor, expand Computer Configuration, expand

Windows Settings, right-click Policy-based QoS, and then select Create new
policy.
6. In the Policy-based QoS dialog box, on the opening page, type a name for the
new policy in the Name box. Select Specify Outbound Throttle Rate and set the
required value, and then select Next.
7. On the next page, select Only applications with this executable name and enter
the name svchost.exe, and then select Next. This setting instructs the policy to
only prioritize matching traffic from the Remote Desktop Service.
8. On the third page, make sure that both Any source IP address and Any
destination IP address are selected. Select Next. These two settings ensure that
packets will be managed regardless of which computer (IP address) sent the
packets and which computer (IP address) will receive the packets.
9. On page four, select UDP from the Select the protocol this QoS policy applies to
drop-down list.
10. Under the heading Specify the source port number, select From this source port
or range. In the accompanying text box, type 3390. Select Finish.
The new policies you've created won't take effect until Group Policy has been refreshed
on your session host computers. Although Group Policy periodically refreshes on its
own, you can force an immediate refresh by following these steps:
1. On each session host for which you want to refresh Group Policy, open a
Command Prompt as administrator (Run as administrator).
2. At the command prompt, enter
Console
gpupdate /force
Implement throttle rate limiting on session host using

PowerShell
You can set throttle rate for RDP Shortpath for managed networks using the PowerShell
cmdlet below:
PowerShell
New-NetQosPolicy -Name "RDP Shortpath for managed networks" -

AppPathNameMatchCondition "svchost.exe" -IPProtocolMatchCondition UDP -
IPSrcPortStartMatchCondition 3390 -IPSrcPortEndMatchCondition 3390 -
ThrottleRateActionBitsPerSecond 10mb -NetworkProfile All
Next steps
Virtual Desktop.
To get started with Quality of Service (QoS) for Azure Virtual Desktop, see
Implement Quality of Service (QoS) for Azure Virtual Desktop.
Proxy server guidelines for Azure Virtual
Desktop
This article will show you how to use a proxy server with Azure Virtual Desktop. The
recommendations in this article only apply to connections between Azure Virtual
Desktop infrastructure, client, and session host agents. This article doesn't cover network
connectivity for Office, Windows 10, FSLogix, or other Microsoft applications.
What are proxy servers?

We recommend bypassing proxies for Azure Virtual Desktop traffic. Proxies don't make
Azure Virtual Desktop more secure because the traffic is already encrypted. To learn
more about connection security, see Connection security.
Most proxy servers aren't designed for supporting long running WebSocket connections
and may affect connection stability. Proxy server scalability also causes issues because
Azure Virtual Desktop uses multiple long-term connections. If you do use proxy servers,
they must be the right size to run these connections.
If the proxy server's geography is far from the host, then this distance will cause more
latency in your user connections. More latency means slower connection time and worse
user experience, especially in scenarios that need graphics, audio, or low-latency
interactions with input devices. If you must use a proxy server, keep in mind that you
need to place the server in the same geography as the Azure Virtual Desktop Agent and
client.
If you configure your proxy server as the only path for Azure Virtual Desktop traffic to
take, the Remote Desktop Protocol (RDP) data will be forced over Transmission Control
Protocol (TCP) instead of User Datagram Protocol (UDP). This move lowers the visual
quality and responsiveness of the remote connection.
In summary, we don't recommend using proxy servers on Azure Virtual Desktop because
they cause performance-related issues from latency degradation and packet loss.
Bypassing a proxy server

If your organization's network and security policies require proxy servers for web traffic,
you can configure your environment to bypass Azure Virtual Desktop connections while
still routing the traffic through the proxy server. However, each organization's policies
are unique, so some methods may work better for your deployment than others. Here
are some configuration methods you can try to prevent performance and reliability loss
in your environment:
Azure service tags on the Azure firewall

Proxy server bypass using Proxy Auto Configuration (.PAC) files
Bypass list in the local proxy configuration
Using proxy servers for per-user configuration
Using RDP Shortpath for the RDP connection while keeping the service traffic over
the proxy
Recommendations for using proxy servers

Some organizations require that all user traffic goes through a proxy server for tracking
or packet inspection. This section describes how we recommend configuring your
environment in these cases.
Use proxy servers in the same Azure geography

When you use a proxy server, it handles all communication with the Azure Virtual
Desktop infrastructure and performs DNS resolution and Anycast routing to the nearest
Azure Front Door. If your proxy servers are distant or distributed across an Azure
geography, your geographical resolution will be less accurate. Less accurate
geographical resolution means connections will be routed to a more distant Azure
Virtual Desktop cluster. To avoid this issue, only use proxy servers that are
geographically close to your Azure Virtual Desktop cluster.
Use RDP Shortpath for managed networks for desktop

connectivity
When you enable RDP Shortpath for managed networks, RDP data will bypass the proxy
server, if possible. Bypassing the proxy server ensures optimal routing while using the
UDP transport. Other Azure Virtual Desktop traffic, such as brokering, orchestration, and
diagnostics will still go through the proxy server.
Don't use SSL termination on the proxy server

Secure Sockets Layer (SSL) termination replaces security certificates of the Azure Virtual
Desktop components with certificates generated by proxy server. This proxy server
feature enables packet inspection for HTTPS traffic on the proxy server. However, packet
inspection also increases the service response time, making it take longer for users to
sign in. For reverse-connect scenarios, RDP traffic packet inspection isn't necessary
because reverse-connect RDP traffic is binary and uses extra levels of encryption.
If you configure your proxy server to use SSL inspection, remember that you can't revert
your server to its original state after the SSL inspection makes changes. If something in
your Azure Virtual Desktop environment stops working while you have SSL inspection
enabled, you must disable SSL inspection and try again before you open a support case.
SSL inspection can also cause the Azure Virtual Desktop agent to stop working because
it interferes with trusted connections between the agent and the service.
Don't use proxy servers that need authentication

Azure Virtual Desktop components on the session host run in the context of their
operating system, so they don't support proxy servers that require authentication. If the
proxy server requires authentication, the connection will fail.
Plan for the proxy server network capacity

Proxy servers have capacity limits. Unlike regular HTTP traffic, RDP traffic has long
running, chatty connections that are bi-directional and consume lots of bandwidth.
Before you set up a proxy server, talk to your proxy server vendor about how much
throughput your server has. Also make sure to ask them how many proxy sessions you
can run at one time. After you deploy the proxy server, carefully monitor its resource use
for bottlenecks in Azure Virtual Desktop traffic.
Proxy servers and Teams optimization

Azure Virtual Desktop doesn't support proxy servers for Teams optimization.
Session host configuration recommendations

To configure a session host level proxy server, you need to enable a systemwide proxy.
Remember that systemwide configuration affects all OS components and applications
running on the session host. The following sections are recommendations for
configuring systemwide proxies.
Use the Web Proxy Auto-Discovery (WPAD) protocol

The Azure Virtual Desktop agent automatically tries to locate a proxy server on the
network using the Web Proxy Auto-Discovery (WPAD) protocol. During a location
attempt, the agent searches the domain name server (DNS) for a file named
wpad.domainsuffix. If the agent finds the file in the DNS, it makes an HTTP request for a
file named wpad.dat. The response becomes the proxy configuration script that chooses
the outbound proxy server.
To configure your network to use DNS resolution for WPAD, follow the instructions in
Auto detect settings Internet Explorer 11. Make sure the DNS server global query
blocklist allows the WPAD resolution by following the directions in Set-
DnsServerGlobalQueryBlockList.
Manually set a device-wide proxy for Windows services

You can set a device-wide proxy or Proxy Auto Configuration (.PAC) file that applies to
all interactive, Local System, and Network Service users with the Network Proxy CSP.
In addition you will need to set a proxy for the Windows services RDAgent and Remote
Desktop Services. RDAgent runs with the account Local System and Remote Desktop
Services runs with the account Network Service. You can set a proxy for these accounts
by running the following commands, changing the placeholder value for <server> with
your own address:
Console
bitsadmin /util /setieproxy LOCALSYSTEM AUTOSCRIPT http://<server>/proxy.pac
bitsadmin /util /setieproxy NETWORKSERVICE AUTOSCRIPT

http://<server>/proxy.pac
Client-side proxy support

The Azure Virtual Desktop client supports proxy servers configured with system settings
or a Network Proxy CSP.
Azure Virtual Desktop client support

The following table shows which Azure Virtual Desktop clients support proxy servers:
Client name Proxy server support
Windows Desktop Yes

Client name Proxy server support
Web client Yes
Android No
iOS Yes
macOS Yes
Windows Store Yes
For more information about proxy support on Linux based thin clients, see Thin client
support.
Support limitations
There are many third-party services and applications that act as a proxy server. These
third-party services include distributed next-gen firewalls, web security systems, and
basic proxy servers. We can't guarantee that every configuration is compatible with
Azure Virtual Desktop. Microsoft only provides limited support for connections
established over a proxy server. If you're experiencing connectivity issues while using a
proxy server, Microsoft support recommends you configure a proxy bypass and then try
to reproduce the issue.
Next steps
For more information about keeping your Azure Virtual Desktop deployment secure,
check out our security guide.
 Documentation

Use Azure Private Link with Azure Virtual Desktop preview - Azure
Learn how Azure Private Link (preview) can help you keep network traffic private.

RDP Shortpath - Azure Virtual Desktop
Learn about RDP Shortpath for Azure Virtual Desktop, which establishes a UDP-based transport
between a Remote Desktop client and session host.
Azure Virtual Desktop terminology - Azure

Learn about the basic elements of Azure Virtual Desktop, like host pools, app groups, and
workspaces.


Show 5 more
 Training
Analyze connection quality in Azure
Virtual Desktop
） Important
The Connection Graphics Data Logs are currently in preview. See the Supplemental
Terms of Use for Microsoft Azure Previews for legal terms that apply to Azure
features that are in beta, preview, or otherwise not yet released into general
availability.
Azure Virtual Desktop helps users host client sessions on their session hosts running on
Azure. When a user starts a session, they connect from their local device over a network
to access the session host. It's important that the user experience feels as much like a
local session on a physical device as possible. In this article, we'll talk about how you can
measure your connection network and connection graphics to improve the connection
quality of your end-users.
You can analyze connection quality in your Azure Virtual Desktop deployment by using
Azure Log Analytics. This article will tell you how you can use Azure Log Analytics to
optimize graphics quality and improve end-user experience.
Azure Virtual Desktop uses Azure Front Door to redirect the user connection to the
nearest Azure Virtual Desktop gateway based on the source IP address. Azure Virtual
Desktop will always use the Azure Virtual Desktop gateway that the client chooses.
The connection network and graphics data that Azure Log Analytics collects can help
you discover areas that impact your end-user's graphical experience. The service collects
data for reports regularly throughout the session. You can also use RemoteFX network
performance counters to get some graphics-related performance data from your
deployment, but they're not quite as comprehensive as Azure Log Analytics. Azure
Virtual Desktop connection network data reports have the following advantages over
RemoteFX network performance counters:
Each record is connection-specific and includes the correlation ID of the

connection that can be tied back to the user.
The round trip time measured in this table is protocol-agnostic and will record the
measured latency for Transmission Control Protocol (TCP) or User Datagram
Protocol (UDP) connections.
Connection network data
The network data you collect for your data tables using the NetworkData table includes
the following information:
The estimated available bandwidth (kilobytes per second) is the average

estimated available network bandwidth during each connection time interval.
The estimated round trip time (milliseconds) is the average estimated round trip
time during each connection time interval. Round trip time is how long a network
request takes to go from the end-user's device to the session host through the
network, then return from the session host to the end-user device.
The Correlation ID is the ActivityId of a specific Azure Virtual Desktop connection

that's assigned to every diagnostic within that connection.
The time generated is a timestamp in Coordinated Universal Time (UTC) time that
marks when an event the data counter is tracking happened on the virtual machine
(VM). All averages are measured by the time window that ends at the marked
timestamp.
The Resource ID is a unique ID assigned to the Azure Virtual Desktop host pool
associated with the data the diagnostics service collects for this table.
The source system, Subscription ID, Tenant ID, and type (table name).
Frequency
The service generates these network data points every two minutes during an active
session.
The ConnectionGraphicsData table (preview)

You should consult the ConnectionGraphicsData table (preview) when users report slow
or choppy experiences in their Azure Virtual Desktop sessions. The
ConnectionGraphicsData table will give you useful information whenever graphical
indicators, end-to-end delay, and dropped frames percentage fall below the "healthy"
threshold for Azure Virtual Desktop. This table will help your admins track and
understand factors across the server, client, and network that could be contributing to
the user's slow or choppy experience. However, while the ConnectionGraphicsData table
is a useful tool for troubleshooting poor user experience, since it's not regularly
populated throughout a session, it isn't a reliable environment baseline.
The Graphics table only captures performance data from the Azure Virtual Desktop
graphics stream. This table doesn't capture performance degradation or "slowness"
caused by application-specific factors or the virtual machine (CPU or storage
constraints). You should use this table with other VM performance metrics to determine
if the delay is caused by the remote desktop service (graphics and network) or
something inherent in the VM or app itself.
The graphics data you collect for your data tables includes the following information:
The Last evaluated connection time interval is the two minutes leading up to the
time graphics indicators fell below the quality threshold.
The end-to-end delay (milliseconds) is the delay in the time between when a
frame is captured on the server until the time frame is rendered on the client,
measured as the sum of the encoding delay on the server, network delay, the
decoding delay on the client, and the rendering time on the client. The delay
reflected is the highest (worst) delay recorded in the last evaluated connection
time interval.
The compressed frame size (bytes) is he compressed size of the frame with the
highest end-to-end delay in the last evaluated connection time interval.
The encoding delay on the server (milliseconds) is the time it takes to encode the
frame with the highest end-to-end delay in the last evaluated connection time
interval on the server.
The decoding delay on the client (milliseconds) is the time it takes to decode the
interval on the client.
The rendering delay on the client (milliseconds) is the time it takes to render the
interval on the client.
The percentage of frames skipped is the total percentage of frames dropped by

these three sources:
The client (slow client decoding).
The network (insufficient network bandwidth).
The server (the server is busy).
The recorded values (one each for client, server, and network) are from the second
with the highest dropped frames in the last evaluated connection time interval.
The estimated available bandwidth (kilobytes per second) is the average
estimated available network bandwidth during the second with the highest end-
to-end delay in the time interval.
The estimated round trip time (milliseconds), which is the average estimated
round trip time during the second with the highest end-to-end delay in the time
interval. Round trip time is how long a network request takes to go from the end-
user's device to the session host through the network, then return from the session
host to the end-user device.
The Correlation ID, which is the ActivityId of a specific Azure Virtual Desktop
connection that's assigned to every diagnostic within that connection.
The time generated, which is a timestamp in UTC time that marks when an event
the data counter is tracking happened on the virtual machine (VM). All averages
are measured by the time window that ends that the marked timestamp.
The Resource ID is a unique ID assigned to the Azure Virtual Desktop host pool
associated with the data the diagnostics service collects for this table.
The source system, Subscription ID, Tenant ID, and type (table name).
Frequency
In contrast to other diagnostics tables that report data at regular intervals throughout a
session, the frequency of data collection for the graphics data varies depending on the
graphical health of a connection. The table won't record data for "Good" scenarios, but
will recording if any of the following metrics are recorded as "Poor" or "Okay," and the
resulting data will be sent to your storage account. Data only records once every two
minutes, maximum. The metrics involved in data collection are listed in the following
table:
Metric Bad Okay Good
Percentage of dropped frames with low frame rate Greater than 10%–15% less than
(less than 15 fps) 15% 10%
Percentage of dropped frames with high frame rage Greater than 20%–50% Less than
(greater than 15 fps) 50% 20%
End-to-end delay per frame Greater than 150 ms– Less than
300 ms 300 ms 150 ms
７ Note
For end-to-end delay per frame, if any frame in a single second is delayed by over
300 ms, the service registers it as "Bad". If all frames in a single second take
between 150 ms and 300 ms, the service marks it as "Okay."
Next steps
Learn more about how to monitor and run queries about connection quality issues
at Monitor connection quality.
Troubleshoot connection and latency issues at Troubleshoot connection quality for
To check the best location for optimal latency, see the Azure Virtual Desktop
Experience Estimator tool .
For pricing plans, see Azure Log Analytics pricing.
To get started with your Azure Virtual Desktop deployment, check out our tutorial.
Virtual Desktop.
Learn how to use Azure Virtual Desktop Insights at Get started with Azure Virtual
Desktop Insights.
Use Azure Private Link with Azure
Virtual Desktop (preview)
） Important
Private Link for Azure Virtual Desktop is currently in PREVIEW.

See the
Supplemental Terms of Use for Microsoft Azure Previews for legal terms that
apply to Azure features that are in beta, preview, or otherwise not yet released into
general availability.
You can use a private endpoint from Azure Private Link with Azure Virtual Desktop to
privately connect to your remote resources. With Private Link, traffic between your
virtual network and the service travels the Microsoft "backbone" network, which means
you'll no longer need to expose your service to the public internet. Keeping traffic within
this "backbone" network improves security and keeps your data safe. This article
describes how Private Link can help you secure your Azure Virtual Desktop environment.
How does Private Link work with Azure Virtual

Desktop?
Azure Virtual Desktop has three workflows with three corresponding resource types of
private endpoints:
The first workflow, initial feed discovery, lets the client discover all workspaces
assigned to a user. To enable this process, you must create a single private
endpoint to the global sub-resource of any workspace. However, you can only
create one private endpoint in your entire Azure Virtual Desktop deployment. This
endpoint creates Domain Name System (DNS) entries and private IP routes for the
global fully-qualified domain name (FQDN) needed for initial feed discovery. This
connection becomes a single, shared route for all clients to use.
The next workflow is feed download, which is when the client downloads all
connection details for a specific user for the workspaces that host their application
groups. To enable this feed download, you must create a private endpoint for each
workspace you want to enable. This endpoint will be to the workspace sub-
resource of the specific workspace you want to allow.
The final workflow involves making connections to host pools. Every connection
has two sides: clients and session host VMs. To enable connections, you need to
create a private endpoint for the host pool sub-resource of any host pool you want
to allow.
You can either share these private endpoints across your network topology or you can
isolate your virtual networks (VNets) so that each has their own private endpoint to the
host pool or workspace.
The following diagram shows how Private Link securely connects a local client to the
Azure Virtual Desktop service:
Supported scenarios
When adding Private Link, you can connect to Azure Virtual Desktop in the following
ways:
Both the clients and the session host VMs use public routes, which don't require
Private Link.
The clients use public routes while session host VMs use private routes.
Both clients and session host VMs use private routes.
Public preview limitations

The public preview of using Private Link with Azure Virtual Desktop has the following
limitations:
You'll need to re-register your resource provider in order to use Private Link.
You can't use the manual connection approval method when using Private Link
with Azure Virtual Desktop. We're aware of this issue and are working on fixing it.
All Azure Virtual Desktop clients are compatible with Private Link, but we currently
only offer troubleshooting support for the web client version of Private Link.
A private endpoint to the global sub-resource of any workspace controls the

shared FQDN for initial feed discovery. This control enables feed discovery for all
workspaces. Because the workspace connected to the private endpoint is so
important, deleting it will cause all feed discovery processes to stop working.
Instead of deleting the workspace, you should create an unused placeholder
workspace to terminate the global endpoint.
Validation for data path access checks, particularly those that prevent exfiltration,
are still being validated. To help us with validation, the preview version of this
feature will collect feedback from customers regarding their exfiltration
requirements, particularly their preferences for how to audit and analyze findings.
We don't recommend or support using the preview version of this feature for
production data traffic.
After you've changed a private endpoint to a host pool, you must restart the
Remote Desktop Agent Loader (RDAgentBootLoader) service on the session host
VM. You'll also need to restart this service whenever you change a host pool's
network configuration. Instead of restarting the service, you can restart the session
host.
Service tags are used by the Azure Virtual Desktop service for agent monitoring
traffic. The service automatically creates these tags.
The public preview doesn't support using both Private Link and RDP Shortpath at
the same time.
Next steps
Learn about how to set up Private Link with Azure Virtual Desktop at Set up Private
Link for Azure Virtual Desktop.
Learn how to configure Azure Private Endpoint DNS at Private Link DNS
integration.
For general troubleshooting guides for Private Link, see Troubleshoot Azure Private
Endpoint connectivity problems.
Understand how connectivity for the Azure Virtual Desktop service works atAzure
Virtual Desktop network connectivity.
See the Required URL list for the list of URLs you'll need to unblock to ensure
network access to the Azure Virtual Desktop service.
Supported identities and authentication
methods
In this article, we'll give you a brief overview of what kinds of identities and
authentication methods you can use in Azure Virtual Desktop.
Identities
Azure Virtual Desktop supports different types of identities depending on which
configuration you choose. This section explains which identities you can use for each
configuration.
） Important
Azure Virtual Desktop doesn't support signing in to Azure AD with one user
account, then signing in to Windows with a separate user account. Signing in with
two different accounts at the same time can lead to users reconnecting to the
wrong session host, incorrect or missing information in the Azure portal, and error
messages appearing while using MSIX app attach.
On-premises identity
Since users must be discoverable through Azure Active Directory (Azure AD) to access
the Azure Virtual Desktop, user identities that exist only in Active Directory Domain
Services (AD DS) aren't supported. This includes standalone Active Directory
deployments with Active Directory Federation Services (AD FS).
Hybrid identity
Azure Virtual Desktop supports hybrid identities through Azure AD, including those
federated using AD FS. You can manage these user identities in AD DS and sync them to
Azure AD using Azure AD Connect. You can also use Azure AD to manage these
identities and sync them to Azure AD Domain Services (Azure AD DS).
When accessing Azure Virtual Desktop using hybrid identities, sometimes the User
Principal Name (UPN) or Security Identifier (SID) for the user in Active Directory (AD) and
Azure AD don't match. For example, the AD account user@contoso.local may
correspond to user@contoso.com in Azure AD. Azure Virtual Desktop only supports this
type of configuration if either the UPN or SID for both your AD and Azure AD accounts
match. SID refers to the user object property "ObjectSID" in AD and
"OnPremisesSecurityIdentifier" in Azure AD.
Cloud-only identity
Azure Virtual Desktop supports cloud-only identities when using Azure AD joined VMs.
These users are created and managed directly in Azure AD.
７ Note
You can also assign hybrid identities to Azure Virtual Desktop Application groups
that host Session hosts of join type Azure AD joined.
Third-party identity providers

If you're using an Identity Provider (IdP) other than Azure AD to manage your user
accounts, you must ensure that:
Your IdP is federated with Azure AD.

Your session hosts are Azure AD-joined or Hybrid Azure AD-joined.
You enable Azure AD authentication to the session host.
External identity
Azure Virtual Desktop currently doesn't support external identities.
Service authentication
To access Azure Virtual Desktop resources, you must first authenticate to the service by
signing in with an Azure AD account. Authentication happens whenever you subscribe
to a workspace to retrieve your resources and connect to apps or desktops. You can use
third-party identity providers as long as they federate with Azure AD.
Multi-factor authentication
Follow the instructions in Enforce Azure Active Directory Multi-Factor Authentication for
Azure Virtual Desktop using Conditional Access to learn how to enforce Azure AD Multi-
Factor Authentication for your deployment. That article will also tell you how to
configure how often your users are prompted to enter their credentials. When deploying
Azure AD-joined VMs, note the extra steps for Azure AD-joined session host VMs.
Passwordless authentication
You can use any authentication type supported by Azure AD, such as Windows Hello for
Business and other passwordless authentication options (for example, FIDO keys), to
authenticate to the service.
Smart card authentication

To use a smart card to authenticate to Azure AD, you must first configure AD FS for user
certificate authentication or configure Azure AD certificate-based authentication.
Session host authentication

If you haven't already enabled single sign-on or saved your credentials locally, you'll also
need to authenticate to the session host when launching a connection. The following list
describes which types of authentication each Azure Virtual Desktop client currently
supports.
The Windows Desktop client supports the following authentication methods:

Username and password
Smart card
Windows Hello for Business certificate trust
Windows Hello for Business key trust with certificates
Azure AD authentication
The Windows Store client supports the following authentication method:
The web client supports the following authentication method:
The Android client supports the following authentication method:
The iOS client supports the following authentication method:
The macOS client supports the following authentication method:
Smart card: support for smart card-based sign in using smart card redirection at
the Winlogon prompt when NLA is not negotiated.
） Important
In order for authentication to work properly, your local machine must also be able
to access the required URLs for Remote Desktop clients.
Single sign-on (SSO)

SSO allows the connection to skip the session host credential prompt and automatically
sign the user in to Windows. For session hosts that are Azure AD-joined or Hybrid Azure
AD-joined, it's recommended to enable SSO using Azure AD authentication. Azure AD
authentication provides other benefits including passwordless authentication and
support for third-party identity providers.
Azure Virtual Desktop also supports SSO using Active Directory Federation Services (AD
FS) for the Windows Desktop and web clients.
Without SSO, the client will prompt users for their session host credentials for every
connection. The only way to avoid being prompted is to save the credentials in the
client. We recommend you only save credentials on secure devices to prevent other
users from accessing your resources.
Smart card and Windows Hello for Business

Azure Virtual Desktop supports both NT LAN Manager (NTLM) and Kerberos for session
host authentication, however Smart card and Windows Hello for Business can only use
Kerberos to sign in. To use Kerberos, the client needs to get Kerberos security tickets
from a Key Distribution Center (KDC) service running on a domain controller. To get
tickets, the client needs a direct networking line-of-sight to the domain controller. You
can get a line-of-sight by connecting directly within your corporate network, using a
VPN connection or setting up a KDC Proxy server.
In-session authentication
Once you're connected to your remote app or desktop, you may be prompted for
authentication inside the session. This section explains how to use credentials other than
username and password in this scenario.
In-session passwordless authentication (preview)

） Important
In-session passwordless authentication is currently in public preview.

This preview
version is provided without a service level agreement, and is not recommended for
production workloads. Certain features might not be supported or might have
constrained capabilities.
For more information, see Supplemental Terms of Use for
Microsoft Azure Previews .
Azure Virtual Desktop supports in-session passwordless authentication (preview) using

Windows Hello for Business or security devices like FIDO keys when using the Windows
Desktop client. Passwordless authentication is enabled automatically when the session
host and local PC are using the following operating systems:
Windows 11 Enterprise single or multi-session with the 2022-10 Cumulative

Updates for Windows 11 (KB5018418) or later installed.
Windows 10 Enterprise single or multi-session, versions 20H2 or later with the
2022-10 Cumulative Updates for Windows 10 (KB5018410) or later installed.
Windows Server 2022 with the 2022-10 Cumulative Update for Microsoft server
operating system (KB5018421) or later installed.
To disable passwordless authentication on your host pool, you must customize an RDP
property. You can find the WebAuthn redirection property under the Device redirection
tab in the Azure portal or set the redirectwebauthn property to 0 using PowerShell.
When enabled, all WebAuthn requests in the session are redirected to the local PC. You
can use Windows Hello for Business or locally attached security devices to complete the
authentication process.
To access Azure AD resources with Windows Hello for Business or security devices, you
must enable the FIDO2 Security Key as an authentication method for your users. To
enable this method, follow the steps in Enable FIDO2 security key method.
In-session smart card authentication

To use a smart card in your session, make sure you've installed the smart card drivers on
the session host and enabled smart card redirection. Review the client comparison chart
to make sure your client supports smart card redirection.
Next steps
Curious about other ways to keep your deployment secure? Check out Security
best practices.
Having issues connecting to Azure AD-joined VMs? Look at Troubleshoot
connections to Azure AD-joined VMs.
Having issues with in-session passwordless authentication? See Troubleshoot
WebAuthn redirection.
Want to use smart cards from outside your corporate network? Review how to set
up a KDC Proxy server.
Built-in Azure RBAC roles for Azure Virtual
Desktop
Azure Virtual Desktop uses Azure role-based access control (RBAC) to control access to
resources. There are a number of built-in roles for use with Azure Virtual Desktop which is a
collection of permissions. You assign roles to users and admins and these roles give permission
to carry out certain tasks. To learn more about Azure RBAC, see What is Azure RBAC?.
The standard built-in roles for Azure are Owner, Contributor, and Reader. However, Azure Virtual
Desktop has additional roles that let you separate management roles for host pools, application
groups, and workspaces. This separation lets you have more granular control over
administrative tasks. These roles are named in compliance with Azure's standard roles and least-
privilege methodology.
Azure Virtual Desktop doesn't have a specific Owner role. However, you can use the general
Owner role for the service objects.
The built-in roles for Azure Virtual Desktop and the permissions for each one are detailed
below. The assignable scope for all built-in roles are set to the root scope ("/"). The root scope
indicates that the role is available for assignment in all scopes, for example management
groups, subscriptions, or resource groups. For more information, see Understand Azure role
definitions.
Desktop Virtualization Contributor

The Desktop Virtualization Contributor role allows users to manage all aspects of the
deployment. However, it doesn't grant users access to compute resources. You'll also need the
User Access Administrator role to publish application groups to users or user groups.
Action type Permissions
actions Microsoft.DesktopVirtualization/*
Microsoft.Resources/subscriptions/resourceGroups/read
Microsoft.Resources/deployments/*
Microsoft.Authorization/*/read
Microsoft.Insights/alertRules/*
Microsoft.Support/*
notActions None
dataActions None
notDataActions None
Desktop Virtualization Reader
The Desktop Virtualization Reader role allows users to view everything in the deployment, but
doesn't let them make any changes.
actions Microsoft.DesktopVirtualization/*/read
Microsoft.Resources/deployments/read
Microsoft.Insights/alertRules/read
Microsoft.Support/*
notActions None
dataActions None
notDataActions None
Desktop Virtualization User

The Desktop Virtualization User role allows users to use the applications in an application group.
actions None
notActions None
dataActions Microsoft.DesktopVirtualization/applicationGroups/useApplications/action
notDataActions None
Desktop Virtualization Host Pool Contributor

The Desktop Virtualization Host Pool Contributor role allows users to manage all aspects of host
pools, including access to resources. You'll also need the Virtual Machine Contributor role to
create virtual machines. You will need Desktop Virtualization Application Group Contributor and
Desktop Virtualization Workspace Contributor roles to create host pools using the portal, or you
can use the Desktop Virtualization Contributor role.

actions Microsoft.DesktopVirtualization/hostpools/*
Microsoft.Support/*
notActions None
dataActions None
notDataActions None
Desktop Virtualization Host Pool Reader

The Desktop Virtualization Host Pool Reader role allows users to view everything in the host
pool, but won't allow them to make any changes.
actions Microsoft.DesktopVirtualization/hostpools/*/read
Microsoft.DesktopVirtualization/hostpools/read
Microsoft.Support/*
notActions None
dataActions None
notDataActions None
Desktop Virtualization Application Group

Contributor
The Desktop Virtualization Application Group Contributor role allows users to manage all
aspects of application groups. If you want users to publish application groups to users or user
groups, they'll also need the User Access Administrator role.

actions Microsoft.DesktopVirtualization/applicationgroups/*
Microsoft.DesktopVirtualization/hostpools/sessionhosts/read
Microsoft.Support/*
notActions None
dataActions None
notDataActions None
Desktop Virtualization Application Group Reader

The Desktop Virtualization Application Group Reader role allows users to view everything in the
application group and will not allow them to make any changes.
actions Microsoft.DesktopVirtualization/applicationgroups/*/read
Microsoft.DesktopVirtualization/applicationgroups/read
Microsoft.Support/*
notActions None
dataActions None
notDataActions None
Desktop Virtualization Workspace Contributor

The Desktop Virtualization Workspace Contributor role allows users to manage all aspects of
workspaces. To get information on applications added to the application groups, they'll also
need the Application Group Reader role.

actions Microsoft.DesktopVirtualization/workspaces/*
Microsoft.Support/*
notActions None
dataActions None
notDataActions None
Desktop Virtualization Workspace Reader

The Desktop Virtualization Workspace Reader role allows users to view everything in the
workspace, but won't allow them to make any changes.
actions Microsoft.DesktopVirtualization/workspaces/read
Microsoft.Support/*
notActions None
dataActions None
notDataActions None
Desktop Virtualization User Session Operator

The Desktop Virtualization User Session Operator role allows users to send messages,
disconnect sessions, and use the "logoff" function to sign sessions out of the session host.
However, this role doesn't let users perform session host management like removing session
host, changing drain mode, and so on. This role can see assignments, but can't modify admins.
We recommend you assign this role to specific host pools. If you give this permission at a
resource group level, the admin will have read permission on all host pools under a resource
group.
actions Microsoft.DesktopVirtualization/hostpools/read
Microsoft.DesktopVirtualization/hostpools/sessionhosts/usersessions/*
Microsoft.Support/*
notActions None
dataActions None
notDataActions None
Desktop Virtualization Session Host Operator

The Desktop Virtualization Session Host Operator role allows users to view and remove session
hosts, as well as change drain mode. Users can't add session hosts using the Azure portal
because they don't have write permission for host pool objects. If the registration token is valid
(generated and not expired), users assigned this role can add session hosts to the host pool
outside of the Azure portal if they also have the Virtual Machine Contributor role.
Microsoft.DesktopVirtualization/hostpools/sessionhosts/*
Microsoft.Support/*
notActions None
dataActions None
notDataActions None
Desktop Virtualization Power On Contributor

The Desktop Virtualization Power On Contributor role allows the Azure Virtual Desktop Resource
Provider to start virtual machines.

actions Microsoft.Compute/virtualMachines/start/action
Microsoft.Compute/virtualMachines/read
Microsoft.Compute/virtualMachines/instanceView/read
notActions None
dataActions None
notDataActions None
Desktop Virtualization Power On Off Contributor

The Desktop Virtualization Power On Off Contributor role allows the Azure Virtual Desktop
Resource Provider to start and stop virtual machines.
actions Microsoft.Compute/virtualMachines/start/action
Microsoft.Compute/virtualMachines/instanceView/read
Microsoft.Compute/virtualMachines/deallocate/action
Microsoft.Compute/virtualMachines/restart/action
Microsoft.Compute/virtualMachines/powerOff/action
Microsoft.Insights/eventtypes/values/read
Microsoft.DesktopVirtualization/hostpools/write
Microsoft.DesktopVirtualization/hostpools/sessionhosts/write
Microsoft.DesktopVirtualization/hostpools/sessionhosts/usersessions/delete
Microsoft.DesktopVirtualization/hostpools/sessionhosts/usersessions/read
Microsoft.DesktopVirtualization/hostpools/sessionhosts/usersessions/sendMessage/action
notActions None
dataActions None
notDataActions None
Desktop Virtualization Virtual Machine Contributor

The Desktop Virtualization Virtual Machine Contributor role allows the Azure Virtual Desktop
Resource Provider to create, delete, update, start, and stop virtual machines.
Microsoft.DesktopVirtualization/hostpools/write
Microsoft.DesktopVirtualization/hostpools/retrieveRegistrationToken/action
Microsoft.DesktopVirtualization/hostpools/sessionhosts/write
Microsoft.DesktopVirtualization/hostpools/sessionhosts/delete
Microsoft.DesktopVirtualization/hostpools/sessionhosts/usersessions/read
Microsoft.DesktopVirtualization/hostpools/sessionhosts/usersessions/disconnect/action
Microsoft.DesktopVirtualization/hostpools/sessionhosts/usersessions/sendMessage/action
Microsoft.DesktopVirtualization/hostpools/sessionHostConfigurations/read
Microsoft.Compute/availabilitySets/read
Microsoft.Compute/availabilitySets/write
Microsoft.Compute/availabilitySets/vmSizes/read
Microsoft.Compute/disks/read
Microsoft.Compute/disks/write
Microsoft.Compute/disks/delete
Microsoft.Compute/galleries/read
Microsoft.Compute/galleries/images/read
Microsoft.Compute/galleries/images/versions/read
Microsoft.Compute/images/read
Microsoft.Compute/locations/usages/read
Microsoft.Compute/locations/vmSizes/read
Microsoft.Compute/operations/read
Microsoft.Compute/skus/read
Microsoft.Compute/virtualMachines/write
Microsoft.Compute/virtualMachines/delete
Microsoft.Compute/virtualMachines/start/action
Microsoft.Compute/virtualMachines/powerOff/action
Microsoft.Compute/virtualMachines/restart/action
Microsoft.Compute/virtualMachines/deallocate/action
Microsoft.Compute/virtualMachines/runCommand/action
Microsoft.Compute/virtualMachines/extensions/read
Microsoft.Compute/virtualMachines/extensions/write
Microsoft.Compute/virtualMachines/extensions/delete
Microsoft.Compute/virtualMachines/runCommands/read
Microsoft.Compute/virtualMachines/runCommands/write
Microsoft.Compute/virtualMachines/vmSizes/read
Microsoft.Network/networkSecurityGroups/read
Microsoft.Network/networkInterfaces/write
Microsoft.Network/networkInterfaces/read
Microsoft.Network/networkInterfaces/join/action
Microsoft.Network/networkInterfaces/delete
Microsoft.Network/virtualNetworks/subnets/read
Microsoft.Network/virtualNetworks/subnets/join/action
Microsoft.Marketplace/offerTypes/publishers/offers/plans/agreements/read
Microsoft.KeyVault/vaults/deploy/action
Microsoft.Storage/storageAccounts/read
notActions None
dataActions None
notDataActions None
Delegated access in Azure Virtual
Desktop
） Important
Azure Virtual Desktop has a delegated access model that lets you define the amount of
access a particular user is allowed to have by assigning them a role. A role assignment
has three components: security principal, role definition, and scope. The Azure Virtual
Desktop delegated access model is based on the Azure RBAC model. To learn more
about specific role assignments and their components, see the Azure role-based access
control overview.
Azure Virtual Desktop delegated access supports the following values for each element
of the role assignment:
Security principal
Users
User groups
Service principals
Role definition
Built-in roles
Custom roles
Scope
Host pools
App groups
Workspaces
PowerShell cmdlets for role assignments

Before you start, make sure to follow the instructions in Set up the PowerShell module
to set up the Azure Virtual Desktop PowerShell module if you haven't already.
Azure Virtual Desktop uses Azure role-based access control (Azure RBAC) while
publishing app groups to users or user groups. The Desktop Virtualization User role is
assigned to the user or user group and the scope is the app group. This role gives the
user special data access on the app group.
Run the following cmdlet to add Azure Active Directory users to an app group:
PowerShell
New-AzRoleAssignment -SignInName <userupn> -RoleDefinitionName "Desktop

Virtualization User" -ResourceName <appgroupname> -ResourceGroupName
<resourcegroupname> -ResourceType
'Microsoft.DesktopVirtualization/applicationGroups'
Run the following cmdlet to add Azure Active Directory user group to an app group:
PowerShell
New-AzRoleAssignment -ObjectId <usergroupobjectid> -RoleDefinitionName

"Desktop Virtualization User" -ResourceName <appgroupname> -
ResourceGroupName <resourcegroupname> -ResourceType
Next steps
For a more complete list of PowerShell cmdlets each role can use, see the PowerShell
reference.
For a complete list of roles supported in Azure RBAC, see Azure built-in roles.
For guidelines for how to set up a Azure Virtual Desktop environment, see Azure Virtual
Desktop environment.
 Documentation


production.
Customize feed for Azure Virtual Desktop users - Azure
How to customize feed for Azure Virtual Desktop users with PowerShell cmdlets.




Show 5 more
 Training

Manage access and security for Azure Virtual Desktop - Training
Manage access and security for Azure Virtual Desktop
Get started with the Azure Virtual
Desktop Agent
In the Azure Virtual Desktop Service framework, there are three main components: the
Remote Desktop client, the service, and the virtual machines. These virtual machines live
in the customer subscription where the Azure Virtual Desktop agent and agent
bootloader are installed. The agent acts as the intermediate communicator between the
service and the virtual machines, enabling connectivity. Therefore, if you're experiencing
any issues with the agent installation, update, or configuration, your virtual machines
won't be able to connect to the service. The agent bootloader is the executable that
loads the agent.
This article will give you a brief overview of the agent installation and update processes.
７ Note
This documentation is not for the FSLogix agent or the Remote Desktop Client
agent.
Initial installation process

The Azure Virtual Desktop agent is initially installed in one of two ways. If you provision
virtual machines (VMs) in the Azure portal and Azure Marketplace, the agent and agent
bootloader are automatically installed. If you provision VMs using PowerShell, you must
manually download the agent and agent bootloader .msi files when creating a Azure
Virtual Desktop host pool with PowerShell. Once the agent is installed, it installs the
Azure Virtual Desktop side-by-side stack and Geneva Monitoring agent. The side-by-
side stack component is required for users to securely establish reverse server-to-client
connections. The Geneva Monitoring agent monitors the health of the agent. All three
of these components are essential for end-to-end user connectivity to function properly.
） Important
To successfully install the Azure Virtual Desktop agent, side-by-side stack, and
Geneva Monitoring agent, you must unblock all the URLs listed in the Required
URL list. Unblocking these URLs is required to use the Azure Virtual Desktop
service.
Agent update process
The Azure Virtual Desktop service updates the agent whenever an update becomes
available. Agent updates can include new functionality or fixes for previous issues. You
must always have the latest stable version of the agent installed so your VMs don't lose
connectivity or security. After you've installed the initial version of the Azure Virtual
Desktop agent, the agent will regularly query the Azure Virtual Desktop service to
determine if there’s a newer version of the agent, stack, or monitoring agent available. If
a newer version exists, the updated component is automatically installed by the flighting
system, unless you've configured the Scheduled Agent Updates feature. If you've
already configured the Scheduled Agent Updates feature, the agent will only install the
updated components during the maintenance window that you specify. For more
information, see Scheduled Agent Updates.
New versions of the agent are deployed at regular intervals in five-day periods to all
Azure subscriptions. These update periods are called "flights". It takes 24 hours for all
VMs in a single broker region to receive the agent update in a flight. Because of this,
when a flight happens, you may see VMs in your host pool receive the agent update at
different times. Also, if the VMs are in different regions, they might update on different
days in the five-day period. The flight will update all VM agents in all subscriptions by
the end of the deployment period. The Azure Virtual Desktop flighting system enhances
service reliability by ensuring the stability and quality of the agent update.
Other important things you should keep in mind:
The agent update isn't connected to Azure Virtual Desktop infrastructure build
updates. When the Azure Virtual Desktop infrastructure updates, that doesn't
mean that the agent has updated along with it.
Because VMs in your host pool may receive agent updates at different times, you'll
need to be able to tell the difference between flighting issues and failed agent
updates. If you go to the event logs for your VM at Event Viewer > Windows Logs
> Application and see an event labeled "ID 3277," that means the Agent update
didn't work. If you don't see that event, then the VM is in a different flight and will
be updated later. See Set up diagnostics to monitor agent updates for more
information about how to set up diagnostic logs to track updates and make sure
they've been installed correctly.
When the Geneva Monitoring agent updates to the latest version, the old
GenevaTask task is located and disabled before creating a new task for the new
monitoring agent. The earlier version of the monitoring agent isn't deleted in case
that the most recent version of the monitoring agent has a problem that requires
reverting to the earlier version to fix. If the latest version has a problem, the old
monitoring agent will be re-enabled to continue delivering monitoring data. All
versions of the monitor that are earlier than the last one you installed before the
update will be deleted from your VM.
Your VM keeps three versions of the agent and of the side-by-side stack at a time.
This allows for quick recovery if something goes wrong with the update. The
earliest version of the agent or stack is removed from the VM whenever the agent
or stack updates. If you delete these components prematurely and the agent or
stack has a failure, the agent or stack won't be able to roll back to an earlier
version, which will put your VM in an unavailable state.
The agent update normally lasts 2-3 minutes on a new VM and shouldn't cause your VM
to lose connection or shut down. This update process applies to both Azure Virtual
Desktop (classic) and the latest version of Azure Virtual Desktop with Azure Resource
Manager.
Next steps
Now that you have a better understanding of the Azure Virtual Desktop agent, here are
some resources that might help you:
If you're experiencing agent or connectivity-related issues, check out the Azure

Virtual Desktop Agent issues troubleshooting guide.
To schedule agent updates, see the Scheduled Agent Updates (preview) document.
To set up diagnostics for this feature, see the Scheduled Agent Updates
Diagnostics guide.
To find information about the latest and previous agent versions, see the Agent
Updates version notes.
 Documentation


environment.

Azure Virtual Desktop scaling plans for host pools in Azure Virtual Desktop
How to assign scaling plans to new or existing host pools in your deployment.

Azure Virtual Desktop session host statuses and health checks

How to troubleshoot the failed session host statuses and failed health checks
Set up diagnostics for autoscale in Azure Virtual Desktop

How to set up diagnostic reports for the scaling service in your Azure Virtual Desktop deployment.

Show 5 more
 Training
Module
Host your own build agent in Azure Pipelines - Training
Work with guidance from the Space Game web team to set up your build agent running on-premises
or on an Azure virtual machine running in the cloud.
Host pool load-balancing algorithms
） Important
Azure Virtual Desktop supports two load-balancing algorithms. Each algorithm

determines which session host will host a user's session when they connect to a
resource in a pooled host pool. The information in this article only applies to pooled
host pools.
The following load-balancing algorithms are available in Azure Virtual Desktop:
Breadth-first load balancing allows you to evenly distribute user sessions across
the session hosts in a host pool. You don't have to specify a maximum session limit
for the number of sessions.
Depth-first load balancing allows you to saturate a session host with user sessions
in a host pool. You have to specify a maximum session limit for the number of
sessions. Once the first session host reaches its session limit threshold, the load
balancer directs any new user connections to the next session host in the host pool
until it reaches its limit, and so on.
Each host pool can only configure one type of load-balancing specific to it. However,
both load-balancing algorithms share the following behaviors no matter which host
pool they're in:
If a user already has an active or disconnected session in the host pool and signs in
again, the load balancer will successfully redirect them to the session host with
their existing session. This behavior applies even if that session host's
AllowNewConnections property is set to False (drain mode is enabled).
If a user doesn't already have a session in the host pool, then the load balancer
won't consider session hosts whose AllowNewConnections property is set to False
during load balancing.
If you lower the maximum session limit on a session host while it has active user
sessions, the change won't affect the active user sessions.
Breadth-first load-balancing algorithm

The breadth-first load-balancing algorithm allows you to distribute user sessions across
session hosts to optimize for session performance. This algorithm is ideal for
organizations that want to provide the best experience for users connecting to their
pooled virtual desktop environment.
The breadth-first algorithm first queries session hosts that allow new connections. The
algorithm then selects a session host randomly from half the set of session hosts with
the least number of sessions. For example, if there are nine machines with 11, 12, 13, 14,
15, 16, 17, 18, and 19 sessions, a new session you create won't automatically go to the
first machine. Instead, it can go to any of the first five machines with the lowest number
of sessions (11, 12, 13, 14, 15).
Depth-first load-balancing algorithm

The depth-first load-balancing algorithm allows you to saturate one session host at a
time to optimize for scale down scenarios. This algorithm is ideal for cost-conscious
organizations that want more granular control on the number of virtual machines
they've allocated for a host pool.
The depth-first algorithm first queries session hosts that allow new connections and
haven't gone over their maximum session limit. The algorithm then selects the session
host with highest number of sessions. If there's a tie, the algorithm selects the first
session host in the query.
） Important
The maximum session limit parameter is required when you use the depth-first load
balancing algorithm. For the best possible user experience, make sure to change
the maximum session host limit parameter to a number that best suits your
environment.
Once all session hosts have reached the maximum session limit, you will need to
increase the limit or deploy more session hosts.
 Documentation

production.
Delegated access in Azure Virtual Desktop - Azure

How to delegate administrative capabilities on a Azure Virtual Desktop deployment, including
examples.
Azure Virtual Desktop FSLogix profile container share - Azure

How to set up an FSLogix profile container for a Azure Virtual Desktop host pool using a virtual
machine-based file share.




Manage app groups for Azure Virtual Desktop portal - Azure

How to manage Azure Virtual Desktop app groups with the Azure portal.
Show 5 more
 Training

Create and configure host pools and session hosts for Azure Virtual Desktop -
Training
Create and configure host pools and session hosts for Azure Virtual Desktop
FSLogix profile containers and Azure files
The Azure Virtual Desktop service recommends FSLogix profile containers as a user profile solution. FSLogix is
designed to roam profiles in remote computing environments, such as Azure Virtual Desktop. It stores a
complete user profile in a single container. At sign in, this container is dynamically attached to the computing
environment using natively supported Virtual Hard Disk (VHD) and Hyper-V Virtual Hard disk (VHDX). The user
profile is immediately available and appears in the system exactly like a native user profile. This article
describes how FSLogix profile containers used with Azure Files function in Azure Virtual Desktop.
７ Note
If you're looking for comparison material about the different FSLogix Profile Container storage options on
Azure, see Storage options for FSLogix profile containers.
User profiles
A user profile contains data elements about an individual, including configuration information like desktop
settings, persistent network connections, and application settings. By default, Windows creates a local user
profile that is tightly integrated with the operating system.
A remote user profile provides a partition between user data and the operating system. It allows the operating
system to be replaced or changed without affecting the user data. In Remote Desktop Session Host (RDSH)
and Virtual Desktop Infrastructures (VDI), the operating system may be replaced for the following reasons:
An upgrade of the operating system

A replacement of an existing Virtual Machine (VM)
A user being part of a pooled (non-persistent) RDSH or VDI environment
Microsoft products operate with several technologies for remote user profiles, including these technologies:
Roaming user profiles (RUP)

User profile disks (UPD)
Enterprise state roaming (ESR)
UPD and RUP are the most widely used technologies for user profiles in Remote Desktop Session Host (RDSH)
and Virtual Hard Disk (VHD) environments.
Challenges with previous user profile technologies

Existing and legacy Microsoft solutions for user profiles came with various challenges. No previous solution
handled all the user profile needs that come with an RDSH or VDI environment. For example, UPD cannot
handle large OST files and RUP does not persist modern settings.
Functionality
The following table shows benefits and limitations of previous user profile technologies.
Technology Modern Win32 OS User Supported Back- Back- Version Subsequent Notes
settings settings settings data on server end end support sign in time
SKU storage storage
on on-
Azure premises
User Profile Yes Yes Yes Yes Yes No Yes Win 7+ Yes
Disks (UPD)
Roaming No Yes Yes Yes Yes No Yes Win 7+ No

User Profile
(RUP),
maintenance
mode
Enterprise Yes No Yes No See notes Yes No Win 10 No Functions

State on server
Roaming SKU but
(ESR) no
supporting
user
interface
User Yes Yes Yes No Yes No Yes Win 7+ No

Experience
Virtualization
(UE-V)
OneDrive No No No Yes See notes See See Win 10 No Not tested

cloud files notes Notes RS3 on server
SKU. Back-
end
storage on
Azure
depends
on sync
client.
Back-end
storage
on-prem
needs a
sync client.
Performance
UPD requires Storage Spaces Direct (S2D) to address performance requirements. UPD uses Server Message
Block (SMB) protocol. It copies the profile to the VM in which the user is being logged.
Cost
While S2D clusters achieve the necessary performance, the cost is expensive for enterprise customers, but
especially expensive for small and medium business (SMB) customers. For this solution, businesses pay for
storage disks, along with the cost of the VMs that use the disks for a share.
Administrative overhead
S2D clusters require an operating system that is patched, updated, and maintained in a secure state. These
processes and the complexity of setting up S2D disaster recovery make S2D feasible only for enterprises with a
dedicated IT staff.
FSLogix profile containers

On November 19, 2018, Microsoft acquired FSLogix . FSLogix addresses many profile container challenges.
Key among them are:
Performance: The FSLogix profile containers are high performance and resolve performance issues that
have historically blocked cached exchange mode.
OneDrive: Without FSLogix profile containers, OneDrive for Business is not supported in non-persistent
RDSH or VDI environments. The OneDrive VDI support page will tell you how they interact. For more
information, see Use the sync client on virtual desktops.
Additional folders: FSLogix provides the ability to extend user profiles to include additional folders.
Since the acquisition, Microsoft started replacing existing user profile solutions, like UPD, with FSLogix profile
containers.
Azure Files integration with Azure Active Directory Domain

Service
FSLogix profile containers' performance and features take advantage of the cloud. On August 7th, 2019,
Microsoft Azure Files announced the general availability of Azure Files authentication with Azure Active
Directory Domain Service (Azure AD DS). By addressing both cost and administrative overhead, Azure Files
with Azure AD DS Authentication is a premium solution for user profiles in the Azure Virtual Desktop service.
Best practices for Azure Virtual Desktop

Azure Virtual Desktop offers full control over size, type, and count of VMs that are being used by customers.
For more information, see What is Azure Virtual Desktop?.
To ensure your Azure Virtual Desktop environment follows best practices:
Azure Files storage account must be in the same region as the session host VMs.
Azure Files permissions should match permissions described in Requirements - Profile Containers.
Each host pool VM must be built of the same type and size VM based on the same master image.
Each host pool VM must be in the same resource group to aid management, scaling and updating.
For optimal performance, the storage solution and the FSLogix profile container should be in the same
data center location.
The storage account containing the master image must be in the same region and subscription where
the VMs are being provisioned.
Next steps
To learn more about storage options for FSLogix profile containers, see Storage options for FSLogix profile
containers in Azure Virtual Desktop.
Storage options for FSLogix profile
containers in Azure Virtual Desktop
Azure offers multiple storage solutions that you can use to store your FSLogix profile
container. This article compares storage solutions that Azure offers for Azure Virtual
Desktop FSLogix user profile containers. We recommend storing FSLogix profile
containers on Azure Files for most of our customers.
Azure Virtual Desktop offers FSLogix profile containers as the recommended user profile
solution. FSLogix is designed to roam profiles in remote computing environments, such
as Azure Virtual Desktop. At sign-in, this container is dynamically attached to the
computing environment using a natively supported Virtual Hard Disk (VHD) and a
Hyper-V Virtual Hard Disk (VHDX). The user profile is immediately available and appears
in the system exactly like a native user profile.
The following tables compare the storage solutions Azure Storage offers for Azure
Virtual Desktop FSLogix profile container user profiles.
Azure platform details

Features Azure Files Azure NetApp Files Storage Spaces
Direct
Use case General purpose General purpose to enterprise scale Cross-platform
Platform Yes, Azure-native Yes, Azure-native solution No, self-managed

service solution
Regional All regions Select regions All regions

availability
Redundancy Locally Locally redundant/geo-redundant with Locally

redundant/zone- cross-region replication redundant/zone-
redundant/geo- redundant/geo-
redundant/geo- redundant
zone-redundant
Features Azure Files Azure NetApp Files Storage Spaces
Direct
Tiers and Standard Standard

Standard HDD: up
performance (Transaction Premium
to 500 IOPS per-
optimized)
Ultra
disk limits
Premium
Up to max 460K IOPS per volume with Standard SSD: up
Up to max 100K 4.5 GBps per volume at about 1 ms to 4k IOPS per-
IOPS per share latency. For IOPS and performance disk limits
with 10 GBps per details, see Azure NetApp Files Premium SSD: up
share at about 3- performance considerations and the to 20k IOPS per-
ms latency FAQ. disk limits
We recommend
Premium disks for
Storage Spaces
Direct
Capacity 100 TiB per 100 TiB per volume, up to 12.5 PiB per Maximum 32 TiB
share, Up to 5 NetApp account per disk
PiB per general
purpose account
Required Minimum share Minimum capacity pool 2 TiB, min Two VMs on Azure
infrastructure size 1 GiB volume size 100 GiB IaaS (+ Cloud
Witness) or at least
three VMs without
and costs for disks
Protocols SMB 3.0/2.1, NFSv3, NFSv4.1, SMB 3.x/2.x, dual- NFSv3, NFSv4.1,
NFSv4.1 protocol SMB 3.1
(preview), REST
Azure management details

Features Azure Files Azure NetApp Files Storage Spaces Direct
Access Cloud, on-premises and Cloud, on-premises Cloud, on-premises

hybrid (Azure file sync)
Backup Azure backup snapshot Azure NetApp Files Azure backup snapshot
integration snapshots
integration
Azure NetApp Files
backup
Security All Azure supported Azure supported All Azure supported

and certificates certificates certificates
compliance
Features Azure Files Azure NetApp Files Storage Spaces Direct
Azure Native Active Directory Azure Active Directory Native Active Directory or
Active and Azure Active Domain Services and Azure Active Directory
Directory Directory Domain Native Active Directory Domain Services support
integration Services only
Once you've chosen your storage method, check out Azure Virtual Desktop pricing for
information about our pricing plans.
Azure Files tiers

Azure Files offers two different tiers of storage: premium and standard. These tiers let
you tailor the performance and cost of your file shares to meet your scenario's
requirements.
Premium file shares are backed by solid-state drives (SSDs) and are deployed in
the FileStorage storage account type. Premium file shares provide consistent high
performance and low latency for input and output (IO) intensive workloads.
Premium file shares use a provisioned billing model, where you pay for the amount
of storage you would like your file share to have, regardless of how much you use.
Standard file shares are backed by hard disk drives (HDDs) and are deployed in the
general purpose version 2 (GPv2) storage account type. Standard file shares
provide reliable performance for IO workloads that are less sensitive to
performance variability, such as general-purpose file shares and dev/test
environments. Standard file shares use a pay-as-you-go billing model, where you
pay based on storage usage, including data stored and transactions.
To learn more about how billing works in Azure Files, see Understand Azure Files billing.
The following table lists our recommendations for which performance tier to use based
on your workload. These recommendations will help you select the performance tier
that meets your performance targets, budget, and regional considerations. We've based
these recommendations on the example scenarios from Remote Desktop workload
types.
Workload type Recommended file tier
Light (fewer than 200 users) Standard file shares
Light (more than 200 users) Premium file shares or standard with multiple file shares
Medium Premium file shares

Workload type Recommended file tier
Heavy Premium file shares
Power Premium file shares
For more information about Azure Files performance, see File share and file scale
targets. For more information about pricing, see Azure Files pricing .
Azure NetApp Files tiers

Azure NetApp Files volumes are organized in capacity pools. Volume performance is
defined by the service level of the hosting capacity pool. Three performance levels are
offered, ultra, premium and standard. For more information, see Storage hierarchy of
Azure NetApp Files. Azure NetApp Files performance is a function of tier times capacity.
More provisioned capacity leads to higher performance budget, which likely results in a
lower tier requirement, providing a more optimal TCO.
The following table lists our recommendations for which performance tier to use based
on workload defaults.
Workload Example Users Azure NetApp Files
Light Users doing basic data entry tasks Standard tier
Medium Consultants and market researchers Premium tier: small-medium

user count
Standard tier: large user count
Heavy Software engineers, content creators Premium tier: small-medium

user count
Power Graphic designers, 3D model makers, machines Ultra tier: small user count
learning researchers Premium tier: medium user

count
In order to provision the optimal tier and volume size, consider using this calculator
for guidance.
Next steps
To learn more about FSLogix profile containers, user profile disks, and other user profile
technologies, see the table in FSLogix profile containers and Azure Files.
If you're ready to create your own FSLogix profile containers, get started with one of
these tutorials:
Set up FSLogix Profile Container with Azure Files and Active Directory
Set up FSLogix Profile Container with Azure NetApp Files
 Documentation
FSLogix profile containers NetApp Azure Virtual Desktop - Azure

How to create an FSLogix profile container using Azure NetApp Files in Azure Virtual Desktop.

Azure Virtual Desktop FSLogix profile containers files - Azure

This article describes FSLogix profile containers within Azure Virtual Desktop and Azure Files.

Install Microsoft Office FSLogix application containers in Azure Virtual Desktop -

Azure
How to use the app rule editor to create an FSLogix application container with Office in Azure Virtual
Desktop.
Autoscale scaling plans and example scenarios in Azure Virtual Desktop

Information about autoscale and a collection of four example scenarios that illustrate how various
parts of autoscale for Azure Virtual Desktop work.
Azure Virtual Desktop disaster recovery concepts

Understand what a disaster recovery plan for Azure Virtual Desktop is and how each plan works.
Set up FSLogix Profile Container with Azure Files and AD DS or Azure AD DS - Azure
Virtual Desktop
This article describes how to create a FSLogix Profile Container with Azure Files and Active Directory
Domain Services or Azure Active Directory Domain Services.
Show 5 more
 Training
Module
Implement and manage storage for Azure Virtual Desktop - Training
Implement and manage storage for Azure Virtual Desktop
Certification
What is MSIX app attach?
MSIX is a new packaging format that offers many features aimed to improve packaging
experience for all Windows apps. To learn more about MSIX, see the MSIX overview.
MSIX app attach is a way to deliver MSIX applications to both physical and virtual
machines. However, MSIX app attach is different from regular MSIX because it's made
especially for supported products, such as Azure Virtual Desktop. This article will
describe what MSIX app attach is and what it can do for you.
What does MSIX app attach do?

In an Azure Virtual Desktop deployment, MSIX app attach delivers apps to session hosts
within MSIX containers. These containers separate user data, the OS, and apps,
increasing security and ensuring easier troubleshooting if something goes wrong. App
attach removes the need for repackaging apps when delivering applications
dynamically, which increases the speed of deployments and reduces the time it takes for
users to sign in to their remote sessions. This rapid delivery reduces operational
overhead and costs for your organization.
Traditional app layering compared to MSIX app

attach
The following table compares key feature of MSIX app attach and app layering.
Feature Traditional app MSIX app attach

layering
Format Different app layering Works with the native MSIX packaging format.
technologies require
different proprietary
formats.
Repackaging Proprietary formats Apps published as MSIX don't require repackaging.

overhead require sequencing and However, if the MSIX package isn't available,
repackaging per repackaging overhead still applies.
update.
Feature Traditional app MSIX app attach
layering
Ecosystem N/A (for example, MSIX is Microsoft's mainstream technology that key
vendors don't ship ISV partners and in-house apps like Office are
App-V) adopting. You can use MSIX on both virtual desktops
and physical Windows computers.
Infrastructure Additional Storage only

infrastructure required
(servers, clients, and so
on)
Administration Requires maintenance Simplifies app updates

and update
User Impacts user sign-in Delivered apps are indistinguishable from locally
experience time. Boundary exists installed applications.
between OS state, app
state, and user data.
Next steps
If you want to learn more about MSIX app attach, check out our glossary and FAQ.
Otherwise, get started with Set up MSIX app attach with the Azure portal.
MSIX app attach glossary
This article is a list of definitions for key terms and concepts related to MSIX app attach.
MSIX container
An MSIX container is where MSIX apps are run. To learn more, see MSIX containers.
MSIX application
An application stored in an .MSIX file.
MSIX package
An MSIX package is an MSIX file or application.
MSIX share
An MSIX share is a network share that holds expanded MSIX packages. MSIX shares
must support SMB 3 or later. The shares must also be accessible to the Virtual Machines
(VM) in the host pool system account. MSIX packages get staged from the MSIX share
without having to move application files to the system drive.
MSIX image
An MSIX image is a VHD, VHDx, or CIM file that contains one or more MSIX packaged
applications. Each application is delivered in the MSIX image using the MSIXMGR tool.
Repackage
Repackaging takes a non-MSIX application and converts it into MSIX using the MSIX
Packaging Tool (MPT). For more information, see MSIX Packaging Tool overview.
Expand an MSIX package

Expanding an MSIX package is a multi-step process. Expansion takes the MSIX file and
puts its content into a VHD(x) or CIM file.
To expand an MSIX package:
1. Get an MSIX package (MSIX file).

2. Rename the MSIX file to a .zip file.
3. Unzip the resulting .zip file in a folder.
4. Create a VHD that's the same size as the folder.
5. Mount the VHD.
6. Initialize a disk.
7. Create a partition.
8. Format the partition.
9. Copy the unzipped content into the VHD.
10. Use the MSIXMGR tool to apply ACLs on the content of the VHD.
11. Unmount the VHD(x) or CIM.
Upload an MSIX package

Uploading an MSIX package involves uploading the VHD(x) or CIM that contains an
expanded MSIX package to the MSIX share.
In Azure Virtual Desktop, uploads happen once per MSIX share. Once you upload a
package, all host pools in the same subscription can reference it.
Add an MSIX package

In Azure Virtual Desktop, adding an MSIX package links it to a host pool.
Publish an MSIX package

In Azure Virtual Desktop, a published MSIX package must be assigned to an Active
Directory Domain Service (AD DS) or Azure Active Directory (Azure AD) user or user
group.
Staging
Staging involves two things:
Mounting the VHD(x) or CIM to the VM.

Notifying the OS that the MSIX package is available for registration.
Registration
Registration makes a staged MSIX package available for your users. Registering is on a
per-user basis. If you haven't explicitly registered an app for that specific user, they
won't be able to run the app.
There are two types of registration: regular and delayed.
Regular registration
In regular registration, each application assigned to a user is fully registered.
Registration happens during the time the user signs in to the session, which might
impact the time it takes for them to start using Azure Virtual Desktop.
Delayed registration
In delayed registration, each application assigned to the user is only partially registered.
Partial registration means that the Start menu tile and double-click file associations are
registered. Registration happens while the user signs in to their session, so it has
minimal impact on the time it takes to start using Azure Virtual Desktop. Registration
completes only when the user runs the application in the MSIX package.
Delayed registration is currently the default configuration for MSIX app attach.
Deregistration
Deregistration removes a registered but non-running MSIX package for a user.
Deregistration happens while the user signs out of their session. During deregistration,
MSIX app attach pushes application data specific to the user to the local user profile.
Destage
Destaging notifies the OS that an MSIX package or application that currently isn't
running and isn't staged for any user can be unmounted. This removes all reference to it
in the OS.
CIM
.CIM is a new file extension associated with Composite Image Files System (CimFS).
Mounting and unmounting CIM files is faster that VHD files. CIM also consumes less
CPU and memory than VHD.
A CIM file is a file with a .CIM extension that contains metadata and at least two
additional files that contain actual data. The files within the CIM file don't have
extensions. The following table is a list of example files you'd find inside a CIM:
File name Extension Size
VSC CIM 1 KB
objectid_b5742e0b-1b98-40b3-94a6-9cb96f497e56_0 NA 27 KB
region_b5742e0b-1b98-40b3-94a6-9cb96f497e56_0 NA 428 KB
region_b5742e0b-1b98-40b3-94a6-9cb96f497e56_1 NA 217 KB
region_b5742e0b-1b98-40b3-94a6-9cb96f497e56_2 NA 264,132 KB
The following table is a performance comparison between VHD and CimFS. These
numbers were the result of a test run with five hundred 300 MB files in each format run
on a DSv4 machine.
Specs VHD CimFS
Average mount time 356 ms 255 ms
Average unmount time 1615 ms 36 ms
Memory consumption 6% (of 8 GB) 2% (of 8 GB)
CPU (count spike) Maxed out multiple times No impact
Next steps
If you want to learn more about MSIX app attach, check out our overview and FAQ.
Otherwise, get started with Set up app attach.
MSIX app attach FAQ
FAQ
This article answers frequently asked questions about MSIX app attach for Azure Virtual
Desktop.
What's the difference between MSIX

and MSIX app attach?
MSIX is a packaging format for apps, while MSIX app attach is the feature that delivers
MSIX packages to your deployment.
Does MSIX app attach use FSLogix?

MSIX app attach doesn't use FSLogix. However, MSIX app attach and FSLogix are
designed to work together to provide a seamless user experience.
Can I use the MSIX app attach outside

of Azure Virtual Desktop?
The APIs that power MSIX app attach are available for Windows 10 Enterprise. These
APIs can be used outside of Azure Virtual Desktop. However, there's no management
plane for MSIX app attach outside of Azure Virtual Desktop.
How do I get an MSIX package?

Your software vendor will give you an MSIX package. You can also convert non-MSIX
packages to MSIX. Learn more at How to move your existing installers to MSIX.
Which operating systems support MSIX

app attach?
Windows 10 Enterprise and Windows 10 Enterprise Multi-session, version 2004 or later.
Is MSIX app attach currently generally
available?
MSIX app attach is part of Windows 10 Enterprise and Windows 10 Enterprise Multi-
session, version 2004 or later. Both operating systems are currently generally available.
Can I use MSIX app attach outside of

Azure Virtual Desktop?
MSIX and MSIX app attach APIs are part of Windows 10 Enterprise and Windows 10
Enterprise Multi-session, version 2004 and later. We currently don't provide
management software for MSIX app attach outside of Azure Virtual Desktop.
Can I run two versions of the same

application at the same time?
For two version of the same MSIX applications to run simultaneously, the MSIX package
family defined in the appxmanifest.xml file must be different for each app.
Should I disable auto-update when

using MSIX app attach?
Yes. MSIX app attach doesn't support auto-update for MSIX applications.
How do permissions work with MSIX

app attach?
All virtual machines (VMs) in a host pool that uses MSIX app attach must have read
permissions on the file share where the MSIX images are stored. If it also uses Azure
Files, they'll need to be granted both role-based access control (RBAC) and New
Technology File System (NTFS) permissions.
How many users can use an MSIX image

handle?
MSIX app attach mounts MSIX images on a per-machine basis, not a per-user basis. The
amount of users who can use an MSIX image handle is based on the size of the
machine's file system and throughput of the network. Also, Azure Files has a limit of
2,000 open handles per file.
Can I use Azure Active Directory

Domain Services (Azure AD DS) with
MSIX app attach?
MSIX app attach doesn't currently support Azure AD DS. Because Azure AD DS
computer objects aren't synchronized to Azure Active Directory (Azure AD), the
administrator can't provide the required role-based access control (RBAC) permissions
for Azure Files.
Can I use MSIX app attach for HTTP or

HTTPs?
Using MSIX app attach over HTTP or HTTPs is currently not supported.
Can I restage the same MSIX

application?
Yes. You can restage applications you've already restaged, and this shouldn't cause any
errors.
Does MSIX app attach support self-

signed certificates?
Yes. You need to install the self-signed certificate on all the session host VMs where
MSIX app attach is used to host the self-signed application. Learn how to create a self-
signed certificate at Create a certificate for package signing.
What applications can I repackage to

MSIX?
Each application uses different features of the OS, programming languages, and
frameworks. To repackage your application, follow the directions in How to move your
existing installers to MSIX. You can find a list of the things you need in order to
repackage an application at Prepare to package a desktop application.
Certain applications can't be application layered, which means they can't be repackaged
into an MSIX file. Here's a list of the applications that can't be repackaged:
Drivers
Active-X or Silverlight
VPN clients
Antivirus programs
How many MSIX applications can I add

to each session host?
Each session host has different limits based on their CPU, memory, and OS. Going over
these limits can affect application performance and overall user experience. However,
MSIX app attach itself has no limit on how many applications it can use.
How many .VHD or .VHDX files can I

mount on a host pool?
MSIX app attach itself doesn't have a limit to the number of files you can mount.
However, the host pool itself can be limited by the following factors:
The ability of the OS to handle mounted volumes.

The maximum number of open files your storage solution or file system can hold.
The host pool's session host memory and CPU utilization.
In other words, the host pool's limits would be the same as if you're installing and
running the apps locally.
Should I timestamp my MSIX packages?

Check the MSIX packaging overview to see Microsoft's recommendations for using
timestamps.
Next steps
If you want to learn more about MSIX app attach, check out our overview and glossary.
Otherwise, get started with Set up app attach.
Supported features for Microsoft Teams
on Azure Virtual Desktop
This article lists the features of Microsoft Teams that Azure Virtual Desktop currently
supports and the minimum requirements to use each feature.
Supported features
The following table lists whether the Windows Desktop client or macOS client supports
specific features for Teams on Azure Virtual Desktop.
Feature Windows Desktop macOS

client client
Audio/video call Yes Yes
Screen share Yes Yes
Configure camera devices Yes Yes
Configure audio devices Yes No
Live captions Yes Yes
Communication Access Real-time Translation (CART) Yes Yes

transcriptions
Give and take control Yes Yes
Multiwindow Yes Yes
Background blur Yes Yes
Background images Yes Yes
Screen share and video together Yes Yes
Application window sharing Yes No
Secondary ringer Yes No
Dynamic e911 Yes Yes
Diagnostic overlay Yes No
Noise suppression Yes Yes

Minimum requirements
The following table lists the minimum required versions for each Teams feature. For
optimal user experience on Teams for Azure Virtual Desktop, we recommend using the
latest supported versions of each client and the WebRTC Redirector Service, which you
can find in the following list:

macOS client
Teams WebRTC Redirector Service
Teams desktop app
Supported Windows macOS WebRTC Redirector Service Teams version

features Desktop client version
client version version
Audio/video 1.2.1755 and 10.7.7 and 1.0.2006.11001 and later Updates within 90
call later later days of the current
version
Screen share 1.2.1755 and 10.7.7 and 1.0.2006.11001 and later Updates within 90
later later days of the current
version
Configure 1.2.1755 and 10.7.7 and 1.0.2006.11001 and later Updates within 90
camera later later days of the current
devices version
Configure 1.2.1755 and Not 1.0.2006.11001 and later Updates within 90

audio later supported days of the current
devices version
Live captions 1.2.2322 and 10.7.7 and 1.0.2006.11001 and later Updates within 90
later later days of the current
version
CART 1.2.2322 and 10.7.7 and 1.0.2006.11001 and later Updates within 90
transcriptions later later days of the current
version
Give and 1.2.2924 and 10.7.10 1.0.2006.11001 and later Updates within 90
take control later and later (Windows), 1.31.2211.15001 days of the current
and later (macOS) version
Multiwindow 1.2.1755 and 10.7.7 and 1.1.2110.16001 and later 1.5.00.11865 and
later later later
Background 1.2.3004 and 10.7.10 1.1.2110.16001 and later 1.5.00.11865 and

blur later and later later
Supported Windows macOS WebRTC Redirector Service Teams version
features Desktop client version
client version version
Background 1.2.3004 and 10.7.10 1.1.2110.16001 and later 1.5.00.11865 and

images later and later later
Screen share 1.2.1755 and 10.7.7 and 1.0.2006.11001 and later Updates within 90
and video later later days of the current
together version
Application 1.2.3770 and Not 1.31.2211.15001 Updates within 90

window later supported days of the current
sharing version
Secondary 1.2.3004 and 10.7.7 and 1.0.2006.11001 and later Updates within 90
ringer later later days of the current
version
Dynamic 1.2.2600 and 10.7.7 and 1.0.2006.11001 and later Updates within 90
e911 later later days of the current
version
Diagnostic 1.2.3316 and Not 1.17.2205.23001 and later Updates within 90

overlay later supported days of the current
version
Noise 1.2.3316 and 10.8.1 and 1.0.2006.11001 and later Updates within 90
suppression later later days of the current
version
Next steps
Learn more about how to set up Teams for Azure Virtual Desktop at Use Microsoft
Learn about the latest version of the Remote Desktop WebRTC Redirector Service at
What's new in the Remote Desktop WebRTC Redirector Service.
 Documentation
Troubleshoot Microsoft Teams on Azure Virtual Desktop - Azure
Known issues and troubleshooting instructions for Teams on Azure Virtual Desktop.
What's new in the Remote Desktop WebRTC Redirector Service?

New features and product updates the Remote Desktop WebRTC Redirector Service for Azure Virtual
Desktop.
Use Microsoft Teams on Azure Virtual Desktop - Azure

How to use Microsoft Teams on Azure Virtual Desktop.

How to use multimedia redirection on Azure Virtual Desktop.

Troubleshoot Multimedia redirection on Azure Virtual Desktop - Azure

Known issues and troubleshooting instructions for multimedia redirection for Azure Virtual Desktop.

Azure
Desktop.
Understanding multimedia redirection on Azure Virtual Desktop - Azure

An overview of multimedia redirection on Azure Virtual Desktop.
Show 5 more
Data locations for Azure Virtual Desktop
Azure Virtual Desktop is available in many Azure regions, which are grouped by
geography. When Azure Virtual Desktop resources are deployed, you have to specify the
Azure region they'll be created in. The location of the resource determines where its
information will be stored and the geography where related information will be stored.
Azure Virtual Desktop itself is a non-regional service where there's no dependency on a
specific Azure region. Learn more about Data residency in Azure and Azure
geographies .
Azure Virtual Desktop stores various information for service objects, such as host pool
names, application group names, workspace names, and user principal names. Data is
categorized into different types, such as customer input, customer data, diagnostic data,
and service-generated data. For more information about data category definitions, see
How Microsoft categorizes data for online services .
７ Note
Microsoft doesn't control or limit the regions where you or your users can access
your user and app-specific data.
Customer input
To set up Azure Virtual Desktop, you must create host pools and other service objects.
During configuration, you must enter information such as the host pool name,
application group name, and so on. This information is considered "customer input."
Customer input is stored in the geography associated with the Azure region the
resource is created in. The stored data includes all data that you input into the host pool
deployment process and any data you add after deployment while making configuration
changes to Azure Virtual Desktop objects. Basically, stored data is the same data you
can access using the Azure Virtual Desktop portal, PowerShell, or Azure command-line
interface (CLI). For example, you can review the available PowerShell commands to get
an idea of what customer input data the Azure Virtual Desktop service stores.
Azure Resource Manager paths to service objects are considered organizational

information, so data residency doesn't apply to them. Data about Azure Resource
Manager paths is stored outside of the chosen geography.
Customer data
The Azure Virtual Desktop service doesn't directly store any User data, i.e. user-created
data such as Word documents etc. or application related data such as databases or
configuation files, but it does store customer data, such as application names, virtual
machine names and user principal names etc., because they're part of the resource
deployment process, as described in the Customer input section above. This information
is stored in the geography associated with the region you created the resource in.
Please see the Data locations section below.
Diagnostic data
Diagnostic data is generated by the Azure Virtual Desktop service and is gathered
whenever administrators or users interact with the service. This data is only used for
troubleshooting, support, and checking the health of the service in aggregate form. For
example, when a session host VM is registered to a host pool, information is generated
that includes the virtual machine (VM) name, which host pool the VM belongs to, and so
on. This information is stored in the geography associated with the Azure region the
host pool is created in. Also, when a user connects to the service and launches a session,
diagnostic information is generated that includes the user principal name, client
location, client IP address, which host pool the user is connecting to, and so on. This
information is sent to two different locations:
The location closest to the user where the service infrastructure (client traces, user
traces, and diagnostic data) is present.
The location where the host pool is located.
Service-generated data
To keep Azure Virtual Desktop reliable and scalable, traffic patterns and usage are
aggregated to check the health and performance of the infrastructure control plane. For
example, to help us understand how to ramp up regional infrastructure capacity as
service usage increases, we process service usage log data. We then review the logs for
peak times and decide where to increase capacity.
Data locations
Storing Customer data and service-generated data is currently supported in the
following geographies:
United States (US)
Europe (EU)
United Kingdom (UK)
Canada (CA)
Japan (JP)
Australia (AU)
India (IN)
In addition, service-generated data is aggregated from all locations where the service
infrastructure is, and sent to the US geography. The data sent to the US includes
scrubbed data, but not customer data.
Data storage
Stored information is encrypted at rest, and geo-redundant mirrors are maintained
within the geography. Data generated by the Azure Virtual Desktop service is replicated
within the Azure geography for disaster recovery purposes.
User-created or app-related information, such as app settings and user data, resides in
the Azure region you choose and isn't managed by the Azure Virtual Desktop service.
Azure Virtual Desktop FAQ
FAQ
This article answers frequently asked questions and explains best practices for Azure
Virtual Desktop.
What are the minimum admin

permissions I need to manage objects?
If you want to create host pools and other objects, you must be assigned the
Contributor role on the subscription or resource group you're working with.
You must be assigned the User Access Admin role on an app group to publish app
groups to users or user groups.
To restrict an admin to only manage user sessions, such as sending messages to users,
signing out users, and so on, you can create custom roles. For example:
JSON
"actions": [
"Microsoft.Resources/deployments/operations/read",
"Microsoft.Resources/tags/read",
"Microsoft.Authorization/roleAssignments/read",
"Microsoft.DesktopVirtualization/hostpools/sessionhosts/usersessions/*",
"Microsoft.DesktopVirtualization/hostpools/sessionhosts/read",
"Microsoft.DesktopVirtualization/hostpools/sessionhosts/write"
],
"notActions": [],
"dataActions": [],
"notDataActions": []
Does Azure Virtual Desktop support

split Azure Active Directory models?
When a user is assigned to an app group, the service does a simple Azure role
assignment. As a result, the user's Azure Active Directory (Azure AD) and the app
group's Azure AD must be in the same location. All service objects, such as host pools,
app groups, and workspaces, also must be in the same Azure AD as the user.
You can create virtual machines (VMs) in a different Azure AD as long as you sync the
Active Directory with the user's Azure AD in the same virtual network (VNET).
What are location restrictions?

All service resources have a location associated with them. A host pool's location
determines which geography the service metadata for the host pool is stored in. An app
group can't exist without a host pool. If you add apps to a RemoteApp app group, you'll
also need a session host to determine the start menu apps. For any app group action,
you'll also need a related data access on the host pool. To make sure data isn't being
transferred between multiple locations, the app group's location should be the same as
the host pool's.
Workspaces also must be in the same location as their app groups. Whenever the
workspace updates, the related app group updates along with it. Like with app groups,
the service requires that all workspaces are associated with app groups created in the
same location.
How do you expand an object's

properties in PowerShell?
When you run a PowerShell cmdlet, you only see the resource name and location.
For example:
PowerShell
Get-AzWvdHostPool -Name 0224hp -ResourceGroupName 0224rg
Location Name Type
-------- ---- ----
westus 0224hp Microsoft.DesktopVirtualization/hostpools
To see all of a resource's properties, add either format-list or fl to the end of the
cmdlet.
For example:
PowerShell
Get-AzWvdHostPool -Name 0224hp -ResourceGroupName 0224rg |fl
To see specific properties, add the specific property names after format-list or fl .
For example:
PowerShell
Get-AzWvdHostPool -Name demohp -ResourceGroupName 0414rg |fl

CustomRdpProperty
CustomRdpProperty :
audiocapturemode:i:0;audiomode:i:0;drivestoredirect:s:;redirectclipboard:i:1
;redirectcomports:i:0;redirectprinters:i:1;redirectsmartcards:i:1;screen
modeid:i:2;

guest users?
Azure Virtual Desktop doesn't support Azure AD guest user accounts. For example, let's
say a group of guest users have Microsoft 365 E3 Per-user, Windows E3 Per-user, or
WIN VDA licenses in their own company, but are guest users in a different company's
Azure AD. The other company would manage the guest users' user objects in both
Azure AD and Active Directory like local accounts.
You can't use your own licenses for the benefit of a third party. Also, Azure Virtual
Desktop doesn't currently support Microsoft Account (MSA).
Why don't I see the client IP address in

the WVDConnections table?
We don't currently have a reliable way to collect the web client's IP addresses, so we
don't include that value in the table.
How does Azure Virtual Desktop handle

backups?
There are multiple options in Azure Virtual Desktop for handling backup. At the
Compute level, backup is recommended only for Personal Host Pools through Azure
Backup. At the Storage level, recommended backup solution varies based on the
backend storage used to store user profiles. If Azure Files Share is used, Azure Backup
for File Share is recommended. If Azure NetApp Files is used, Snaphots/Policies or Azure
NetApp Files Backup are tools available.

third-party collaboration apps?
Azure Virtual Desktop is currently optimized for Teams. Microsoft currently doesn't
support third-party collaboration apps like Zoom. Third-party organizations are
responsible for giving compatibility guidelines to their customers. Azure Virtual Desktop
also doesn't support Skype for Business.
Can I change from pooled to personal

host pools?
Once you create a host pool, you can't change its type. However, you can move any
VMs you register to a host pool to a different type of host pool.
What's the largest profile size FSLogix

can handle?
Limitations or quotas in FSLogix depend on the storage fabric used to store user profile
VHD(X) files.
The following table gives an example of how many IOPS an FSLogix profile needs to
support each user. Requirements can vary widely depending on the user, applications,
and activity on each profile.
Resource Requirement
Steady state IOPS 10
Sign in/sign out IOPS 50
The example in this table is of a single user, but can be used to estimate requirements
for the total number of users in your environment. For example, you'd need around
1,000 IOPS for 100 users, and around 5,000 IOPS during sign-in and sign-out.
Is there a scale limit for host pools
created in the Azure portal?
These factors can affect scale limit for host pools:
The Azure template is limited to 800 objects. To learn more, see Azure subscription
and service limits, quotas, and constraints. Each VM also creates about six objects,
so that means you can create around 132 VMs each time you run the template.
There are restrictions on how many cores you can create per region and per
subscription. For example, if you have an Enterprise Agreement subscription, you
can create 350 cores. You'll need to divide 350 by either the default number of
cores per VM or your own core limit to determine how many VMs you can create
each time you run the template. Learn more at Virtual Machines limits - Azure
Resource Manager.
The VM prefix name and the number of VMs is fewer than 15 characters. To learn
more, see Naming rules and restrictions for Azure resources.
Can I manage Azure Virtual Desktop

environments with Azure Lighthouse?
Azure Lighthouse doesn't fully support managing Azure Virtual Desktop environments.
Since Lighthouse doesn't currently support cross-Azure AD tenant user management,
Lighthouse customers still need to sign in to the Azure AD that customers use to
manage users.
You also can't use CSP sandbox subscriptions with the Azure Virtual Desktop service. To
learn more, see Integration sandbox account.
Finally, if you enabled the resource provider from the CSP owner account, the CSP
customer accounts won't be able to modify the resource provider.
How often should I turn my VMs on to

prevent registration issues?
After you register a VM to a host pool within the Azure Virtual Desktop service, the
agent regularly refreshes the VM's token whenever the VM is active. The certificate for
the registration token is valid for 90 days. Because of this 90-day limit, we recommend
VMs to be online for 20 minutes every 90 days so that the machine can refresh its
tokens and update the agent and side-by-side stack components. Turning your VM on
within this time limit will prevent its registration token from expiring or becoming
invalid. If you've started your VM after 90 days and are experiencing registration issues,
follow the instructions in the Azure Virtual Desktop agent troubleshooting guide to
remove the VM from the host pool, reinstall the agent, and reregister it to the pool.
Can I set availability options when

creating host pools?
Yes. Azure Virtual Desktop host pools have an option for selecting either availability set
or availability zones when you create a VM. These availability options are the same as
the ones Azure Compute uses. If you select a zone for the VM you create in a host pool,
the setting automatically applies to all VMs you create in that zone. If you'd prefer to
spread your host pool VMs across multiple zones, you'll need to follow the directions in
Add virtual machines with the Azure portal to manually select a new zone for each new
VM you create.
Make sure that your Azure availability zones are available in the region where your VMs
are located.
Which availability option is best for me?

The availability option you should use for your VMs depends on your image's location.
The following table explains the relationship each setting has with these variables to
help you figure out which option is best for your deployment.
Availability option Image location
None Gallery
None Blob storage
Availability zone Gallery (blob storage option disabled)
Availability set with managed SKU (managed disk) Gallery
Availability set with managed SKU (managed disk) Blob storage

Availability option Image location
Availability set with managed SKU (managed disk) Blob storage (Gallery option disabled)
Availability set (newly created by user) Gallery
Availability set (newly created by user) Blob storage
Should I use Windows Defender

Application Control or AppLocker to
control which applications and drivers
are allowed to run on my Windows 10
devices?
We recommend you use Windows Defender Application Control instead of AppLocker.
When I'm testing migration, can I have

the two different Azure Virtual Desktop
environments exist in the same tenant?
Yes. You can have both deployments within the same Azure Active Directory tenant.
Are ephemeral OS disks for Azure VMs

supported with Azure Virtual Desktop?
No. Ephemeral OS disks for Azure VMs are not supported with Azure Virtual Desktop.
If I store my host pools and VMs in

different regions, what would happen in
a disaster scenario where the host pool
region goes down but the VM region
stays online?
If the region you stored your host pool metadata in goes down, Azure Virtual Desktop
won't accept new user connections to the session host VMs in that host pool. However,
any existing sessions on the session host VMs in that host pool will remain connected
and unaffected.
What happens when you try to add

more than 200 VMs to an availability set
in Azure Virtual Desktop?
If you try to go over 200 VMs in an availability set in Azure Virtual Desktop, you'll receive
an error message that says "Can't create VM because the limit of 200 VMs has already
been reached." For more information, see the Availability sets overview.
Azure Virtual Desktop for Azure Stack
HCI overview (preview)
Azure Virtual Desktop for Azure Stack HCI (preview) lets you deploy Azure Virtual
Desktop session hosts on your on-premises Azure Stack HCI infrastructure. You manage
your session hosts from the Azure portal.
Overview
If you already have an existing on-premises Virtual Desktop Infrastructure (VDI)
deployment, Azure Virtual Desktop for Azure Stack HCI can improve your experience. If
you're already using Azure Virtual Desktop in the cloud, you can extend your
deployment to your on-premises infrastructure to better meet your performance or data
locality needs.
Azure Virtual Desktop for Azure Stack HCI is currently in public preview. As such, it
doesn't currently support certain important Azure Virtual Desktop features. Because of
these limitations, we don't recommend using this feature for production workloads yet.
） Important
See the Supplemental Terms of Use for Microsoft Azure Previews for legal
terms that apply to Azure features that are in beta.
７ Note
Azure Virtual Desktop for Azure Stack HCI is not an Azure Arc-enabled service. As
such, it is not supported outside of Azure, in a multi-cloud environment, or on
Azure Arc-enabled servers besides Azure Stack HCI virtual machines as described in
this article.
Benefits
With Azure Virtual Desktop for Azure Stack HCI, you can:
Improve performance for Azure Virtual Desktop users in areas with poor
connectivity to the Azure public cloud by giving them session hosts closer to their
location.
Meet data locality requirements by keeping app and user data on-premises. For
more information, see Data locations for Azure Virtual Desktop.
Improve access to legacy on-premises apps and data sources by keeping virtual
desktops and apps in the same location.
Reduce costs and improve user experience with Windows 10 and Windows 11
Enterprise multi-session virtual desktops.
Simplify your VDI deployment and management compared to traditional on-

premises VDI solutions by using the Azure portal.
Achieve best performance by leveraging RDP Shortpath for low-latency user

access.
Deploy the latest fully patched images quickly and easily using Azure Marketplace
images.
Supported platforms
Azure Virtual Desktop for Azure Stack HCI supports the same Remote Desktop clients as
Azure Virtual Desktop, and supports the following x64 operating system images:
Windows 11 Enterprise multi-session

Windows 11 Enterprise
Windows 10 Enterprise multi-session, version 21H2
Windows 10 Enterprise, version 21H2
Windows Server 2022
Windows Server 2019
Pricing
The following things affect how much it costs to run Azure Virtual Desktop for Azure
Stack HCI:
Infrastructure costs. You'll pay monthly service fees for Azure Stack HCI. Learn
more at Azure Stack HCI pricing .
User access rights. The same licenses that grant access to Azure Virtual Desktop in
the cloud also apply to Azure Virtual Desktop for Azure Stack HCI. Learn more at
Azure Virtual Desktop pricing .
Hybrid service fee. This fee requires you to pay for each active virtual CPU (vCPU)
of Azure Virtual Desktop session hosts you're running on Azure Stack HCI. This fee
will become active once the preview period ends.
Data storage
Azure Virtual Desktop for Azure Stack HCI doesn't guarantee that all data is stored on-
premises. You can choose to store user data on-premises by locating session host virtual
machines (VMs) and associated services such as file servers on-premises. However, some
customer data, diagnostic data, and service-generated data are still stored in Azure. For
more information on how Azure Virtual Desktop stores different kinds of data, see Data
locations for Azure Virtual Desktop.
Known issues and limitations

The following issues affect the preview version of Azure Virtual Desktop for Azure Stack
HCI:
Templates may show failures in certain cases at the domain-joining step. To

proceed, you can manually join the session hosts to the domain. For more
information, see VM provisioning through Azure portal on Azure Stack HCI.
Azure Stack HCI host pools don't currently support the following Azure Virtual
Desktop features:
Session host scaling with Azure Automation
Autoscale plan
Start VM On Connect
Multimedia redirection (preview)
Per-user access pricing
Azure Virtual Desktop for Azure Stack HCI doesn't currently support host pools
containing both cloud and on-premises session hosts. Each host pool in the
deployment must have only one type of host pool.
Session hosts on Azure Stack HCI don't support certain cloud-only Azure services.
Because Azure Stack HCI supports so many types of hardware and on-premises
networking capabilities that performance and user density may vary widely
between session hosts running in the Azure cloud. Azure Virtual Desktop's virtual
machine sizing guidelines are broad, so you should only use them for initial
performance estimates.
Next steps
Set up Azure Virtual Desktop for Azure Stack HCI (preview).
Azure Virtual Desktop for the
enterprise
Azure Active Directory Active Directory Domain Services Virtual Network Azure Virtual Desktop
Azure Virtual Desktop is a desktop and application virtualization service that runs in
Azure. This article is intended to help desktop infrastructure architects, cloud architects,
desktop administrators, and system administrators explore Azure Virtual Desktop and
build virtualized desktop infrastructure (VDI) solutions at enterprise scale. Enterprise-
scale solutions generally cover 1,000 or more virtual desktops.
Architecture
A typical architectural setup for Azure Virtual Desktop is illustrated in the following
diagram:
Download a Visio file of this architecture.
Dataflow
The diagram's dataflow elements are described here:
The application endpoints are in a customer's on-premises network. Azure

ExpressRoute extends the on-premises network into Azure, and Azure Active
Directory (Azure AD) Connect integrates the customer's Active Directory Domain
Services (AD DS) with Azure AD.
The Azure Virtual Desktop control plane handles web access, gateway, broker,
diagnostics, and extensibility components such as REST APIs.
The customer manages AD DS and Azure AD, Azure subscriptions, virtual networks,
Azure Files or Azure NetApp Files, and the Azure Virtual Desktop host pools and
workspaces.
To increase capacity, the customer uses two Azure subscriptions in a hub-spoke

architecture and connects them via virtual network peering.
For more information about FSLogix Profile Container - Azure Files and Azure NetApp
Files best practices, see FSLogix for the enterprise.
Components
Azure Virtual Desktop service architecture is similar to Windows Server Remote Desktop
Services. Although Microsoft manages the infrastructure and brokering components,
enterprise customers manage their own desktop host virtual machines (VMs), data, and
clients.
Components that Microsoft manages

Microsoft manages the following Azure Virtual Desktop services, as part of Azure:
Web Access: By using the Web Access service within Azure Virtual Desktop you can
access virtual desktops and remote apps through an HTML5-compatible web
browser just as you would with a local PC, from anywhere and on any device. You
can secure web access by using multifactor authentication in Azure Active
Directory.
Gateway: The Remote Connection Gateway service connects remote users to Azure
Virtual Desktop apps and desktops from any internet-connected device that can
run an Azure Virtual Desktop client. The client connects to a gateway, which then
orchestrates a connection from a VM back to the same gateway.
Connection Broker: The Connection Broker service manages user connections to

virtual desktops and remote apps. Connection Broker provides load balancing and
reconnection to existing sessions.
Diagnostics: Remote Desktop Diagnostics is an event-based aggregator that marks

each user or administrator action on the Azure Virtual Desktop deployment as a
success or failure. Administrators can query the event aggregation to identify
failing components.
Extensibility components: Azure Virtual Desktop includes several extensibility
components. You can manage Azure Virtual Desktop by using Windows PowerShell
or with the provided REST APIs, which also enable support from third-party tools.
Components that you manage

You manage the following components of Azure Virtual Desktop solutions:
Azure Virtual Network: With Azure Virtual Network , Azure resources such as
VMs can communicate privately with each other and with the internet. By
connecting Azure Virtual Desktop host pools to an Active Directory domain, you
can define network topology to access virtual desktops and virtual apps from the
intranet or internet, based on organizational policy. You can connect an Azure
Virtual Desktop instance to an on-premises network by using a virtual private
network (VPN), or you can use Azure ExpressRoute to extend the on-premises
network into Azure over a private connection.
Azure AD: Azure Virtual Desktop uses Azure AD for identity and access
management. Azure AD integration applies Azure AD security features, such as
conditional access, multifactor authentication, and Intelligent Security Graph ,
and it helps maintain app compatibility in domain-joined VMs.
Active Directory Domain Services: Azure Virtual Desktop VMs must domain-join
an AD DS service, and AD DS must be in sync with Azure AD to associate users
between the two services. You can use Azure AD Connect to associate AD DS with
Azure AD.
Azure Virtual Desktop session hosts: Session hosts are VMs that users connect to
for their desktops and applications. Several versions of Windows are supported
and you can create images with your applications and customizations. You can
choose VM sizes, including GPU-enabled VMs. Each session host has an Azure
Virtual Desktop host agent, which registers the VM as part of the Azure Virtual
Desktop workspace or tenant. Each host pool can have one or more app groups,
which are collections of remote applications or desktop sessions that you can
access. To see which versions of Windows are supported, see Operating systems
and licenses.
Azure Virtual Desktop workspace: The Azure Virtual Desktop workspace or tenant
is a management construct for managing and publishing host pool resources.
Scenario details
Potential use cases
The greatest demand for enterprise virtual desktop solutions comes from:
Security and regulation applications, such as financial services, healthcare, and

government.
Elastic workforce needs, such as remote work, mergers and acquisitions, short-term
employees, contractors, and partner access.
Specific employees, such as bring your own device (BYOD) and mobile users, call
centers, and branch workers.
Specialized workloads, such as design and engineering, legacy apps, and software
development testing.
Personal and pooled desktops

By using personal desktop solutions, sometimes called persistent desktops, users can
always connect to the same specific session host. Users can ordinarily modify their
desktop experience to meet personal preferences, and they can save files in the desktop
environment. Personal desktop solutions:
Let users customize their desktop environment, including user-installed

applications, and users can save files within the desktop environment.
Allow assigning dedicated resources to specific users, which can be helpful for
some manufacturing or development use cases.
Pooled desktop solutions, also called non-persistent desktops, assign users to whichever
session host is currently available, depending on the load-balancing algorithm. Because
users don't always return to the same session host each time they connect, they have
limited ability to customize the desktop environment and don't usually have
administrator access.
Windows servicing
There are several options for updating Azure Virtual Desktop instances. Deploying an
updated image every month guarantees compliance and state.
Microsoft Endpoint Configuration Manager (MECM) updates server and desktop

operating systems.
Windows Updates for Business updates desktop operating systems such as
Windows 10 multi-session.
Azure Update Management updates server operating systems.
Azure Log Analytics checks compliance.
Deploy a new (custom) image to session hosts every month for the latest Windows
and applications updates. You can use an image from Azure Marketplace or a
custom Azure-managed image.
Relationships between key logical components

The relationships between host pools, workspaces, and other key logical components
vary. They're summarized in the following diagram:
The numbers in the following descriptions correspond to those in the preceding diagram.
(1) An application group that contains a published desktop can only contain MSIX
packages mounted to the host pool (the packages will be available in the Start
menu of the session host), it can't contain any other published resources and is
called a desktop application group.
(2) Application groups assigned to the same host pool must be members of the
same workspace.
(3) A user account can be assigned to an application group either directly or via an
Azure AD group. It's possible to assign no users to an application group, but then
it can't service any.
(4) It's possible to have an empty workspace, but it can't service users.
(5) It's possible to have an empty host pool, but it can't service users.
(6) It's possible for a host pool not to have any application groups assigned to it
but it can't service users.
(7) Azure AD is required for Azure Virtual Desktop. This is because Azure AD user
accounts and groups must always be used to assign users to Azure Virtual Desktop
application groups. Azure AD is also used to authenticate users into the Azure
Virtual Desktop service. Azure Virtual Desktop session hosts can also be members
of an Azure AD domain, and in this situation the Azure Virtual Desktop-published
applications and desktop sessions will also be launched and run (not just assigned)
by using Azure AD accounts.
(7) Alternatively, Azure Virtual Desktop session hosts can be members of an AD
DS domain, and in this situation the Azure Virtual Desktop-published
applications and desktop sessions will be launched and run (but not assigned)
by using AD DS accounts. To reduce user and administrative overhead, AD DS
can be synchronized with Azure AD through Azure AD Connect.
(7) Finally, Azure Virtual Desktop session hosts can, instead, be members of an
Azure AD DS domain, and in this situation the Azure Virtual Desktop-published
applications and desktop sessions will be launched and run (but not assigned)
by using Azure AD DS accounts. Azure AD is automatically synchronized with
Azure AD DS, one way, from Azure AD to Azure AD DS only.
Resource Purpose Logical relationships
Published A Windows desktop Member of one and only one

desktop environment that runs on application group (1)
session hosts and is
delivered to users over the
network
Published A Windows application that Member of one and only one

application runs on Azure Virtual application group
Desktop session hosts and is
delivered to users over the
network
Application A logical grouping of - Contains a published desktop (1) or

group published applications or a one or more published applications
published desktop - Assigned to one and only one host

pool (2)
- Member of one and only one

workspace (2)
- One or more Azure AD user

accounts or groups are assigned to it
(3)
Azure AD user Identifies the users who are - Member of one and only one Azure
account/group permitted to launch Active Directory
published desktops or - Assigned to one or more

applications application groups (3)
Azure AD (7) Identity provider - Contains one or more user accounts

or groups, which must be used to
assign users to application groups,
and can also be used to log in to the
session hosts
- Can hold the memberships of the

session hosts
- Can be synchronized with AD DS or

Azure AD DS
AD DS (7) Identity and directory - Contains one or more user accounts

services provider or groups, which can be used to log
in to the session hosts

session hosts
- Can be synchronized with Azure AD
Azure AD DS Platform as a service (PaaS)- - Contains one or more user accounts

(7) based identity and directory or groups, which can be used to log
services provider in to the session hosts

session hosts
- Synchronized with Azure AD
Workspace A logical grouping of Contains one or more application

application groups groups (4)
Host pool A group of identical session - Contains one or more session hosts
hosts that serve a common (5)
purpose - One or more application groups are

assigned to it (6)
Session host A virtual machine that hosts Member of one and only one host
published desktops or pool
applications
Considerations
These considerations implement the pillars of the Azure Well-Architected Framework,
which is a set of guiding tenets that can be used to improve the quality of a workload.
For more information, see Microsoft Azure Well-Architected Framework.
The numbers in the following sections are approximate. They're based on a variety of
large customer deployments and are subject to change over time.
Also, note that:
You can't create more than 500 application groups per single Azure AD tenant*.
We recommend that you do not publish more than 50 applications per application
group.
Azure Virtual Desktop limitations

Azure Virtual Desktop, much like Azure, has certain service limitations that you need to
be aware of. To avoid having to make changes in the scaling phase, it's a good idea to
address some of these limitations during the design phase.
Azure Virtual Desktop object Per Parent container object Service limit
Workspace Azure Active Directory tenant 1300
HostPool Workspace 400
Application group Azure Active Directory tenant 500*

Azure Virtual Desktop object Per Parent container object Service limit
RemoteApp Application group 500
Role assignment Any Azure Virtual Desktop object 200
Session host HostPool 10,000
*If you require more than 500 application groups, submit a support ticket via the Azure
portal.
We recommend that you deploy no more than 5,000 VMs per Azure subscription
per region. This recommendation applies to both personal and pooled host pools,
based on Windows Enterprise single and multi-session. Most customers use
Windows Enterprise multi-session, which allows multiple users to log in to each
VM. You can increase the resources of individual session-host VMs to
accommodate more user sessions.
For automated session-host scaling tools, the limits are around 2,500 VMs per
Azure subscription per region, because VM status interaction consumes more
resources.
To manage enterprise environments with more than 5,000 VMs per Azure
subscription in the same region, you can create multiple Azure subscriptions in a
hub-spoke architecture and connect them via virtual network peering, as in the
preceding example architecture. You could also deploy VMs in a different region in
the same subscription to increase the number of VMs.
Azure Resource Manager (ARM) subscription API throttling limits don't allow more
than 600 Azure VM reboots per hour via the Azure portal. You can reboot all your
machines at once via the operating system, which doesn't consume any Azure
Resource Manager subscription API calls. For more information about counting
and troubleshooting throttling limits based on your Azure subscription, see
Troubleshoot API throttling errors.
You can currently deploy 399 VMs per Azure Virtual Desktop ARM template
deployment without Availability Sets, or 200 VMs per Availability Set. You can
increase the number of VMs per deployment by switching off Availability Sets in
either the ARM template or the Azure portal host pool enrollment.
Azure VM session-host name prefixes can't exceed 11 characters, due to auto-
assigning of instance names and the NetBIOS limit of 15 characters per computer
account.
By default, you can deploy up to 800 instances of most resource types in a
resource group. Azure Compute doesn't have this limit.
For more information about Azure subscription limitations, see Azure subscription and
service limits, quotas, and constraints.
VM sizing
Virtual machine sizing guidelines lists the maximum suggested number of users per
virtual central processing unit (vCPU) and minimum VM configurations for different
workloads. This data helps estimate the VMs you need in your host pool.
Use simulation tools to test deployments with both stress tests and real-life usage
simulations. Make sure that the system is responsive and resilient enough to meet user
needs, and remember to vary the load sizes when testing.
Cost optimization
Cost optimization is about looking at ways to reduce unnecessary expenses and
improve operational efficiencies. For more information, see Overview of the cost
optimization pillar.
You can architect your Azure Virtual Desktop solution to realize cost savings. Here are
five different options to help manage costs for enterprises:
Windows 10 multi-session: By delivering a multi-session desktop experience for

users with identical compute requirements, you can let more users log in to a
single VM at once, an approach that can result in considerable cost savings.
Azure Hybrid Benefit: If you have Software Assurance, you can use Azure Hybrid
Benefit for Windows Server to save on the cost of your Azure infrastructure.
Azure Reserved VM Instances: You can prepay for your VM usage and save
money. Combine Azure Reserved VM Instances with Azure Hybrid Benefit for up
to 80 percent savings over list prices.
Session-host load-balancing: When you're setting up session hosts, breadth-first
mode, which spreads users randomly across the session hosts, is the standard
default mode. Alternatively, you can use depth-first mode to fill up a session-host
server with the maximum number of users before it moves on to the next session
host. You can adjust this setting for maximum cost benefits.
Deploy this scenario

Use the ARM templates to automate the deployment of your Azure Virtual Desktop
environment. These ARM templates support only Azure Resource Manager's Azure
Virtual Desktop objects. These ARM templates don't support Azure Virtual Desktop
(classic).
Contributors
This article is maintained by Microsoft. It was originally written by the following
contributors.
Principal author:
Tom Hickling | Senior Product Manager, Azure Virtual Desktop Engineering
Other contributor:
Nelson Del Villar | Senior Customer Engineer, Azure Core Infrastructure
Next steps
Azure Virtual Desktop partner integrations lists approved Azure Virtual Desktop
partner providers and independent software vendors.
Use the Virtual Desktop Optimization Tool to help optimize performance in a
Windows 10 Enterprise VDI (virtual desktop infrastructure) environment.
See Deploy Azure AD-joined virtual machines in Azure Virtual Desktop.
Learn more about Active Directory Domain Services.
What is Azure AD Connect?
Related resources
For best practices documentation, see FSLogix for the enterprise.
For more information about multiple Active Directory forests architecture, see
Multiple Active Directory forests architecture in Azure Virtual Desktop.
Multiple forests with AD DS and
Azure AD
Azure Virtual Desktop Azure Active Directory Active Directory Domain Services ExpressRoute Storage
Many organizations want to take advantage of Azure Virtual Desktop to create

environments that have multiple on-premises Active Directory forests.
This article expands on the architecture that's described in the Azure Virtual Desktop at
enterprise scale article. It's intended to help you understand how to integrate multiple
domains and Azure Virtual Desktop by using Azure Active Directory (Azure AD) Connect
to sync users from on-premises Active Directory Domain Services (AD DS) to Azure AD.
Architecture
Dataflow
In this architecture, the identity flow works as follows:
1. Azure AD Connect syncs users from both CompanyA.com and CompanyB.com to
an Azure AD tenant (NewCompanyAB.onmicrosoft.com).
2. Host pools, workspaces, and app groups are created in separate subscriptions and
spoke virtual networks.
3. Users are assigned to the app groups.
4. Azure Virtual Desktop session hosts in the host pools join the domains
CompanyA.com and CompanyB.com by using the domain controllers in Azure.
5. Users sign in by using either the Azure Virtual Desktop application or the web
client with a User Principal Name (UPN) in the following format:
user@NewCompanyA.com, user@CompanyB.com, or user@NewCompanyAB.com,
depending on their configured UPN suffix.
6. Users are presented with their respective virtual desktops or applications. For
example, users in CompanyA are presented with a virtual desktop or application in
Workspace A, host pool 1 or 2.
7. FSLogix user profiles are created in Azure Files shares on the corresponding
storage accounts.
8. Group Policy Objects (GPOs) that are synced from on-premises are applied to users
and Azure Virtual Desktop session hosts.
Components
This architecture uses the same components as those listed in Azure Virtual Desktop at
enterprise scale architecture.
Additionally, this architecture uses the following components:
Azure AD Connect in staging mode: The Staging server for Azure AD Connect
topologies provides additional redundancy for the Azure AD Connect instance.
Azure subscriptions, Azure Virtual Desktop workspaces, and host pools: You can
use multiple subscriptions, Azure Virtual Desktop workspaces, and host pools for
administration boundaries and business requirements.
Scenario details
This architecture diagram represents a typical scenario that contains the following
elements:
The Azure AD tenant is available for a new company named

NewCompanyAB.onmicrosoft.com.
Azure AD Connect syncs users from on-premises AD DS to Azure AD.
Company A and Company B have separate Azure subscriptions. They also have a
shared services subscription, referred to as the Subscription 1 in the diagram.
An Azure hub-spoke architecture is implemented with a shared services hub virtual
network.
Complex hybrid on-premises Active Directory environments are present with two
or more Active Directory forests. Domains live in separate forests, each with a
different UPN suffix. For example, CompanyA.local with the UPN suffix
CompanyA.com, CompanyB.local with the UPN suffix CompanyB.com, and an
additional UPN suffix, NewCompanyAB.com.
Domain controllers for both forests are located on-premises and in Azure.
Verified domains are present in Azure for CompanyA.com, CompanyB.com, and
NewCompanyAB.com.
GPO and legacy authentication, such as Kerberos, NTLM (Windows New
Technology LAN Manager), and LDAP (Lightweight Directory Access Protocol) , is
used.
For Azure environments that still have dependency on-premises infrastructure,
private connectivity (Site-to-site VPN or Azure ExpressRoute) is set up between on-
premises and Azure.
The Azure Virtual Desktop environment consists of an Azure Virtual Desktop
workspace for each business unit and two host pools per workspace.
The Azure Virtual Desktop session hosts are joined to domain controllers in Azure.
That is, CompanyA session hosts join the CompanyA.local domain, and CompanyB
session hosts join the CompanyB.local domain.
Azure storage accounts can use Azure Files for FSLogix profiles. One account is
created per company domain (that is, CompanyA.local and CompanyB.local), and
the account is joined to the corresponding domain.
７ Note
Active Directory Domain Services is a self-managed, on-premises component in

many hybrid environments, and Azure Active Directory Domain Services (Azure AD
DS) provides managed domain services with a subset of fully compatible,
traditional AD DS features such as domain join, group policy, LDAP, and
Kerberos/NTLM authentication. For a detailed comparison of these components,
see Compare self-managed AD DS, Azure AD, and managed Azure AD DS.
The solution idea Multiple Azure Virtual Desktop forests using Azure Active
Directory Domain Services discusses architecture that uses cloud-managed Azure
AD DS.
Potential use cases
Here are a few relevant use cases for this architecture:
Mergers and acquisitions, organization rebranding, and multiple on-premises

identities
Complex on-premises active directory environments (multi-forest, multi-domains,
group policy (or GPO) requirements, and legacy authentication)
On-premises GPO infrastructure with Azure Virtual Desktop
Considerations
When you're designing your workload based on this architecture, keep the following
ideas in mind.
Group Policy Objects

To extend GPO infrastructure for Azure Virtual Desktop, the on-premises domain
controllers should sync to the Azure infrastructure as a service (IaaS) domain
controllers.
Extending GPO infrastructure to Azure IaaS domain controllers requires private

connectivity.
Network and connectivity

The domain controllers are shared components, so they need to be deployed in a
shared services hub virtual network in this hub-spoke architecture.
Azure Virtual Desktop session hosts join the domain controller in Azure over their
respective hub-spoke virtual network peering.
Azure Storage
The following design considerations apply to user profile containers, cloud cache
containers, and MSIX packages:
You can use both Azure Files and Azure NetApp Files in this scenario. You choose
the right solution based on factors such as expected performance, cost, and so on.
Both Azure storage accounts and Azure NetApp Files are limited to joining to one
single AD DS at a time. In these cases, multiple Azure storage accounts or Azure
NetApp Files instances are required.
Azure Active Directory

In scenarios with users in multiple on-premises Active Directory forests, only one Azure
AD Connect sync server is connected to the Azure AD tenant. An exception to this is an
Azure AD Connect server that's used in staging mode.
The following identity topologies are supported:
Multiple on-premises Active Directory forests.

One or more resource forests trust all account forests.
A full mesh topology allows users and resources to be in any forest. Commonly,
there are two-way trusts between the forests.
For more details, see the Staging server section of Azure AD Connect topologies.
Contributors
contributors.
Principal author:
Tom Maher | Senior Security and Identity Engineer
Next steps
For more information, see the following articles:
Azure AD Connect topology
Compare different identity options: Self-managed Active Directory Domain
Services (AD DS), Azure Active Directory (Azure AD), and Azure Active Directory
Domain Services (Azure AD DS)
Related resources
Azure Virtual Desktop for the enterprise
Solution idea: Multiple forests with Azure AD DS
Multiple forests with AD DS,
Azure AD, and Azure AD DS
Azure Active Directory Active Directory Domain Services Files Azure Virtual Desktop
Solution ideas
This article is a solution idea. If you'd like us to expand the content with more
information, such as potential use cases, alternative services, implementation
considerations, or pricing guidance, let us know by providing GitHub feedback .
This solution idea illustrates how to deploy Azure Virtual Desktop rapidly in a minimum
viable product (MVP) or a proof of concept (PoC) environment with the use of Azure
Active Directory Domain Services (Azure AD DS). Use this idea to both extend on-
premises multi-forest AD DS identities to Azure without private connectivity and support
legacy authentication.
Potential use cases

This solution idea also applies to mergers and acquisitions, organization rebranding, and
multiple on-premises identities requirements.
Architecture
Azure Active Directory tenant: companyAB.onmicrosoft.com
Synchronization
Azure Active Directory DC Desktop virtualization Azure Virtual Desktop Azure Virtual Desktop Azure Virtual Desktop
administrators contributors (CompanyA) users (CompanyA) users (CompanyB) users (CompanyAB)
Authentication
Azure Active Role-Based Access Control
Directory
Active Directory Domain Services subnet Azure Virtual Desktop subnet Storage
VNet peering account
Azure Virtual Desktop host pool A
Azure AD
Connect Domain join
Synchronization Azure Virtual Azure Virtual Azure Virtual
Desktop host Desktop host Desktop host
Profiles
Azure AD DS Azure Virtual Desktop host pool B
Domain Controller
Domain Domain join Profiles
Controller Azure Files
Azure Virtual Azure Virtual Azure Virtual
CompanyA.local
Profiles
Azure AD DS
Domain Controller Azure Virtual Desktop host pool AB
Domain join
aadds.newcompanyAB.com
Azure Virtual Azure Virtual Azure Virtual
AD Domain
Services
Domain
Controller
CompanyB.local
Shared-Services-VNet AVD-SPOKE-VNET
Microsoft
On-premises network Shared services subscription Azure Virtual Desktop subscription

Azure
Dataflow
The following steps show how the data flows in this architecture in the form of identity.
1. Complex hybrid on-premises Active Directory environments are present, with two
or more Active Directory forests. Domains live in separate forests, with distinct User
Principal Name (UPN) suffixes. For example, CompanyA.local with UPN suffix
CompanyA.com, CompanyB.local with UPN suffix CompanyB.com, and an additional
UPN suffix, newcompanyAB.com.
2. Instead of using customer-managed domain controllers, either on-premises or on
Azure (that is, Azure infrastructure as a service [IaaS] domain controllers), the
environment uses the two cloud-managed domain controllers provided by Azure
AD DS.
3. Azure Active Directory (Azure AD) Connect syncs users from both CompanyA.com
and CompanyB.com to the Azure AD tenant, newcompanyAB.onmicrosoft.com. The
user account is represented only once in Azure AD, and private connectivity isn't
used.
4. Users then sync from Azure AD to the managed Azure AD DS as a one-way sync.
5. A custom and routable Azure AD DS domain name, aadds.newcompanyAB.com, is
created. The newcompanyAB.com domain is a registered domain that supports
LDAP certificates. We generally recommend that you not use non-routable domain
names, such as contoso.local, because it can cause issues with DNS resolution.
6. The Azure Virtual Desktop session hosts join the Azure AD DS domain controllers.
7. Host pools and app groups can be created in a separate subscription and spoke
virtual network.
8. Users are assigned to the app groups.
9. Users sign in by using either the Azure Virtual Desktop application or the web
client, with a UPN in a format such as john@companyA.com,
jane@companyB.com, or joe@newcompanyAB.com, depending on their
configured UPN suffix.
10. Users are presented with their respective virtual desktops or apps. For example,
john@companyA.com is presented with virtual desktops or apps in host pool A,
jane@companyB is presented with virtual desktops or apps in host pool B, and
joe@newcompanyAB is presented with virtual desktops or apps in host pool AB.
11. The storage account (Azure Files is used for FSLogix) is joined to the managed
domain AD DS. The FSLogix user profiles are created in Azure Files shares.
７ Note
For Group Policy requirements in Azure AD DS, you can install Group Policy
Management tools on a Windows Server virtual machine that's joined to
Azure AD DS.
To extend Group Policy infrastructure for Azure Virtual Desktop from the on-
premises domain controllers, you need to manually export and import it to
Azure AD DS.
Components
You implement this architecture by using the following technologies:

Azure Active Directory Domain Services
Azure Files
Azure Virtual Network
Contributors
contributors.
Principal author:
Tom Maher | Senior Security and Identity Engineer
Next steps
Multiple Active Directory forests architecture with Azure Virtual Desktop
Azure Virtual Desktop for enterprises
Azure AD Connect topologies
Compare different identity options
Related resources
Hybrid architecture design
Multiple forests with AD DS and Azure AD
Azure Virtual Desktop disaster recovery
concepts
Azure Virtual Desktop has grown tremendously as a remote and hybrid work solution in
recent years. Because so many users now work remotely, organizations require solutions
with high deployment speed and reduced costs. Users also need to have a remote work
environment with guaranteed availability and resiliency that lets them access their
virtual machines even during disasters. This document describes disaster recovery plans
that we recommend for keeping your organization up and running.
To prevent system outages or downtime, every system and component in your Azure
Virtual Desktop deployment must be fault-tolerant. Fault tolerance is when you have a
duplicate configuration or system in another Azure region that takes over for the main
configuration during an outage. This secondary configuration or system reduces the
impact of a localized outage. There are many ways you can set up fault tolerance, but
this article will focus on the methods currently available in Azure.
Azure Virtual Desktop infrastructure

In order to figure out which areas to make fault-tolerant, we first need to know who's
responsible for maintaining each area. You can divide responsibility in the Azure Virtual
Desktop service into two areas: Microsoft-managed and customer-managed. Metadata
like the host pools, app groups, and workspaces is controlled by Microsoft. The
metadata is always available and doesn't require extra setup by the customer to
replicate host pool data or configurations. We've designed the gateway infrastructure
that connects people to their session hosts to be a global, highly resilient service
managed by Microsoft. Meanwhile, customer-managed areas involve the virtual
machines (VMs) used in Azure Virtual Desktop and the settings and configurations
unique to the customer's deployment. The following table gives a clearer idea of which
areas are managed by which party.
Managed by Microsoft Managed by customer
Load balancer Network
Session broker Session hosts
Gateway Storage
Diagnostics User profile data

Managed by Microsoft Managed by customer
Cloud identity platform Identity
In this article, we're going to focus on customer-managed components, as these are

settings you can configure yourself.
Disaster recovery basics

In this section, we'll discuss actions and design principles that can protect your data and
prevent having huge data recovery efforts after small outages or full-blown disasters.
For smaller outages, following certain smaller steps can help prevent them from
becoming bigger disasters. Let's go over some basic terms that will help you when you
start setting up your disaster recovery plan.
When you design a disaster recovery plan, you should keep the following three things in
mind:
High availability: distributing infrastructure so smaller, more localized outages

don't interrupt your entire deployment. Designing with HA in mind can minimize
outage impact and avoid the need for a full disaster recovery.
Business continuity: how an organization can keep operating during outages of
any size.
Disaster recovery: the process of getting back to operation after a full outage.
Azure has many built-in, free-of-charge features that can deliver high availability at
many levels. The first feature is availability sets, which distribute VMs across different
fault and update domains within Azure. Next are availability zones, which are physically
isolated and geographically distributed groups of data centers that can reduce the
impact of an outage. Finally, distributing session hosts across multiple Azure regions
provides even more geographical distribution, which further reduces outage impact. All
three features provide a certain level of protection within Azure Virtual Desktop, and you
should carefully consider them along with any cost implications.
Basically, the disaster recovery strategy we recommend for Azure Virtual Desktop is to
deploy resources across multiple availability zones within a region. If you need more
protection, you can also deploy resources across multiple paired Azure regions.
Active-passive and active-active deployments

Something else you should keep in mind is the difference between active-passive and
active-active plans. Active-passive plans are when you have a region with one set of
resources that's active and one that's turned off until it's needed (passive). If the active
region is taken offline by an emergency, the organization can switch to the passive
region by turning it on and moving all their users there.
Another option is an active-active deployment, where you use both sets of infrastructure
at the same time. While some users may be affected by outages, the impact is limited to
the users in the region that went down. Users in the other region that's still online won't
be affected, and the recovery is limited to the users in the affected region reconnecting
to the functioning active region. Active-active deployments can take many forms,
including:
Overprovisioning infrastructure in each region to accommodate affected users in

the event one of the regions goes down. A potential drawback to this method is
that maintaining the additional resources costs more.
Have extra session hosts in both active regions, but deallocate them when they
aren't needed, which reduces costs.
Only provision new infrastructure during disaster recovery and allow affected users
to connect to the newly provisioned session hosts. This method requires regular
testing with infrastructure-as-code tools so you can deploy the new infrastructure
as quickly as possible during a disaster.
Recommended disaster recovery methods

The disaster recovery methods we recommend are:
Configure and deploy Azure resources across multiple availability zones.
Configure and deploy Azure resources across multiple regions in either active-
active or active-passive configurations. These configurations are typically found in
shared host pools.
For personal host pools with dedicated VMs, replicate VMs using Azure Site
Recovery to another region.
Configure a separate "disaster recovery" host pool in the secondary region. During
a disaster, you can switch users over to the secondary region.
We'll go into more detail about the two main methods you can achieve these methods
with for shared and personal host pools in the following sections.
Disaster recovery for shared host pools

In this section, we'll discuss shared (or "pooled") host pools using an active-passive
approach. The active-passive approach is when you divide up existing resources into a
primary and secondary region. Normally, your organization would do all its work in the
primary (or "active") region, but during a disaster, all it takes to switch over to the
secondary (or "passive") region is to turn off the resources in the primary region (if you
can do so, depending on the outage's extent) and turn on the ones in the secondary
one.
The following diagram shows an example of a deployment with redundant infrastructure

in a secondary region. "Redundant" means that a copy of the original infrastructure
exists in this other region, and is standard in deployments to provide resiliency for all
components. Beneath a single Azure Active Directory, there are two regions: West US
and East US. Each region has two session hosts running a multi-session operating
system (OS), A server running Azure AD Connect, an Active Directory Domain Controller,
an Azure Files Premium File share for FSLogix profiles, a storage account, and a virtual
network (VNET). In the primary region, West US, all resources are turned on. In the
secondary region, East US, the session hosts in the host pool are either turned off or in
drain mode, and the Azure AD Connect server is in staging mode. The two VNETs in
both regions are connected by peering.
In most cases, if a component fails or the primary region isn't available, then the only
action the customer needs to perform is to turn on the hosts or remove drain mode in
the secondary region to enable end-user connections. This scenario focuses on reducing
downtime. However, a redundancy-based disaster recovery plan may cost more due to
having to maintain those extra components in the secondary region.
The potential benefits of this plan are as follows:
Less time spent recovering from disasters. For example, you'll spend less time on
provisioning, configuring, integrating, and validating newly deployed resources.
There's no need to use complicated procedures.
It's easy to test failover outside of disasters.
The potential drawbacks are as follows:
May cost more due to having more infrastructure to maintain, such as storage
accounts, hosts, and so on.
You'll need to spend more time configuring your deployment to accommodate this
plan.
You need to maintain the extra infrastructure you set up even when you don't need
it.
Important information for shared host pool

recovery
When using this disaster recovery strategy, it's important to keep the following things in
mind:
Having multiple session hosts online across many regions can impact user
experience. The managed network load balancer doesn't account for geographic
proximity, instead treating all hosts in a host pool equally.
During a disaster, users will be creating new profiles in the secondary region. You
should store any business- or mission-critical data in OneDrive (using known folder
redirection) or Sharepoint. Storing data here will give users quick access to their
applications with minor disruption to the user experience.
Make sure that you configure your virtual machines (VMs) exactly the same way
within your host pool. Also, make sure all VMs within your host pool are the same
size. If your VMs aren't the same, the managed network load balancer will
distribute user connections evenly across all available VMs. The smaller VMs may
become resource-constrained earlier than expected compared to larger VMs,
resulting in a negative user experience.
Region availability affects data or workspace monitoring. If a region isn't available,
the service may lose all historical monitoring data during a disaster. We
recommend using a custom export or dump of historical monitoring data.
We recommend you update your session hosts at least once every month. This
recommendation applies to session hosts you keep turned off for extended
periods of time.
Test your deployment by running a controlled failover at least once every six
months. Part of the controlled failover could mean your secondary location
becomes primary until the next controlled failover. Changing your secondary
location to primary allows users to have nearly identical profiles during a real
disaster.
The following table lists deployment recommendations for host pool disaster recovery
strategies:
Technology Recommendations
Network Create and deploy a secondary virtual network in another region and configure
Azure Peering with your primary virtual network.
Session Create and deploy an Azure Virtual Desktop shared host pool with multi-session
hosts OS SKU and include VMs from other availability zones and another region.
Storage Create storage accounts in multiple regions using premium-tier accounts.
User profile Create SMB storage locations in multiple regions.

data
Identity Active Directory Domain Controllers from the same directory.
Disaster recovery for personal host pools

For personal host pools, your disaster recovery strategy should involve replicating your
resources to a secondary region using Azure Site Recovery Services Vault. If your primary
region goes down during a disaster, Azure Site Recovery can fail over and turn on the
resources in your secondary region.
For example, let's say we have a deployment with a primary region in the West US and a
secondary region in the East US. The primary region has a personal host pool with two
session hosts each. Each session host has their own local disk containing the user profile
data and their own VNET that's not paired with anything. If there's a disaster, you can
use Azure Site Recovery to fail over to the secondary region in East US (or to a different
availability zone in the same region). Unlike the primary region, the secondary region
doesn't have local machines or disks. During the failover, Azure Site Recovery takes the
replicated data from the Azure Site Recovery Vault and uses it to create two new VMs
that are copies of the original session hosts, including the local disk and user profile
data. The secondary region has its own independent VNET, so the VNET going offline in
the primary region won't affect functionality.
The following diagram shows the example deployment we just described.
The benefits of this plan include a lower overall cost and not requiring maintenance to
patch or update due to resources only being provisioned when you need them.
However, a potential drawback is that you'll spend more time provisioning, integrating,
and validating failover infrastructure than you would with a shared host pool disaster
recovery setup.
Important information about personal host

pool recovery
When using this disaster recovery strategy, it's important to keep the following things in
mind:
There may be requirements that the host pool VMs need to function in the
secondary site, such as virtual networks, subnets, network security, or VPNs to
access a directory such as on-premises Active Directory.
７ Note
Using an Azure Active Directory-joined VM fulfills some of these

requirements automatically.
You may experience integration, performance, or contention issues for resources if
a large-scale disaster affects multiple customers or tenants.
Personal host pools use VMs that are dedicated to one user, which means affinity
load load-balancing rules direct all user sessions back to a specific VM. This one-
to-one mapping between user and VM means that if a VM is down, the user won't
be able to sign in until the VM comes back online or the VM is recovered after
disaster recovery is finished.
VMs in a personal host pool store user profile on drive C, which means FSLogix
isn't required.
Region availability affects data or workspace monitoring. If a region isn't available,

the service may lose all historical monitoring data during a disaster. We
recommend using a custom export or dump of historical monitoring data.
We recommend you avoid using FSLogix when using a personal host pool
configuration.
Virtual machine provisioning isn't guaranteed in the failover region.
Run controlled failover and failback tests at least once every six months.
The following table lists deployment recommendations for host pool disaster recovery
strategies:
Technology Recommendations
Network Create and deploy a secondary virtual network in another region to follow custom
naming conventions or security requirements outside of the Azure Site Recovery
default naming scheme.
Session Enable and configure Azure Site Recovery for VMs. Optionally, you can pre-stage
hosts an image manually or use the Azure Image Builder service for ongoing
provisioning.
Storage Creating an Azure Storage account is optional to store profiles.
User profile User profile data is locally stored on drive C.

data
Identity Active Directory Domain Controllers from the same directory across multiple
regions.
Next steps
For more in-depth information about disaster recovery in Azure, check out these articles:
Cloud Adoption Framework Azure Virtual Desktop business continuity and disaster
recovery documentation
Azure Virtual Desktop Handbook: Disaster Recovery

Manage session hosts with Microsoft
Intune
We recommend using Microsoft Intune to manage your Azure Virtual Desktop

environment. Microsoft Intune is a unified management platform that includes Microsoft
Configuration Manager and Microsoft Intune.
Microsoft Configuration Manager

Microsoft Configuration Manager versions 1906 and later can manage your domain-
joined and Hybrid Azure Active Directory (Azure AD)-joined session hosts. For more
information, see Supported OS versions for clients and devices for Configuration
Manager.
Microsoft Intune
Microsoft Intune can manage your Azure AD-joined and Hybrid Azure AD-joined session
hosts. To learn more about using Intune to manage Windows 11 and Windows 10 single
session hosts, see Using Azure Virtual Desktop with Intune.
For Windows 11 and Windows 10 multi-session hosts, Intune supports both device-
based configurations on Windows 11 and Windows 10 and user-scope configurations
on Windows 11. User-scope configurations for Windows 10 are currently in preview. To
learn more about using Intune to manage multi-session hosts, see Using Azure Virtual
Desktop multi-session with Intune.
７ Note
Managing Azure Virtual Desktop session hosts using Intune is currently supported
in the Azure Public and Azure Government clouds.
Licensing
Microsoft Intune licenses are included with most Microsoft 365 subscriptions.
Learn more about licensing requirements at the following resources:

Frequently asked questions for Configuration Manager branches and licensing
Microsoft Intune licensing
 Documentation

Create an application group, a workspace, and assign users - Azure Virtual Desktop
Learn how to create an application group and a workspace, and assign users in Azure Virtual Desktop
by using the Azure portal, Azure CLI, or Azure PowerShell.

Create Azure NetApp files Azure Virtual Desktop - Azure

This article describes how to create Azure NetApp Files in Azure Virtual Desktop.



to production.
Show 5 more
 Training
Module
Set up Microsoft Intune - Training
After completing this module, you will have set up Microsoft Intune. Set up includes reviewing the
supported configurations, signing up for Intune, adding users and groups, assigning licenses to
users, and confirming the MDM authority.
Certification
Autoscale scaling plans and example
scenarios in Azure Virtual Desktop
Autoscale lets you scale your session host virtual machines (VMs) in a host pool up or
down to optimize deployment costs. You create a scaling plan that can be based on:
Time of day
Specific days of the week
Session limits per session host
７ Note
Azure Virtual Desktop (classic) doesn't support autoscale.

Autoscale isn't supported on Azure Virtual Desktop for Azure Stack HCI.
Autoscale doesn't support scaling of ephemeral disks.
Autoscale doesn't support scaling of generalized or sysprepped VMs with
machine-specific information removed. For more information, see Remove
machine-specific information by generalizing a VM before creating an
image.
You can't use autoscale and scale session hosts using Azure Automation on
the same host pool. You must use one or the other.
Autoscale is available in Azure and Azure Government in the same regions
you can create host pools in.
For best results, we recommend using autoscale with VMs you deployed with Azure
Virtual Desktop Azure Resource Manager (ARM) templates or first-party tools from
Microsoft.
How a scaling plan works

Before you create your plan, keep the following things in mind:
You can assign one scaling plan to one or more host pools of the same host pool
type. The scaling plan's schedule will also be applied across all assigned host pools.
You can only associate one scaling plan per host pool. If you assign a single scaling
plan to multiple host pools, those host pools can't be assigned to another scaling
plan.
A scaling plan can only operate in its configured time zone.
A scaling plan can have one or multiple schedules. For example, different
schedules during weekdays versus the weekend.
Make sure you understand usage patterns before defining your schedule. You'll
need to schedule around the following times of day:
Ramp-up: the start of the day, when usage picks up.
Peak hours: the time of day when usage is expected to be at its highest.
Ramp-down: when usage tapers off. This is usually when you shut down your
VMs to save costs.
Off-peak hours: the time of the day when usage is expected to be at its lowest.
The scaling plan will take effect as soon as you enable it.
Also, keep these limitations in mind:
Don’t use autoscale in combination with other scaling Microsoft or third-party

scaling tools. Ensure that you disable those for the host pools you apply the
scaling plans to.
Autoscale overwrites drain mode, so make sure to use exclusion tags when
updating VMs in host pools.
Autoscale ignores existing load-balancing algorithms in your host pool settings,

and instead applies load balancing based on your schedule configuration.
Example scenarios
In this section, there are four scenarios that show how different parts of autoscale works.
In each example, there are tables that show the host pool's settings and animated visual
demonstrations.
７ Note
To learn more about what the parameter terms mean, see our autoscale glossary.
Scenario 1: When does autoscale turn virtual machines

on?
In this scenario, we'll demonstrate that autoscale can turn on session host virtual
machines (VMs) in any phase of the scaling plan schedule when the used host pool
capacity exceeds the capacity threshold.
For example, let's look at the following host pool setup as described in this table:
Parameter Value
Phase Ramp-up
Total session hosts 6
Load balancing algorithm Breadth-first
Capacity threshold 30%
Minimum percentage of hosts 30%
Available session hosts 2
Maximum session limit 5
Available host pool capacity 10
User sessions 0
Used host pool capacity 0%
At the beginning of this phase, autoscale has turned on two session hosts to match the
minimum percentage of hosts. Although 30% of six isn't a whole number, autoscale
rounds up to the nearest whole number. Having two available session hosts and a
maximum session limit of five sessions per host means that this host pool has an
available host pool capacity of 10. Since there aren't currently any user sessions, the
used host pool capacity is 0%.
When the day begins, let's say three users sign in and start user sessions. Their user
sessions get evenly distributed across the two available session hosts since the load
balancing algorithm is breadth first. The available host pool capacity is still 10, but with
the three new user sessions, the used host pool capacity is now 30%. However,
autoscale won't turn on virtual machines (VMs) until the used host pool capacity is
greater than the capacity threshold. In this example, the capacity threshold is 30%, so
autoscale won't turn on any VMs yet.
At this point, the host pool's parameters look like this:
Parameter Value
Parameter Value
Phase Ramp-up
User sessions 3
When another user signs in and starts a session, there are now four total users sessions
distributed across two session hosts. The used host pool capacity is now 40%, which is
greater than the capacity threshold. As a result, autoscale will turn on another session
host to bring the used host pool capacity to less than or equal to the capacity threshold
(30%).
In summary, here are the parameters when the used host pool capacity exceeds the
capacity threshold:
Parameter Value
Phase Ramp-up
User sessions 4
Parameter Value
Here are the parameters after autoscale turns on another session host:
Parameter Value
Phase Ramp-up
User sessions 4
Turning on another session host means there are now three available session hosts in
the host pool. With the maximum session limit still being five, the available host pool
capacity has gone up to 15. Because the available host pool capacity increased, the used
host pool capacity has gone down to 27%, which is below the 30% capacity threshold.
When another user signs in, there are now five user sessions spread across three
available session hosts. The used host pool capacity is now 33%, which is over the 30%
capacity threshold. Exceeding the capacity threshold activates autoscale to turn on
another session host.
Since our example is in the ramp-up phase, new users are likely to keep signing in. As
more users arrive, the pattern becomes clearer:
Total Number of Available Capacity Used host Does autoscale turn

user available host pool threshold pool on another session
sessions session hosts capacity capacity host?
5 3 15 30% 33% Yes
5 4 20 30% 25% No
Total Number of Available Capacity Used host Does autoscale turn
user available host pool threshold pool on another session
sessions session hosts capacity capacity host?
6 4 20 30% 30% No
7 4 20 30% 35% Yes
7 5 25 30% 28% No
As this table shows, autoscale only turns on new session hosts when the used host pool
capacity goes over the capacity threshold. If the used host pool capacity is at or below
the capacity threshold, autoscale won't turn on new session hosts.
The following animation is a visual recap of what we just went over in Scenario 1.
Scenario 2: When does autoscale turn virtual machines

off?
In this scenario, we'll show that autoscale turns off session hosts when all of the
following things are true:
The used host pool capacity is below the capacity threshold.

Autoscale can turn off session hosts without exceeding the capacity threshold.
Autoscale only turns off session hosts with no user sessions on them (unless the
scaling plan is in ramp-down phase and you've enabled the force logoff setting).
For this scenario, the host pool starts off looking like this:
Parameter Value
Phase Peak
User sessions 7
Because we're in the peak phase, we can expect the number of users to remain relatively
stable. However, to keep the amount of resources used stable while also remaining
efficient, autoscale will turn session hosts on and off as needed.
So, let's say that there are seven users signed in during peak hours. If the total number
of user sessions is seven, that would make the used host pool capacity 28%. Because
autoscale can't turn off a session host without the used host pool capacity exceeding
the capacity threshold, autoscale won't turn off any session hosts yet.
If two of the seven users sign out during their lunch break, that leaves five user sessions
across five session hosts. Since the maximum session limit is still five, the available host
pool capacity is 25. Having only five users means that the used host pool capacity is now
20%. autoscale must now check if it can turn off a session host without making the used
host pool capacity go above the capacity threshold.
If autoscale turned off a session host, the available host pool capacity would be 20. With
five users, the used host pool capacity would then be 25%. Because 25% is less than the
capacity threshold of 30%, autoscale will select a session host without user sessions on
it, put it in drain mode, and turn it off.
Once autoscale turns off one of the session hosts without user sessions, there are four
available session hosts left. The host pool maximum session limit is still five, so the
available host pool capacity is 20. Since there are five user sessions, the used host pool
capacity is 25%, which is still below the capacity threshold.
However, if another user signs out and heads out for lunch, there are now four user
sessions spread across the four session hosts in the host pool. Since the maximum
session limit is still five, the available host pool capacity is 20, and the used host pool
capacity is 20%. Turning off another session host would leave three session hosts and an
available host pool capacity of 15, which would cause the used host pool capacity to
jump up to around 27%. Even though 27% is below the capacity threshold, there are no
session hosts with zero user sessions on it. Autoscale will select the session host with the
least number of user sessions, put it in drain mode, and wait for all user sessions to sign
out before turning it off. If at any point the used host pool capacity gets to a point
where autoscale can no longer turn off the session host, it will take the session host out
of drain mode.
Scenario 3: When does autoscale force users to sign out?

Autoscale only forces users to sign out if you've enabled the force logoff setting during
the ramp-down phase of your scaling plan schedule. The force logoff setting won't sign
out users during any other phase of the scaling plan schedule.
For example, let's look at a host pool with the following parameters:
Parameter Value
Phase Ramp-down

Parameter Value
Load balancing algorithm Depth-first
User sessions 4
During the ramp-down phase, the host pool admin has set the capacity threshold to
75% and the minimum percentage of hosts to 10%. Having a high capacity threshold
and a low minimum percentage of hosts in this phase decreases the need to turn on
new session hosts at the end of the workday.
For this scenario, let's say that there are currently four users on the four available session
hosts in this host pool. Since the available host pool capacity is 20, that means the used
host pool capacity is 20%. Based on this information, autoscale detects that it can turn
off two session hosts without going over the capacity threshold of 75%. However, since
there are user sessions on all the session hosts in the host pool, in order to turn off two
session hosts, autoscale will need to force users to sign out.
When you've enabled the force logoff setting, autoscale will select the session hosts
with the fewest user sessions, then put the session hosts in drain mode. Autoscale then
sends users in the selected session hosts notifications that they're going to be forcibly
signed out of their sessions after a certain time. Once that time has passed, if the users
haven't already ended their sessions, autoscale will forcibly end their sessions for them.
In this scenario, since there are equal numbers of user sessions on each of the session
hosts in the host pool, autoscale will choose two session hosts at random to forcibly
sign out all their users and will then turn off the session hosts.
Once autoscale turns off the two session hosts, the available host pool capacity is now
10. Now that there are only two user sessions left, the used host pool capacity is 20%, as
shown in the following table.
Parameter Value
Phase Ramp-down
Parameter Value
User sessions 2
Now, let's say that the two users who were forced to sign out want to continue doing
work and sign back in. Since the available host pool capacity is still 10, the used host
pool capacity is now 40%, which is below the capacity threshold of 75%. However,
autoscale can't turn off more session hosts, because that would leave only one available
session host and an available host pool capacity of five. With four users, that would
make the used host pool capacity 80%, which is above the capacity threshold.
So now the parameters look like this:
Parameter Value
Phase Ramp-down
User sessions 4

If at this point another user signs out, that leaves only three user sessions distributed
across the two available session hosts. In other words, the host pool now looks like this:
Parameter Value
Phase Ramp-down
User sessions 3
Because the maximum session limit is still five and the available host pool capacity is 10,
the used host pool capacity is now 30%. Autoscale can now turn off one session host
without exceeding the capacity threshold. Autoscale turns off a session host by choosing
the session host with the fewest number of user sessions on it. Autoscale then puts the
session host in drain mode, sends users a notification that says the session host will be
turned off, then after a set amount of time, forcibly signs any remaining users out and
turns it off. After doing so, there's now one remaining available session host in the host
pool with a maximum session limit of five, making the available host pool capacity five.
Since autoscale forced a user to sign out when turning off the chosen session host, there
are now only two user sessions left, which makes the used host pool capacity 40%.
To recap, here's what the host pool looks like now:
Parameter Value
Phase Ramp-down

Parameter Value
User sessions 2
After that, let's imagine that the user who was forced to sign out signs back in, making
the host pool look like this:
Parameter Value
Phase Ramp-down
User sessions 3
Now there are three user sessions in the host pool. However, the host pool capacity is
still five, which means the used host pool capacity is 60% and below the capacity
threshold. Because turning off the remaining session host would make the available host
pool capacity zero, which is below the 10% minimum percentage of hosts, autoscale will
ensure that there's always at least one available session host during the ramp-down
phase.
Scenario 4: How do exclusion tags work?
When a virtual machine has a tag name that matches the scaling plan exclusion tag,
autoscale won't turn it on, off, or change its drain mode setting. Exclusion tags are
applicable in all phases of your scaling plan schedule.
Here's the example host pool we're starting with:
Parameter Value
Phase Off-peak
User sessions 3

In this example scenario, the host pool admin applies the scaling plan exclusion tag to
five out of the six session hosts. When a new user signs in, that brings the total number
of user sessions up to four. There's only one available session host and the host pool's
maximum session limit is still five, so the available host pool capacity is five. The used
host pool capacity is 80%. However, even though the used host pool capacity is greater
than the capacity threshold, autoscale won't turn on any other session hosts because all
of the session hosts except for the one currently running have been tagged with the
exclusion tag.
So, now the host pool looks like this:
Parameter Value
Phase Off-peak
User sessions 4
Next, let's say all four users have signed out, leaving no user sessions left on the
available session host. Because there are no user sessions in the host pool, the used host
pool capacity is 0. Autoscale will keep this single session host on despite it having no
users, because during the off-peak phase, autoscale's minimum percentage of hosts
setting dictates that it needs to keep at least one session host available during this
phase.
To summarize, the host pool now looks like this:
Parameter Value
Phase Off-peak

Parameter Value
User sessions 0
If the admin applies the exclusion tag name to the last untagged session host virtual
machine and turns it off, then that means even if other users try to sign in, autoscale
won't be able to turn on a VM to accommodate their user session. That user will see a
"No resources available" error.
However, being unable to turn VMs back on means that the host pool won't be able to
meet its minimum percentage of hosts. To fix any potential problems that causes, the
admin removes the exclusion tags from two of the VMs. Autoscale only turns on one of
the VMs, because it only needs one VM to meet the 10% minimum requirement.
So, finally, the host pool will look like this:
Parameter Value
Phase Off-peak
User sessions 0
Parameter Value
Next steps
To learn how to create scaling plans for autoscale, see Create autoscale scaling for
Azure Virtual Desktop host pools.
To review terms associated with autoscale, see the autoscale glossary.
For answers to commonly asked questions about autoscale, see the autoscale FAQ.
 Documentation






Show 5 more
 Training

Training
Autoscale glossary for Azure Virtual
Desktop
This article is a list of definitions for key terms and concepts related to the autoscale
feature for Azure Virtual Desktop.
Autoscale
Autoscale is Azure Virtual Desktop’s native scaling service that turns VMs on and off
based on the number of sessions on the session hosts in the host pool and which phase
of the scaling plan schedule the workday is in.
Scaling tool
Azure Virtual Desktop’s scaling tool uses Azure Automation and Azure Logic Apps to
scale the VMs in a host pool based on how many user sessions per CPU core there are
during peak and off-peak hours.
Scaling plan
A scaling plan is an Azure Virtual Desktop Azure Resource Manager object that defines
the schedules for scaling session hosts in a host pool. You can assign one scaling plan to
multiple host pools. Each host pool can only have one scaling plan assigned to it.
Schedule
Schedules are sub-resources of scaling plans that specify the start time, capacity
threshold, minimum percentage of hosts, load-balancing algorithm, and other
configuration settings for the different phases of the day.
Ramp-up
The ramp-up phase of a scaling plan schedule is usually at the beginning of the work
day, when users start to sign in and start their sessions. In this phase, the number of
active user sessions usually increases at a rapid pace without reaching the maximum
number of active sessions for the day yet.
Peak
The peak phase of a scaling plan schedule is when your host pool reaches the maximum
number of active user sessions for the day. In this phase, the number of active sessions
usually holds steady until the peak phase ends. New active user sessions can be
established during this phase, but usually at a slower rate than the ramp-up phase.
Ramp-down
The ramp-down phase of a scaling plan schedule is usually at the end of the work day,
when users start to sign out and end their sessions for the evening. In this phase, the
number of active user sessions usually decreases rapidly.
Off-peak
The off-peak phase of the scaling plan schedule is when the host pool usually reaches
the minimum number of active user sessions for the day. During this phase, there aren't
usually many active users, but you can keep a small amount of resources on to
accommodate users who work after the peak and ramp-down phases.
Available session host

Available session hosts are session hosts that have passed all Azure Virtual Desktop
agent health checks and have VM objects that are powered on, making them available
for users to start their user sessions on.
Capacity threshold
The capacity threshold is the percentage of a host pool's capacity that, when reached,
triggers a scaling action to happen.
For example:
If the used host pool capacity is below the capacity threshold and autoscale can
turn off virtual machines (VMs) without going over the capacity threshold, then the
feature will turn off the VMs.
If the used host pool capacity goes over the capacity threshold, then autoscale will
turn on more VMs until the used host pool capacity goes below the capacity
threshold.
Available host pool capacity
Available host pool capacity is how many user sessions a host pool can host based on
the number of available session hosts. The available host pool capacity is the host pool's
maximum session limit multiplied by the number of available session hosts in the host
pool.
In other words:
Host pool maximum session limit × number of available session hosts = available host
pool capacity.
Used host pool capacity

The used host pool capacity is the amount of host pool capacity that's currently taken
up by active and disconnected user sessions.
In other words:
The number of active and disconnected user sessions ÷ the host pool capacity = used
host pool capacity.
Scaling action
Scaling actions are when autoscale turns VMs on or off.
Minimum percentage of hosts

The minimum percentage of hosts is the lowest percentage of all session hosts in the
host pool that must be turned on for each phase of the scaling plan schedule.
Active user session

A user session is considered "active" when the user signs in and connects to their
remote app or desktop resource.
Disconnected user session

A disconnected user session is an inactive session that the user hasn't signed out of yet.
When a user closes the remote session window without signing out, the session
becomes disconnected. When a user reconnects to their remote resources, they'll be
redirected to their disconnected session on the session host they were working on. At
this point, the disconnected session becomes an active session again.
Force log-off
A force log-off, or forced sign-out, is when the service ends an active user session or a
disconnected user session without the user's consent.
Exclusion tag
An exclusion tag is a property of a scaling plan that's a tag name you can apply to VMs
that you want to exclude from scaling actions. Autoscale only performs scaling actions
on VMs without tag names that match the exclusion tag.
Next steps
For more information about autoscale, see the autoscale feature document.
For examples of how autoscale works, see Autoscale example scenarios.
For more information about the scaling script, see the scaling script document.
Azure Virtual Desktop autoscale
FAQ
FAQ
This article answers frequently asked questions about how to use autoscale for Azure
Virtual Desktop.
How do I configure autoscale so I run

zero session hosts after working hours?
Ramp-down mode always uses the lowest possible number of session hosts. However, if
there are existing user sessions, the lowest number of usable session hosts won't be
zero. To configure the time limit policy to sign out all disconnected users to avoid
having usable session hosts after hours, go to Local Computer Policy > Computer
Configuration > Administrative Templates > Windows Components > Remote
Desktop Services > Remote Desktop Session Host > Session Time Limits > Set time
limit for disconnected sessions.
Does autoscale create or delete virtual

machines (VMs) based on service load?
No.
Does autoscale change the SKU or size

of VMs?
No.
Can I configure scaling for specific dates

like holidays?
No. Autoscale doesn’t currently support ramping down on specific dates.
Will I be charged extra for using
autoscale?
No. For more information on rates, see our pricing page .
What happens if the host pool capacity

is equal to the capacity threshold?
Nothing. Autoscale only reacts when the host pool capacity is greater than or less than
the capacity threshold. The feature won't do anything when the host pool capacity is the
same as the capacity threshold.
If I set drain mode on session hosts, will

autoscale change my configured
setting?
Yes, autoscale still turns VMs in drain mode on or off, no matter who put it in drain
mode. Autoscale overrides drain mode on all VMs included in scaling, so if you want to
exclude a VM from scaling actions, you must use exclusion tags.
How often does autoscale monitor the

session hosts and perform scaling
evaluations?
Autoscale monitors for when users sign in or out of their session hosts and categorizes
this activity as session change events. Session change events trigger a scaling evaluation
that creates logs. If there aren't any session change events or the event service has an
outage, autoscale then checks to see if it missed any events. When several session
change events happen within a short time period, the feature batches the scaling
evaluations. This batching allows autoscale to process large numbers of events quickly
without overloading the system.
Can force sign-out happen in any phase

of the day?
No. If you've enabled autoscale, you can only force users to sign out during the ramp-
down phase. If you put a session host in drain mode during ramp-down to prepare it to
be shut down but not all users sign out before the phase changes to off-peak, the
remaining user sessions won't be forced to sign out from their session. The reason users
aren't signed out is because autoscale doesn't force users to sign out of their sessions
during off-peak hours. Instead, autoscale waits until all users have signed out before
deallocating the VM. For example, if the ramp-down phase is 15 minutes long, and the
wait time before signing out users and shutting down VMs is 20 minutes long, the
schedule shifts to the off-peak phase and the user sessions won't be forced to sign out.
If I configure autoscale to force users to

sign out during ramp-down, will it also
sign out users with active sessions?
Yes. Idle, disconnected, and active sessions are forced to sign out if the users don't sign
out during the ramp-down phase wait time.
If an active session is forced to sign out,

but the user tries to reconnect, is there
a way to prevent them from starting a
new session on a session host that
autoscale is about to turn off?
After autoscale selects a session host to be shut down, it puts the session host in drain
mode. Once all the user sessions have been signed out, autoscale deallocates the VM.
After deallocating the VM, autoscale sets the AllowNewSessions setting to true, which
turns off drain mode. Because sessions hosts that are about to be shut down are put in
drain mode, a user who is forced to sign out of their session won't connect to a session
host that is about to be shut down if they try to reconnect.
Can autoscale turn off all the VMs in a

host pool, or does it need to keep at
least a few VMs on to work properly?
Autoscale can turn off all VMs in a host pool if the minimum percentage of hosts is set
to 0% and there are no user sessions on the session hosts in the host pool.
How many VMs need to be in a host

pool for autoscale to work properly?
At least one.
Why would I want to configure the load

balancing algorithm differently during
different phases of the scaling plan
schedule?
When you set up your scaling plan schedule, you can specify different load balancing
algorithms for different phases of the day. For example, during the ramp-up and peak
phases, you can use the breadth-first load balancing algorithm. This algorithm ensures
you have an even distribution of user sessions during the first two phases of the day,
which optimizes performance. Likewise, during the ramp-down and off-peak phases,
you can use the depth-first load balancing algorithm to help the autsocale feature
consolidate user sessions until it reaches the minimal possible number of session hosts
in the host pool.
Can you use Azure CLI to configure

autoscale?
No, currently autoscale doesn't offer the option to configure settings with Azure CLI.
Does autoscale handle scaling session

hosts in secondary regions if the session
hosts in the primary region have an
outage?
No. Customers need to set up their own disaster recovery strategy to manage outages.
Autoscale only handles scaling existing VMs within the region they're created in.
Does autoscale consider availability
zones during scaling operations if
session hosts are created in multiple
zones within a region?
No. Autoscale does not know what availability zone a VM was created in and so may not
perform scaling operations across all zones equally.
Can autoscale turn off all VMs in a host

pool and still work properly?
Autoscale can turn off all VMs in a host pool if the minimum percentage of hosts is set
to 0% and there are no active user sessions in the host pool. However, if the last session
host that’s been turned on in the host pool still has active user sessions on it, those
users won’t be forced to sign out. The final VM won’t turn off until after those users sign
out.
Scale session hosts using Azure
Automation and Azure Logic Apps for
You can reduce your total Azure Virtual Desktop deployment cost by scaling your virtual
machines (VMs). This means shutting down and deallocating session host VMs during
off-peak usage hours, then turning them back on and reallocating them during peak
hours.
In this article, you'll learn about the scaling tool built with the Azure Automation account
and Azure Logic Apps that automatically scales session host VMs in your Azure Virtual
Desktop environment. To learn how to use the scaling tool, see Set up scaling of session
hosts using Azure Automation and Azure Logic Apps.
How the scaling tool works

The scaling tool provides a low-cost automation option for customers who want to
optimize their session host VM costs.
You can use the scaling tool to:
Schedule VMs to start and stop based on peak and off-peak business hours.
Scale out VMs based on number of sessions per CPU core.
Scale in VMs during off-peak hours, leaving the minimum number of session host
VMs running.
The scaling tool uses a combination of an Azure Automation account, a PowerShell

runbook, a webhook, and a Logic App to function. When the tool runs, the Logic App
calls a webhook to start the runbook. The runbook then creates a job.
Peak and off-peak hours are defined as:
Peak: The time when maximum user session concurrency is expected to be

reached.
Off-peak: The time when minimum user session concurrency is expected to be
reached.
During peak usage time, the job checks the current number of sessions and the VM
capacity of the current running session host for each host pool. It uses this information
to calculate if the running session host VMs can support existing sessions based on the
SessionThresholdPerCPU parameter defined for the CreateOrUpdateAzLogicApp.ps1 file.
If the session host VMs can't support existing sessions, the job starts extra session host
VMs in the host pool.
７ Note
SessionThresholdPerCPU doesn't restrict the number of sessions on the VM. This

parameter only determines when new VMs need to be started to load-balance the
connections. To restrict the number of sessions, you need to follow the instructions
Update-AzWvdHostPool to configure the MaxSessionLimit parameter accordingly.
During the off-peak usage time, the job determines how many session host VMs should
be shut down based on the MinimumNumberOfRDSH parameter. If you set the
LimitSecondsToForceLogOffUser parameter to a non-zero positive value, the job will set
the session host VMs to drain mode to prevent new sessions from connecting to the
hosts. The job will then notify any currently signed in users to save their work, wait the
configured amount of time, and then force the users to sign out. Once all user sessions
on the session host VM have been signed out, the job will shut down the VM. After the
VM shuts down, the job will reset its session host drain mode.
７ Note
If you manually set the session host VM to drain mode, the job won't manage the
session host VM. If the session host VM is running and set to drain mode, it will be
treated as unavailable, which will make the job start additional VMs to handle the
load. We recommend you tag any Azure VMs before you manually set them to
drain mode. You can name the tag with the MaintenanceTagName parameter when
you create Azure Logic App Scheduler later. Tags will help you distinguish these
VMs from the ones the scaling tool manages. Setting the maintenance tag also
prevents the scaling tool from making changes to the VM until you remove the tag.
If you set the LimitSecondsToForceLogOffUser parameter to zero, the job allows the
session configuration setting in specified group policies to handle signing off user
sessions. To see these group policies, go to Computer Configuration > Policies >
Administrative Templates > Windows Components > Remote Desktop Services >
Remote Desktop Session Host > Session Time Limits. If there are any active sessions on
a session host VM, the job will leave the session host VM running. If there aren't any
active sessions, the job will shut down the session host VM.
At any time, the job also takes host pool's MaxSessionLimit into account to determine if
the current number of sessions is more than 90% of the maximum capacity. If it is, the
job will start extra session host VMs.
The job runs periodically based on a set recurrence interval. You can change this interval
based on the size of your Azure Virtual Desktop environment, but remember that
starting and shutting down VMs can take some time, so remember to account for the
delay. We recommend setting the recurrence interval to every 15 minutes.
However, the tool also has the following limitations:
This solution applies only to pooled multi-session session host VMs.

This solution manages VMs in any region, but can only be used in the same
subscription as your Azure Automation account and Azure Logic App.
The maximum runtime of a job in the runbook is 3 hours. If starting or stopping
the VMs in the host pool takes longer than that, the job will fail. For more
information, see Shared resources.
At least one VM or session host needs to be turned on for the scaling algorithm to
work properly.
The scaling tool doesn't support scaling based on CPU or memory.
Scaling only works with existing hosts in the host pool. The scaling tool doesn't
support scaling new session hosts.
７ Note
The scaling tool controls the load balancing mode of the host pool it's currently
scaling. The tool uses breadth-first load balancing mode for both peak and off-
peak hours.
Next steps
Learn how to set up scaling of session hosts using Azure Automation and Azure
Logic Apps.
Security best practices
Azure Virtual Desktop is a managed virtual desktop service that includes many security
capabilities for keeping your organization safe. In an Azure Virtual Desktop deployment,
Microsoft manages portions of the services on the customer’s behalf. The service has
many built-in advanced security features, such as Reverse Connect, which reduce the risk
involved with having remote desktops accessible from anywhere.
This article describes steps you can take as an admin to keep your customers' Azure
Virtual Desktop deployments secure.
Security responsibilities
What makes cloud services different from traditional on-premises virtual desktop
infrastructures (VDIs) is how they handle security responsibilities. For example, in a
traditional on-premises VDI, the customer would be responsible for all aspects of
security. However, in most cloud services, these responsibilities are shared between the
customer and the company.
When you use Azure Virtual Desktop, it’s important to understand that while some
components come already secured for your environment, you'll need to configure other
areas yourself to fit your organization’s security needs.
Here are the security needs you're responsible for in your Azure Virtual Desktop
deployment:
Security need Is the customer responsible for this?
Identity Yes
User devices (mobile and PC) Yes
App security Yes
Session host operating system (OS) Yes
Deployment configuration Yes
Network controls Yes
Virtualization control plane No
Physical hosts No
Security need Is the customer responsible for this?
Physical network No
Physical datacenter No
The security needs the customer isn't responsible for are handled by Microsoft.
Azure security best practices

Azure Virtual Desktop is a service under Azure. To maximize the safety of your Azure
Virtual Desktop deployment, you should make sure to secure the surrounding Azure
infrastructure and management plane as well. To secure your infrastructure, consider
how Azure Virtual Desktop fits into your larger Azure ecosystem. To learn more about
the Azure ecosystem, see Azure security best practices and patterns.
This section describes best practices for securing your Azure ecosystem.
Enable Microsoft Defender for Cloud

We recommend enabling Microsoft Defender for Cloud's enhanced security features to:
Manage vulnerabilities.
Assess compliance with common frameworks like PCI.
Strengthen the overall security of your environment.
To learn more, see Enable enhanced security features.
Improve your Secure Score

Secure Score provides recommendations and best practice advice for improving your
overall security. These recommendations are prioritized to help you pick which ones are
most important, and the Quick Fix options help you address potential vulnerabilities
quickly. These recommendations also update over time, keeping you up to date on the
best ways to maintain your environment’s security. To learn more, see Improve your
Secure Score in Microsoft Defender for Cloud.
Azure Virtual Desktop security best practices

Azure Virtual Desktop has many built-in security controls. In this section, you'll learn
about security controls you can use to keep your users and data safe.
Require multi-factor authentication
Requiring multi-factor authentication for all users and admins in Azure Virtual Desktop
improves the security of your entire deployment. To learn more, see Enable Azure AD
Multi-Factor Authentication for Azure Virtual Desktop.
Enable Conditional Access

Enabling Conditional Access lets you manage risks before you grant users access to your
Azure Virtual Desktop environment. When deciding which users to grant access to, we
recommend you also consider who the user is, how they sign in, and which device
they're using.
Collect audit logs

Enabling audit log collection lets you view user and admin activity related to Azure
Virtual Desktop. Some examples of key audit logs are:
Azure Activity Log

Azure Active Directory Activity Log
Session hosts
Key Vault logs
Use RemoteApps
When choosing a deployment model, you can either provide remote users access to
entire virtual desktops or only select applications. Remote applications, or RemoteApps,
provide a seamless experience as the user works with apps on their virtual desktop.
RemoteApps reduce risk by only letting the user work with a subset of the remote
machine exposed by the application.
Monitor usage with Azure Monitor

Monitor your Azure Virtual Desktop service's usage and availability with Azure
Monitor . Consider creating service health alerts for the Azure Virtual Desktop service
to receive notifications whenever there's a service impacting event.
Encrypt your VM
Encrypt your VM with managed disk encryption options to protect stored data from
unauthorized access.
Session host security best practices

Session hosts are virtual machines that run inside an Azure subscription and virtual
network. Your Azure Virtual Desktop deployment's overall security depends on the
security controls you put on your session hosts. This section describes best practices for
keeping your session hosts secure.
Enable endpoint protection

To protect your deployment from known malicious software, we recommend enabling
endpoint protection on all session hosts. You can use either Windows Defender Antivirus
or a third-party program. To learn more, see Deployment guide for Windows Defender
Antivirus in a VDI environment.
For profile solutions like FSLogix or other solutions that mount VHD files, we
recommend excluding VHD file extensions.
Install an endpoint detection and response product

We recommend you install an endpoint detection and response (EDR) product to
provide advanced detection and response capabilities. For server operating systems with
Microsoft Defender for Cloud enabled, installing an EDR product will deploy Microsoft
Defender for Endpoint. For client operating systems, you can deploy Microsoft Defender
for Endpoint or a third-party product to those endpoints.
Enable threat and vulnerability management assessments

Identifying software vulnerabilities that exist in operating systems and applications is
critical to keeping your environment secure. Microsoft Defender for Cloud can help you
identify problem spots through Microsoft Defender for Endpoint's threat and
vulnerability management solution. You can also use third-party products if you're so
inclined, although we recommend using Microsoft Defender for Cloud and Microsoft
Defender for Endpoint.
Patch software vulnerabilities in your environment

Once you identify a vulnerability, you must patch it. This applies to virtual environments
as well, which includes the running operating systems, the applications that are
deployed inside of them, and the images you create new machines from. Follow your
vendor patch notification communications and apply patches in a timely manner. We
recommend patching your base images monthly to ensure that newly deployed
machines are as secure as possible.
Establish maximum inactive time and disconnection

policies
Signing users out when they're inactive preserves resources and prevents access by
unauthorized users. We recommend that timeouts balance user productivity as well as
resource usage. For users that interact with stateless applications, consider more
aggressive policies that turn off machines and preserve resources. Disconnecting long
running applications that continue to run if a user is idle, such as a simulation or CAD
rendering, can interrupt the user's work and may even require restarting the computer.
Set up screen locks for idle sessions

You can prevent unwanted system access by configuring Azure Virtual Desktop to lock a
machine's screen during idle time and requiring authentication to unlock it.
Establish tiered admin access

We recommend you don't grant your users admin access to virtual desktops. If you need
software packages, we recommend you make them available through configuration
management utilities like Microsoft Intune. In a multi-session environment, we
recommend you don't let users install software directly.
Consider which users should access which resources

Consider session hosts as an extension of your existing desktop deployment. We
recommend you control access to network resources the same way you would for other
desktops in your environment, such as using network segmentation and filtering. By
default, session hosts can connect to any resource on the internet. There are several
ways you can limit traffic, including using Azure Firewall, Network Virtual Appliances, or
proxies. If you need to limit traffic, make sure you add the proper rules so that Azure
Virtual Desktop can work properly.
Manage Office Pro Plus security

In addition to securing your session hosts, it's important to also secure the applications
running inside of them. Office Pro Plus is one of the most common applications
deployed in session hosts. To improve the Office deployment security, we recommend
you use the Security Policy Advisor for Microsoft 365 Apps for enterprise. This tool
identifies policies that can you can apply to your deployment for more security. Security
Policy Advisor also recommends policies based on their impact to your security and
productivity.
Other security tips for session hosts

By restricting operating system capabilities, you can strengthen the security of your
session hosts. Here are a few things you can do:
Control device redirection by redirecting drives, printers, and USB devices to a

user's local device in a remote desktop session. We recommend that you evaluate
your security requirements and check if these features ought to be disabled or not.
Restrict Windows Explorer access by hiding local and remote drive mappings. This
prevents users from discovering unwanted information about system configuration
and users.
Avoid direct RDP access to session hosts in your environment. If you need direct
RDP access for administration or troubleshooting, enable just-in-time access to
limit the potential attack surface on a session host.
Grant users limited permissions when they access local and remote file systems.
You can restrict permissions by making sure your local and remote file systems use
access control lists with least privilege. This way, users can only access what they
need and can't change or delete critical resources.
Prevent unwanted software from running on session hosts. You can enable App
Locker for additional security on session hosts, ensuring that only the apps you
allow can run on the host.
Azure Virtual Desktop support for Trusted

Launch
Trusted launch are Gen2 Azure VMs with enhanced security features aimed to protect
against “bottom of the stack” threats through attack vectors such as rootkits, boot kits,
and kernel-level malware. The following are the enhanced security features of trusted
launch, all of which are supported in Azure Virtual Desktop. To learn more about trusted
launch, visit Trusted launch for Azure virtual machines.
Azure Confidential Computing virtual machines

(preview)
） Important
Azure Virtual Desktop support for Azure Confidential virtual machines is currently in
PREVIEW.
See the Supplemental Terms of Use for Microsoft Azure Previews for
legal terms that apply to Azure features that are in beta, preview, or otherwise not
yet released into general availability.
Azure Virtual Desktop support for Azure Confidential Computing virtual machines
(preview) ensures a user’s virtual desktop is encrypted in memory, protected in use, and
backed by hardware root of trust. Deploying confidential VMs with Azure Virtual
Desktop gives users access to Microsoft 365 and other applications on session hosts
that use hardware-based isolation, which hardens isolation from other virtual machines,
the hypervisor, and the host OS. These virtual desktops are powered by the latest Third-
generation (Gen 3) Advanced Micro Devices (AMD) EPYC™ processor with Secure
Encrypted Virtualization Secure Nested Paging (SEV-SNP) technology. Memory
encryption keys are generated and safeguarded by a dedicated secure processor inside
the AMD CPU that can't be read from software. For more information, see the Azure
Confidential Computing overview.
Secure Boot
Secure Boot is a mode that platform firmware supports that protects your firmware from
malware-based rootkits and boot kits. This mode only allows signed OSes and drivers to
start up the machine.
Monitor boot integrity using Remote Attestation

Remote attestation is a great way to check the health of your VMs. Remote attestation
verifies that Measured Boot records are present, genuine, and originate from the Virtual
Trusted Platform Module (vTPM). As a health check, it provides cryptographic certainty
that a platform started up correctly.
vTPM
A vTPM is a virtualized version of a hardware Trusted Platform Module (TPM), with a
virtual instance of a TPM per VM. vTPM enables remote attestation by performing
integrity measurement of the entire boot chain of the VM (UEFI, OS, system, and
drivers).
We recommend enabling vTPM to use remote attestation on your VMs. With vTPM
enabled, you can also enable BitLocker functionality with Azure Disk Encryption, which
provides full-volume encryption to protect data at rest. Any features using vTPM will
result in secrets bound to the specific VM. When users connect to the Azure Virtual
Desktop service in a pooled scenario, users can be redirected to any VM in the host
pool. Depending on how the feature is designed this may have an impact.
７ Note
BitLocker should not be used to encrypt the specific disk where you're storing your
FSLogix profile data.
Virtualization-based Security
Virtualization-based Security (VBS) uses the hypervisor to create and isolate a secure
region of memory that's inaccessible to the OS. Hypervisor-Protected Code Integrity
(HVCI) and Windows Defender Credential Guard both use VBS to provide increased
protection from vulnerabilities.
Hypervisor-Protected Code Integrity

HVCI is a powerful system mitigation that uses VBS to protect Windows kernel-mode
processes against injection and execution of malicious or unverified code.
Windows Defender Credential Guard

Windows Defender Credential Guard uses VBS to isolate and protect secrets so that only
privileged system software can access them. This prevents unauthorized access to these
secrets and credential theft attacks, such as Pass-the-Hash attacks.
Nested virtualization
The following operating systems support running nested virtualization on Azure Virtual
Desktop:
Windows Server 2016
Windows Server 2019
Windows Server 2022
Windows Defender Application Control

The following operating systems support using Windows Defender Application Control
with Azure Virtual Desktop:
Windows Server 2016

Windows Server 2019
Windows Server 2022
７ Note
When using Windows Defender Access Control, we recommend only targeting

policies at the device level. Although it's possible to target policies to individual
users, once the policy is applied, it affects all users on the device equally.
Windows Update
Windows Update provides a secure way to keep your devices up-to-date. Its end-to-end
protection prevents manipulation of protocol exchanges and ensures updates only
include approved content. You may need to update firewall and proxy rules for some of
your protected environments in order to get proper access to Windows Updates. For
more information, see Windows Update security.
Client updates on other OS platforms

Software updates for the Remote Desktop clients you can use to access Azure Virtual
Desktop services on other OS platforms are secured according to the security policies of
their respective platforms. All client updates are delivered directly by their platforms. For
more information, see the respective store pages for each app:
macOS
iOS
Android
Next steps
To learn how to enable multi-factor authentication, see Set up multi-factor
authentication.
 Documentation
Azure security baseline for Azure Virtual Desktop

The Azure Virtual Desktop security baseline provides procedural guidance and resources for
implementing the security recommendations specified in the Microsoft cloud security benchmark.
Identity and access management for Azure Virtual Desktop - Cloud Adoption
Framework
Learn how to use Azure role-based access control for identity and access management in your virtual
desktop infrastructure.
Azure Virtual Desktop architecture recommendations - Azure

Architecture recommendations for Azure Virtual Desktop for app developers.


Security guide for cross-organizational apps Azure Virtual Desktop - Azure

A guide for how to keep the apps you host in Azure Virtual Desktop secure across multiple
organizations.


Show 5 more
 Training
Module
Secure an Azure Virtual Desktop deployment - Training
Introduction to Microsoft security capabilities that can help keep your applications and data secure
in your Azure Virtual Desktop deployment.
Certification
Azure security baseline for Azure Virtual
Desktop
This security baseline applies guidance from the Microsoft cloud security benchmark
version 1.0 to Azure Virtual Desktop. The Microsoft cloud security benchmark provides
recommendations on how you can secure your cloud solutions on Azure. The content is
grouped by the security controls defined by the Microsoft cloud security benchmark and
the related guidance applicable to Azure Virtual Desktop.
You can monitor this security baseline and its recommendations using Microsoft
Defender for Cloud. Azure Policy definitions will be listed in the Regulatory Compliance
section of the Microsoft Defender for Cloud dashboard.
When a feature has relevant Azure Policy Definitions, they are listed in this baseline to
help you measure compliance to the Microsoft cloud security benchmark controls and
recommendations. Some recommendations may require a paid Microsoft Defender plan
to enable certain security scenarios.
７ Note
Features not applicable to Azure Virtual Desktop have been excluded. To see how
Azure Virtual Desktop completely maps to the Microsoft cloud security benchmark,
see the full Azure Virtual Desktop security baseline mapping file .
Security profile
The security profile summarizes high-impact behaviors of Azure Virtual Desktop, which
may result in increased security considerations.
Service Behavior Attribute Value
Product Category Virtual Desktop
Customer can access HOST / OS Full Access
Service can be deployed into customer's virtual network False
Stores customer content at rest False

Network security
For more information, see the Microsoft cloud security benchmark: Network security.
NS-1: Establish network segmentation boundaries
Features
Virtual Network Integration
Description: Service supports deployment into customer's private Virtual Network

(VNet). Learn more.
Supported Enabled By Default Configuration Responsibility
True False Customer
Feature notes: Virtual machines within the host pool must be placed in a virtual
network.
Configuration Guidance: Deploy the service into a virtual network. Assign private IPs to
the resource (where applicable) unless there is a strong reason to assign public IPs
directly to the resource.
Reference: Tutorial: Create a host pool
Network Security Group Support
Description: Service network traffic respects Network Security Groups rule assignment
on its subnets. Learn more.
True False Customer
Feature notes: Virtual machines used within the host pool support use of network
security groups.
Configuration Guidance: Use network security groups (NSG) to restrict or monitor traffic
by port, protocol, source IP address, or destination IP address. Create NSG rules to
restrict your service's open ports (such as preventing management ports from being
accessed from untrusted networks). Be aware that by default, NSGs deny all inbound
traffic but allow traffic from virtual network and Azure Load Balancers.
Reference: Tutorial: Create a host pool
NS-2: Secure cloud services with network controls
Features
Azure Private Link
Description: Service native IP filtering capability for filtering network traffic (not to be
confused with NSG or Azure Firewall). Learn more.
True False Customer
Feature notes: Private link with Azure Virtual Desktop is currently in preview.
Configuration Guidance: Deploy private endpoints for all Azure resources that support
the Private Link feature, to establish a private access point for the resources.
Reference: Use Azure Private Link with Azure Virtual Desktop (preview)
Disable Public Network Access
Description: Service supports disabling public network access either through using
service-level IP ACL filtering rule (not NSG or Azure Firewall) or using a 'Disable Public
Network Access' toggle switch. Learn more.
False Not Applicable Not Applicable
Configuration Guidance: This feature is not supported to secure this service.
Identity management
For more information, see the Microsoft cloud security benchmark: Identity management.
IM-1: Use centralized identity and authentication system

Features
Azure AD Authentication Required for Data Plane Access
Description: Service supports using Azure AD authentication for data plane access.
Learn more.
True False Customer
Configuration Guidance: Use Azure Active Directory (Azure AD) as the default
authentication method to control your data plane access.
Reference: Azure AD join for Azure Virtual Desktop
IM-3: Manage application identities securely and

automatically
Features
Managed Identities
Description: Data plane actions support authentication using managed identities. Learn
more.
True False Customer
Configuration Guidance: Use Azure managed identities instead of service principals

when possible, which can authenticate to Azure services and resources that support
Azure Active Directory (Azure AD) authentication. Managed identity credentials are fully
managed, rotated, and protected by the platform, avoiding hard-coded credentials in
source code or configuration files.
Reference: Set up managed identities
Service Principals
Description: Data plane supports authentication using service principals. Learn more.
True False Customer
Configuration Guidance: There is no current Microsoft guidance for this feature

configuration. Please review and determine if your organization wants to configure this
security feature.
Reference: Tutorial: Create service principals and role assignments with PowerShell in
Azure Virtual Desktop (classic)
IM-7: Restrict resource access based on conditions
Features
Conditional Access for Data Plane
Description: Data plane access can be controlled using Azure AD Conditional Access
Policies. Learn more.
True False Customer
Configuration Guidance: Define the applicable conditions and criteria for Azure Active
Directory (Azure AD) conditional access in the workload. Consider common use cases
such as blocking or granting access from specific locations, blocking risky sign-in
behavior, or requiring organization-managed devices for specific applications.
Reference: Enable Conditional Access
IM-8: Restrict the exposure of credential and secrets
Features
Service Credential and Secrets Support Integration and Storage in

Azure Key Vault
Description: Data plane supports native use of Azure Key Vault for credential and secrets
store. Learn more.
Privileged access
For more information, see the Microsoft cloud security benchmark: Privileged access.
PA-1: Separate and limit highly privileged/administrative

users
Features
Local Admin Accounts
Description: Service has the concept of a local administrative account. Learn more.
True False Customer
Feature notes: A local virtual machine administrator account is created for virtual
machines that are added to the host pool. Avoid the usage of local authentication
methods or accounts, these should be disabled wherever possible. Instead use Azure AD
to authenticate where possible.
Configuration Guidance: If not required for routine administrative operations, disable or

restrict any local admin accounts for only emergency use.
PA-7: Follow just enough administration (least privilege)

principle
Features
Azure RBAC for Data Plane
Description: Azure Role-Based Access Control (Azure RBAC) can be used to managed
access to service's data plane actions. Learn more.
True False Customer
Configuration Guidance: Use Azure role-based access control (Azure RBAC) to manage
Azure resource access through built-in role assignments. Azure RBAC roles can be
assigned to users, groups, service principals, and managed identities.
Reference: Built-in Azure RBAC roles for Azure Virtual Desktop
PA-8: Determine access process for cloud provider

support
Features
Customer Lockbox
Description: Customer Lockbox can be used for Microsoft support access. Learn more.
Data protection
For more information, see the Microsoft cloud security benchmark: Data protection.
DP-1: Discover, classify, and label sensitive data
Features
Sensitive Data Discovery and Classification
Description: Tools (such as Azure Purview or Azure Information Protection) can be used
for data discovery and classification in the service. Learn more.

True False Customer
Feature notes: Use Azure Information Protection (and its associated scanning tool) for
sensitive information within Office documents on Azure, on-premises, Office 365 and
other locations.
Configuration Guidance: Use tools such as Azure Purview, Azure Information Protection,
and Azure SQL Data Discovery and Classification to centrally scan, classify and label any
sensitive data that resides in Azure, on-premises, Microsoft 365, or other locations.
DP-2: Monitor anomalies and threats targeting sensitive

data
Features
Data Leakage/Loss Prevention
Description: Service supports DLP solution to monitor sensitive data movement (in
customer's content). Learn more.
True False Microsoft
Feature notes: Use data loss prevention solutions, such as host-based ones, to enforce
detective and/or preventative controls to prevent data exfiltration.
Solutions such as DLP for Microsoft Azure may also be used for your Virtual Desktop
Environment. For more information, please visit: Data Loss Prevention (DLP) for
Microsoft Azure
Azure Information protection (AIP) provides monitoring capabilities
for information that has been classified and labeled.
Configuration Guidance: If required for compliance of data loss prevention (DLP), you
can use a host based DLP solution from Azure Marketplace or a Microsoft 365 DLP
solution to enforce detective and/or preventative controls to prevent data exfiltration.
DP-3: Encrypt sensitive data in transit
Features
Data in Transit Encryption
Description: Service supports data in-transit encryption for data plane. Learn more.
True True Microsoft
Configuration Guidance: No additional configurations are required as this is enabled on

a default deployment.
Reference: Networking
DP-4: Enable data at rest encryption by default
Features
Data at Rest Encryption Using Platform Keys
Description: Data at-rest encryption using platform keys is supported, any customer
content at rest is encrypted with these Microsoft managed keys. Learn more.
True True Microsoft
Configuration Guidance: No additional configurations are required as this is enabled on

a default deployment.
Reference: Data protection
DP-5: Use customer-managed key option in data at rest

encryption when required
Features
Data at Rest Encryption Using CMK
Description: Data at-rest encryption using customer-managed keys is supported for

customer content stored by the service. Learn more.
DP-6: Use a secure key management process
Features
Key Management in Azure Key Vault
Description: The service supports Azure Key Vault integration for any customer keys,
secrets, or certificates. Learn more.
DP-7: Use a secure certificate management process
Features
Certificate Management in Azure Key Vault
Description: The service supports Azure Key Vault integration for any customer
certificates. Learn more.
Asset management
For more information, see the Microsoft cloud security benchmark: Asset management.
AM-2: Use only approved services
Features
Azure Policy Support
Description: Service configurations can be monitored and enforced via Azure Policy.
Learn more.
True False Customer
Configuration Guidance: Use Microsoft Defender for Cloud to configure Azure Policy to
audit and enforce configurations of your Azure resources. Use Azure Monitor to create
alerts when there is a configuration deviation detected on the resources. Use Azure
Policy [deny] and [deploy if not exists] effects to enforce secure configuration across
Azure resources.
Reference: Azure security baseline for Azure Virtual Desktop
AM-5: Use only approved applications in virtual machine
Features
Microsoft Defender for Cloud - Adaptive Application Controls
Description: Service can limit what customer applications run on the virtual machine
using Adaptive Application Controls in Microsoft Defender for Cloud. Learn more.
Feature notes: Though Adaptive Application Control through Microsoft Defender for
Cloud is not supported, when choosing a deployment model, you can either provide
remote users access to entire virtual desktops or only select applications. Remote
applications, or RemoteApps, provide a seamless experience as the user works with apps
on their virtual desktop. RemoteApps reduce risk by only letting the user work with a
subset of the remote machine exposed by the application.
For more information, please visit: Use Remote Apps
Logging and threat detection

For more information, see the Microsoft cloud security benchmark: Logging and threat
detection.
LT-1: Enable threat detection capabilities
Features
Microsoft Defender for Service / Product Offering
Description: Service has an offering-specific Microsoft Defender solution to monitor and

alert on security issues. Learn more.
True False Customer
Configuration Guidance: Use Azure Active Directory (Azure AD) as the default
authentication method to control your management plane access. When you get an
alert from Microsoft Defender for Key Vault, investigate and respond to the alert.
Reference: Onboard Windows devices in Azure Virtual Desktop
LT-4: Enable logging for security investigation
Features
Azure Resource Logs
Description: Service produces resource logs that can provide enhanced service-specific
metrics and logging. The customer can configure these resource logs and send them to
their own data sink like a storage account or log analytics workspace. Learn more.

True False Customer
Configuration Guidance: Enable resource logs for the service. For example, Key Vault
supports additional resource logs for actions that get a secret from a key vault or and
Azure SQL has resource logs that track requests to a database. The content of resource
logs varies by the Azure service and resource type.
Reference: Push diagnostics data to your workspace
Posture and vulnerability management

For more information, see the Microsoft cloud security benchmark: Posture and
vulnerability management.
PV-3: Define and establish secure configurations for

compute resources
Features
Azure Automation State Configuration
Description: Azure Automation State Configuration can be used to maintain the security
configuration of the operating system. Learn more.
Azure Policy Guest Configuration Agent
Description: Azure Policy guest configuration agent can be installed or deployed as an

extension to compute resources. Learn more.

Custom VM Images
Description: Service supports using user-supplied VM images or pre-built images from

the marketplace with certain baseline configurations pre-applied. Learn more.
True False Customer
Configuration Guidance: Use a pre-configured hardened image from a trusted supplier

such as Microsoft or build a desired secure configuration baseline into the VM image
template
Reference: Operating systems and licenses
Custom Containers Images
Description: Service supports using user-supplied container images or pre-built images

from the marketplace with certain baseline configurations pre-applied. Learn more.
PV-5: Perform vulnerability assessments
Features
Vulnerability Assessment using Microsoft Defender
Description: Service can be scanned for vulnerability scan using Microsoft Defender for
Cloud or other Microsoft Defender services embedded vulnerability assessment
capability (including Microsoft Defender for server, container registry, App Service, SQL,
and DNS). Learn more.
True False Customer

Configuration Guidance: Follow recommendations from Microsoft Defender for Cloud
for performing vulnerability assessments on your Azure virtual machines, container
images, and SQL servers.
Reference: Enable Microsoft Defender for Cloud
PV-6: Rapidly and automatically remediate vulnerabilities
Features
Azure Automation Update Management
Description: Service can use Azure Automation Update Management to deploy patches
and updates automatically. Learn more.
Endpoint security
For more information, see the Microsoft cloud security benchmark: Endpoint security.
ES-1: Use Endpoint Detection and Response (EDR)
Features
EDR Solution
Description: Endpoint Detection and Response (EDR) feature such as Azure Defender for
servers can be deployed into the endpoint. Learn more.
True False Customer
Configuration Guidance: Azure Defender for servers (with Microsoft Defender for
Endpoint integrated) provides EDR capability to prevent, detect, investigate, and
respond to advanced threats. Use Microsoft Defender for Cloud to deploy Azure
Defender for servers for your endpoint and integrate the alerts to your SIEM solution
such as Azure Sentinel.
Reference: Enable endpoint protection
ES-2: Use modern anti-malware software
Features
Anti-Malware Solution
Description: Anti-malware feature such as Microsoft Defender Antivirus, Microsoft

Defender for Endpoint can be deployed on the endpoint. Learn more.
True False Customer
Configuration Guidance: For Windows Server 2016 and above, Microsoft Defender for
Antivirus is installed by default. For Windows Server 2012 R2 and above, customers can
install SCEP (System Center Endpoint Protection). For Linux, customers can have the
choice of installing Microsoft Defender for Linux. Alternatively, customers also have the
choice of installing third-party anti-malware products.
ES-3: Ensure anti-malware software and signatures are

updated
Features
Anti-Malware Solution Health Monitoring
Description: Anti-malware solution provides health status monitoring for platform,

engine, and automatic signature updates. Learn more.
True False Customer

Configuration Guidance: Configure your anti-malware solution to ensure the platform,
engine and signatures are updated rapidly and consistently and their status can be
monitored.
Backup and recovery

For more information, see the Microsoft cloud security benchmark: Backup and recovery.
BR-1: Ensure regular automated backups
Features
Azure Backup
Description: The service can be backed up by the Azure Backup service. Learn more.
True False Customer
Configuration Guidance: Enable Azure Backup and configure the backup source (such
as Azure Virtual Machines, SQL Server, HANA databases, or File Shares) on a desired
frequency and with a desired retention period. For Azure Virtual Machines, you can use
Azure Policy to enable automatic backups.
Reference: How does Azure Virtual Desktop handle backups?
Service Native Backup Capability
Description: Service supports its own native backup capability (if not using Azure
Backup). Learn more.
Feature notes: Azure Virtual Desktop leverages Azure Backup.

Next steps
See the Microsoft cloud security benchmark overview
Learn more about Azure security baselines
Tag Azure Virtual Desktop resources to
manage costs
Tagging is a tool available across Azure services that helps you organize resources inside
their Azure subscription. Organizing resources makes it easier to track costs across
multiple services. Tags also help you understand how much each grouping of Azure
resources costs per billing cycle. If you'd like to learn more about tagging in general, see
Use tags to organize your Azure resources and management hierarchy. You can also
watch a quick video about some other ways to use Azure tags.
How tagging works

You can tag Azure services you manage in the Azure portal or through PowerShell. The
tags will appear as key-value pairs of text. As you use tagged Azure resources, the
associated tag key-value pair will be attached to the resource usage.
Once your deployment reports tagged usage information to Azure Cost Management,
you can use your tagging structure to filter cost data. To learn how to filter by tags in
Azure Cost Management, see Quickstart: Explore and analyze costs with cost analysis.
Add, edit, or delete tags

When you apply a new tag to a resource, it won't be visible in Azure Cost Management
until its associated Azure resource reports activity. If you apply an existing tag to your
resources, this change also won't be visible in Azure Cost Management until the Azure
resources report activity.
If you edit a tag name, the associated resources will now associate costs with its new
key-value pair. You can still filter data with the old tag, but all new data from after the
change will be reported with the new tag.
If you delete a tag, Azure Virtual Desktop will no longer report data associated with the
deleted tag to Azure Cost Management. You can still filter with deleted tags for data
reported before you deleted the tag.
） Important
Tagged Azure resources that haven't been active since you applied new or updated
tags to them won't report any activity associated with the changed tags to Azure
Cost Management. You won't be able to filter for specific tags until their associated
activity is reported to Azure Cost Management by the service.
View all existing tags

You can view all existing tags for your Azure services by going to the Azure portal, then
opening the Tags tab . The Tags tab will show you all tags in objects you have access
to. You can also sort tags by their keys or values whenever you need to quickly update a
large number of tags at the same time.
What tags can and can't do

Tags only report usage and cost data for Azure resources they're directly assigned to. If
you've tagged a resource without tagging the other resources in it, then Azure Virtual
Desktop will only report activity related to the top-level tagged resource. You'll also
need to tag every resource under that top-level resource if you want your billing data to
be accurate.
To learn more about how tags work in Azure Cost Management, see How tags are used
in cost and usage data.
For a list of known Azure tag limitations, see Use tags to organize your Azure resources
and management hierarchy.
Using tags in Azure Virtual Desktop

Now that you understand the basics of Azure tags, let’s go over how you can use them
in Azure Virtual Desktop.
You can use Azure tags to organize costs for creating, managing, and deploying
virtualized experiences for your customers and users. Tagging can also help you track
resources you buy directly through Azure Virtual Desktop and other Azure services
connected to Azure Virtual Desktop deployments.
Suggested tags for Azure Virtual Desktop

Because Azure Virtual Desktop can work with other Azure services to support its
deployments, there isn't a universal system for tagging deployment resources. What's
most important is that you develop a strategy that works for you and your organization.
However, we do have some suggestions that might help you, especially if you're new to
using Azure.
The following suggestions apply to all Azure Virtual Desktop deployments:
Become familiar with your purchased Azure services so you understand the extent
of what you want to tag. As you learn how to use the Azure portal, keep a list of
service groups and objects where you can apply tags. Some resources that you
should keep track of include resource groups, virtual machines, disks, and network
interface cards (NICs). For a more comprehensive list of cost generating service
components you can tag, see Understanding total Azure Virtual Desktop
deployment costs.
Create a cost reporting aggregation to organize your tags. You can either follow a
common tagging pattern or create a new pattern that meets your organization’s
needs.
Keep your tags consistent wherever you apply them. Even the smallest typo can
impact data reporting, so make sure you're adding the exact key-value pair you
want to look up later.
Keep a record of any tags you update or edit. This record will let you combine each
tag's historic data as needed. When you edit or update a tag, you should also
apply those changes across all resources that include the changed tag.
Suggested tags for Azure Virtual Desktop host

pools
Every virtual machine in an Azure Virtual Desktop host pool creates a cost-producing
construct. Because host pools are the foundation of an Azure Virtual Desktop
deployment, their VMs are typically the main source of costs for Azure Virtual Desktop
deployments. If you want to set up a tagging system, we recommend that you start with
tagging all the host pools in your deployment to track VM compute costs. Tagging your
host pools can help you use filtering in Azure Cost Management to identify these VM
costs.
Like with the general suggestions, there's no universal system for tagging host pools.
However, we do have a few suggestions to help you organize your host pool tags:
Tagging host pools while you're creating them is optional, but tagging during the
creation process will make it easier for you to view all tagged usage in Azure Cost
Management later. Your host pool tags will follow all cost-generating components
of the session hosts within your host pool. Learn more about session host-specific
costs at Understanding total Azure Virtual Desktop deployment costs.
If you use the Azure portal to create a new host pool, the creation workflow will
give you the chance to add existing tags. These tags will be passed along to all
resources you create during the host pool creation process. Tags will also be
applied to any session hosts you add to an existing host pool in the Azure portal.
However, you'll need to enter the tags manually every time you add a new session
host.
It's unlikely you'll ever get a complete cost report of every supporting Azure
service working with your host pools, since configuration options are both limitless
and unique to each customer. It's up to you to decide how closely you want to
track costs across any Azure services associated with your Azure Virtual Desktop
deployment. The more thoroughly you track these costs by tagging, the more
accurate your monthly Azure Virtual Desktop cost report will become.
If you build your tagging system around your host pools, make sure to use key-
value pairs that make sense to add to other Azure services later.
Use the cm-resource-parent tag to automatically group

costs by host pool
You can group costs by host pool by using the cm-resource-parent tag. This tag won't
impact billing but will let you review tagged costs in Microsoft Cost Management
without having to use filters. The key for this tag is cm-resource-parent and its value is
the resource ID of the Azure resource you want to group costs by. For example, you can
group costs by host pool by entering the host pool resource ID as the value. To learn
more about how to use this tag, see Group related resources in the cost analysis
(preview).
Suggested tags for other Azure Virtual Desktop

resources
Most Azure Virtual Desktop customers deploy other Azure services to support their
deployments. If you want to include the cost of these extra services in your cost report,
you should consider the following suggestions:
If you've already purchased an Azure service or resources that you want to

integrate into your Azure Virtual Desktop deployments, you have two options:
Separate your purchased Azure services between different Azure subscriptions.
Combine all purchased Azure services in the same subscription with your Azure
Virtual Desktop tags.
Separating your services will give you a clearer idea of costs for each service, but
may end up being more expensive in the end. You may need to purchase extra
storage for these services to make sure your Azure Virtual Desktop has its own
designated storage.
Combining your purchased services is less expensive, but may inflate your cost
report because the usage data for shared resources won't be as accurate. To make
up for the lack of accuracy, you can add multiple tags to your resources to see
shared costs through filters that track different factors.
If you started building your tagging system with a different Azure service, make
sure the key-value pairs you create can be applied to your Azure Virtual Desktop
deployment or other services later.
Next steps
If you’d like to learn more about common Azure Virtual Desktop related costs, check out
Understanding total Azure Virtual Desktop deployment costs.
If you’d like to learn more about Azure tags, check out the following resources:
Use tags to organize your Azure resources and management hierarchy
A video explaining the value of using Azure tags
How tags are used in cost and usage data
Develop your naming and tagging strategy for Azure resources
Define your tagging strategy
Resource naming and tagging decision guide
If you’d like to learn more about Azure Cost Management, check out the following
articles:
What is Azure Cost Management + Billing?
Quickstart: Explore and analyze costs with cost analysis

Remote Desktop clients for Azure
Virtual Desktop
With Microsoft Remote Desktop clients, you can connect to Azure Virtual Desktop and
use and control desktops and apps that your admin has made available to you. There
are clients available for many different types of devices on different platforms and form
factors, such as desktops and laptops, tablets, smartphones, and through a web
browser. Using your web browser on desktops and laptops, you can connect without
having to download and install any software.
There are many features you can use to enhance your remote experience, such as:
Multiple monitor support.

Custom display resolutions.
Dynamic display resolutions and scaling.
Device redirection, such as webcams, storage devices, and printers.
Microsoft Teams optimizations.
Some features are only available with certain clients, so it's important to check Compare
the features of the Remote Desktop clients to understand the differences when
 Tip
You can use most versions of the Remote Desktop client to connect to Remote
Desktop Services in Windows Server or to a remote PC, as well as to Azure Virtual
Desktop. If you'd prefer to use Remote Desktop Services instead, learn more at
Remote Desktop clients for Remote Desktop Services.
Here's a list of the Remote Desktop client apps and our documentation for connecting
to Azure Virtual Desktop, where you can find download links, what's new, and learn how
to install and use each client.
Remote Documentation and download links Version

Desktop client information
Windows Connect to Azure Virtual Desktop with the Remote Desktop What's new
Desktop client for Windows
Remote Documentation and download links Version
Desktop client information
Web Connect to Azure Virtual Desktop with the Remote Desktop What's new
client for Web
macOS Connect to Azure Virtual Desktop with the Remote Desktop What's new
client for macOS
iOS/iPadOS Connect to Azure Virtual Desktop with the Remote Desktop What's new
client for iOS and iPadOS
Android/Chrome Connect to Azure Virtual Desktop with the Remote Desktop What's new
OS client for Android and Chrome OS
Microsoft Store Connect to Azure Virtual Desktop with the Remote Desktop What's new
client for Windows (Microsoft Store)
 Documentation
Connect to Azure Virtual Desktop with the Remote Desktop client for Windows
(Microsoft Store) - Azure Virtual Desktop
Learn how to connect to Azure Virtual Desktop using the Remote Desktop client for Windows
(Microsoft Store).
Connect to Azure Virtual Desktop (classic) Windows 10 or 7 - Azure

How to connect to Azure Virtual Desktop (classic) using the Windows Desktop client.
Connect to Azure Virtual Desktop with the Remote Desktop client for Android and
Chrome OS- Azure Virtual Desktop
Learn how to connect to Azure Virtual Desktop using the Remote Desktop client for Android and
Chrome OS.
Connect to Azure Virtual Desktop with the Remote Desktop client for macOS - Azure
Virtual Desktop
Learn how to connect to Azure Virtual Desktop using the Remote Desktop client for macOS.
Virtual Desktop.
Connect Azure Virtual Desktop (classic) web client - Azure

How to connect to Azure Virtual Desktop (classic) using the web client.
What's new in the Remote Desktop client for Windows

Learn about recent changes to the Remote Desktop client for Windows
Show 5 more
Compare the features of the Remote
Desktop clients when connecting to
There are some differences between the features of each of the Remote Desktop clients
when connecting to Azure Virtual Desktop. Below you can find information about what
these differences are.
 Tip
Some clients and features differ when using Azure Virtual Desktop to using Remote
Desktop Services. If you want to see the clients and features for Remote Desktop
Services, see Compare the clients: features and Compare the clients: redirections.
Features comparison
The following table compares the features of each Remote Desktop client when
Feature Windows Microsoft Android iOS or macOS Web Description

Desktop Store or iPadOS
Chrome
OS
Remote X X X X X X Desktop of a
Desktop remote
sessions computer
presented in a
full screen or
windowed
mode.
Integrated X X Individual
RemoteApp remote apps
sessions integrated into
the local
desktop as if
they are
running locally.
Chrome
OS
Immersive X X X X Individual
RemoteApp remote apps
sessions presented in a
window or
maximized to a
full screen.
Multiple 16 16 Lets the user

monitors monitor monitor run Remote
limit limit Desktop or
remote apps on
all local
monitors.
Each monitor
can have a
maximum
resolution of
8K, with the
total resolution
limited to 32K.
These limits
depend on
factors such as
session host
specification
and network
connectivity.
Dynamic X X X X Resolution and

resolution orientation of
local monitors
is dynamically
reflected in the
remote session.
If the client is
running in
windowed
mode, the
remote desktop
is resized
dynamically to
the size of the
client window.
Chrome
OS
Smart sizing X X X Remote

Desktop in
Windowed
mode is
dynamically
scaled to the
window's size.
Localization X X English X X Client user

only interface is
available in
multiple
languages.
Multi-factor X X X X X X Supports multi-

authentication factor
authentication
for remote
connections.
Teams X X Media
optimization optimizations
for Azure for Microsoft
Virtual Teams to
Desktop provide high
quality calls
and screen
sharing
experiences.
Learn more at
Use Microsoft
Teams on Azure
Virtual
Desktop.
Redirections comparison
The following tables compare support for device and other redirections across the
different Remote Desktop clients when connecting to Azure Virtual Desktop.
Organizations can configure redirections centrally through Azure Virtual Desktop RDP
properties or Group Policy.
） Important
You can only enable redirections with binary settings that apply to both to and
from the remote machine. One-way blocking of redirections from only one side of
the connection is not supported.
Input redirection
The following table shows which input methods are available for each Remote Desktop
client:
Input Windows Microsoft Store Android or iOS or macOS Web

Desktop client Chrome OS iPadOS client
Keyboard X X X X X X
Mouse X X X X X X
Touch X X X X X
Multi- X X X X
touch
Pen X X (as touch) X*
* Pen input redirection is not supported when connecting to Windows 8, Windows 8.1,
Windows Server 2012, or Windows Server 2012 R2.
Port redirection
The following table shows which ports can be redirected for each Remote Desktop
client:
Redirection Windows Microsoft Android or iOS or macOS Web

Desktop Store client Chrome OS iPadOS client
Serial port X
USB X
When you enable USB port redirection, all USB devices attached to USB ports are
automatically recognized in the remote session. For devices to work as expected, you
must make sure to install their required drivers on both the local device and session
host. You will need to make sure the drivers are certified to run in remote scenarios. If
you need more information about using your USB device in remote scenarios, talk to the
device manufacturer.
Other redirection (devices, etc.)

The following table shows which other devices can be redirected with each Remote
Desktop client:
Redirection Windows Microsoft Android iOS or macOS Web

Desktop Store or Chrome iPadOS client
client OS
Cameras X X X X X
(preview)
Clipboard X X Text Text, X Text

images
Local X X X X X*
drive/storage
Location X
(Windows
11 only)
Microphones X X X X X X
Printers X X** (CUPS only) PDF

print
Scanners X
Smart cards X X (Windows

sign-in not
supported)
Speakers X X X X X X
Third-party X
virtual channel
plugins
WebAuthn X
* Limited to uploading and downloading files through the Remote Desktop Web client.
** For printer redirection, the macOS app supports the Publisher Imagesetter printer
driver by default. The app doesn't support the native printer drivers.
 Documentation
Desktop.
Virtual Desktop.
(Microsoft Store).
Chrome OS.
Show 5 more
Supported RDP properties with Azure Virtual Desktop
Organizations can configure Remote Desktop Protocol (RDP) properties centrally in Azure Virtual Desktop to determine
how a connection to Azure Virtual Desktop should behave. There are a wide range of RDP properties that can be set, such
as for device redirection, display settings, session behavior, and more. For more information, see Customize RDP
properties for a host pool.
７ Note
Supported RDP properties differ when using Azure Virtual Desktop compared to Remote Desktop Services. Use the
following tables to understand each setting and whether it applies when connecting to Azure Virtual Desktop,
Remote Desktop Services, or both.
Connection information
Display name RDP property Azure Remote Description Values Default
Virtual Desktop value
Desktop Services
Azure AD enablerdsaadauth:i:value ✔ ✔ Determines - 0: RDP won't use Azure AD 0

authentication whether the client authentication, even if the remote
will use Azure AD PC supports it.
to authenticate to - 1: RDP will use Azure AD

the remote PC if authentication if the remote PC
it's available.
supports it.
Note: Available in
preview for
Windows and web
clients only
currently. This
replaces the
property
targetisaadjoined .
Azure AD targetisaadjoined:i:value ✔ ✗ Allows connections - 0: connections to Azure AD- 0

authentication to Azure AD-joined joined session hosts will succeed
session hosts using for Windows devices that meet
username and the requirements, but other
password.
connections will fail.
- 1: connections to Azure AD-

Note: only joined hosts will succeed but are
applicable to non- restricted to entering user name
Windows clients and password credentials when
and local Windows connecting to session hosts.
devices that aren't
joined to Azure
AD.
Credential enablecredsspsupport:i:value ✔ ✔ Determines - 0: RDP won't use CredSSP, even 1

Security whether the client if the operating system supports
Support will use the CredSSP.
Provider Credential Security - 1: RDP will use CredSSP if the

Support Provider operating system supports
(CredSSP) for CredSSP.
authentication if
it's available.
Desktop Services
Alternate shell alternate shell:s:value ✔ ✔ Specifies a Valid path to an executable file, None
program to be such as
started C:\ProgramFiles\Office\word.exe .
automatically in
the remote session
as the shell instead
of explorer.
KDC proxy kdcproxyname:s:value ✔ ✗ Specifies the fully Valid path to a KDC proxy server, None
name qualified domain such as kdc.contoso.com .
name of a KDC
proxy.
Address full address:s:value ✗ ✔ This setting A valid name, IPv4 address, or None
specifies the IPv6 address.
hostname or IP
address of the
remote computer
that you want to
connect to.
This is the only

required setting in
an RDP file.
Alternate alternate full address:s:value ✗ ✔ Specifies an A valid name, IPv4 address, or None
address alternate name or IPv6 address.
IP address of the
remote computer.
Username username:s:value ✗ ✔ Specifies the name Any valid username. None

of the user account
that will be used to
sign in to the
remote computer.
Domain domain:s:value ✗ ✔ Specifies the name A valid domain name, such as None
of the domain in CONTOSO.
which the user
account that will
be used to sign in
to the remote
computer is
located.
RD Gateway gatewayhostname:s:value ✗ ✔ Specifies the RD A valid name, IPv4 address, or None

hostname Gateway host IPv6 address.
name.
RD Gateway gatewaycredentialssource:i:value ✗ ✔ Specifies the RD - 0: Ask for password (NTLM).

0
authentication Gateway - 1: Use smart card.
authentication - 2: Use the credentials for the

method. currently signed in user.
- 3: Prompt the user for their

credentials and use basic
authentication.
- 4: Allow user to select later.
- 5: Use cookie-based
authentication.
Desktop Services
RD Gateway gatewayprofileusagemethod:i:value ✗ ✔ Specifies whether - 0: Use the default profile mode, 0

profile to use default RD as specified by the administrator.
Gateway settings. - 1: Use explicit settings, as

specified by the user.
Use RD gatewayusagemethod:i:value ✗ ✔ Specifies when to - 0: Don't use an RD Gateway.

0
Gateway use an RD Gateway - 1: Always use an RD Gateway.
for the connection. - 2: Use an RD Gateway if a direct

connection can't be made to the
RD Session Host.
- 3: Use the default RD Gateway

settings.
- 4: Don't use an RD Gateway,

bypass gateway for local
addresses.
Setting this property value to 0 or

4 are effectively equivalent, but
setting this property to 4 enables
the option to bypass local
addresses.
Save promptcredentialonce:i:value ✗ ✔ Determines - 0: Remote session won't use the 1

credentials whether a user's same credentials.
credentials are - 1: Remote session will use the

saved and used for same credentials.
both the RD
Gateway and the
remote computer.
Server authentication level:i:value ✗ ✔ Defines the server - 0: If server authentication fails, 3

authentication authentication connect to the computer without
level settings. warning.
- 1: If server authentication fails,

don't establish a connection.
- 2: If server authentication fails,

show a warning, and choose to
connect or refuse the connection.
- 3: No authentication
requirement specified.
Connection disableconnectionsharing:i:value ✗ ✔ Determines - 0: Reconnect to any existing 0

sharing whether the client session.
reconnects to any - 1: Initiate new connection.

existing
disconnected
session or initiate a
new connection
when a new
connection is
launched.
Session behavior
Display RDP property Azure Remote Description Values Default
name Virtual Desktop value
Desktop Services
Desktop Services
Reconnection autoreconnection ✔ ✔ Determines whether the client will - 0: Client 1

enabled:i:value automatically try to reconnect to the doesn't
remote computer if the connection automatically try
is dropped, such as when there's a to reconnect.
network connectivity interruption. - 1: Client

automatically
tries to
reconnect.
Bandwidth bandwidthautodetect:i:value ✔ ✔ Determines whether or not to use - 0: Disable 1

auto detect automatic network bandwidth automatic
detection. Requires network type
bandwidthautodetect to be set to 1. detection.
- 1: Enable
automatic
network type
detection.
Network networkautodetect:i:value ✔ ✔ Determines whether automatic - 0: Don't use 1

auto detect network type detection is enabled. automatic
network
bandwidth
detection.
- 1: Use
automatic
network
bandwidth
detection.
Compression compression:i:value ✔ ✔ Determines whether bulk - 0: Disable RDP 1

compression is enabled when it's bulk
transmitted by RDP to the local compression.
computer. - 1: Enable RDP

bulk
compression.
Video videoplaybackmode:i:value ✔ ✔ Determines if the connection will use - 0: Don't use 1

playback RDP-efficient multimedia streaming RDP efficient
for video playback. multimedia
streaming for
video playback.
- 1: Use RDP-
efficient
multimedia
streaming for
video playback
when possible.
Device redirection
） Important
You can only enable redirections with binary settings that apply to both to and from the remote machine. The service
doesn't currently support one-way blocking of redirections from only one side of the connection.

Desktop Services
Desktop Services
Microphone audiocapturemode:i:value ✔ ✔ Indicates whether audio - 0: Disable audio capture 0

redirection input redirection is from the local device.
enabled. - 1: Enable audio capture

from the local device and
redirection to an audio
application in the remote
session.
Redirect encode redirected video ✔ ✔ Enables or disables - 0: Disable encoding of 1

video capture:i:value encoding of redirected redirected video.
encoding video. - 1: Enable encoding of

redirected video.
Encoded redirected video capture ✔ ✔ Controls the quality of - 0: High compression video. 0
video quality encoding quality:i:value encoded video. Quality may suffer when
there's a lot of motion.
- 1: Medium compression.
- 2: Low compression video

with high picture quality.
Audio output audiomode:i:value ✔ ✔ Determines whether the - 0: Play sounds on the local 0
location local or remote machine computer.
plays audio. - 1: Play sounds on the

remote computer.
- 2: Don't play sounds.
Camera camerastoredirect:s:value ✔ ✔ Configures which - *: Redirect all cameras.

Don't
redirection cameras to redirect. This - List of cameras, such as \\? redirect
setting uses a \usb#vid_0bda&pid_58b0&mi .
any
semicolon-delimited list - You can exclude a specific cameras.
of camera by prepending the
KSCATEGORY_VIDEO_CAMERA symbolic link string with "-".
interfaces of cameras
enabled for redirection.
Media devicestoredirect:s:value ✔ ✔ Determines which - *: Redirect all supported Don't

Transfer devices on the local devices, including ones that redirect
Protocol computer will be are connected later.
any
(MTP) and redirected and available - Valid hardware ID for one or devices.
Picture in the remote session. more devices.
Transfer - DynamicDevices: Redirect all

Protocol supported devices that are
(PTP) connected later.
Drive/storage drivestoredirect:s:value ✔ ✔ Determines which disk - No value specified: don't Don't

redirection drives on the local redirect any drives.
redirect
computer will be - *: Redirect all disk drives, any
redirected and available including drives that are drives.
in the remote session. connected later.
- DynamicDrives: redirect any

drives that are connected
later.
- The drive and labels for one

or more drives, such as
drivestoredirect:s:C\:;E\:; ,
redirect the specified drive(s).
Desktop Services
Windows key keyboardhook:i:value ✔ ✔ Determines when - 0: Windows key 2

combinations Windows key combinations are applied on
combinations ( Windows , the local computer.
Alt + Tab ) are applied - 1: (Desktop only) Windows

to the remote session for key combinations are applied
desktop and RemoteApp on the remote computer
connections. when in focus.
- 2: (Desktop only) Windows

key combinations are applied
on the remote computer in
full screen mode only.
- 3: (RemoteApp only)
Windows key combinations
are applied on the
RemoteApp when in focus.
We recommend you use this
value only when publishing
the Remote Desktop
Connection app ( mstsc.exe )
from the host pool on Azure
Virtual Desktop. This value is
only supported when using
the Windows client.
Clipboard redirectclipboard:i:value ✔ ✔ Determines whether - 0: Clipboard on local 1

redirection clipboard redirection is computer isn't available in
enabled. remote session.
- 1: Clipboard on local
computer is available in
remote session.
COM ports redirectcomports:i:value ✔ ✔ Determines whether - 0: COM ports on the local 0

redirection COM (serial) ports on the computer aren't available in
local computer will be the remote session.
redirected and available - 1: COM ports on the local

in the remote session. computer are available in the
remote session.
Location redirectlocation:i:value ✔ ✔ Determines whether the - 0: The remote session uses 0

service location of the local the location of the remote
redirection device will be redirected computer or virtual machine.
and available in the - 1: The remote session uses

remote session. the location of the local
device.
Printer redirectprinters:i:value ✔ ✔ Determines whether - 0: The printers on the local 1

redirection printers configured on computer aren't available in
the local computer will the remote session.
be redirected and - 1: The printers on the local

available in the remote computer are available in the
session. remote session.
Smart card redirectsmartcards:i:value ✔ ✔ Determines whether - 0: The smart card device on 1

redirection smart card devices on the local computer isn't
the local computer will available in the remote
be redirected and session.
available in the remote - 1: The smart card device on

session. the local computer is
available in the remote
session.
Desktop Services
WebAuthn redirectwebauthn:i:value ✔ ✔ Determines whether - 0: WebAuthn requests from 1

redirection WebAuthn requests on the remote session aren't
the remote computer sent to the local computer for
will be redirected to the authentication and must be
local computer allowing completed in the remote
the use of local session.
authenticators (such as - 1: WebAuthn requests from

Windows Hello for the remote session are sent
Business and security to the local computer for
key). authentication.
USB device usbdevicestoredirect:s:value ✔ ✔ Determines which - *: Redirect all USB devices Don't
redirection supported RemoteFX that aren't already redirected redirect
USB devices on the client by another high-level any USB
computer will be redirection.
devices.
redirected and available - {Device Setup Class GUID}:
in the remote session Redirect all devices that are
when you connect to a members of the specified
remote session that device setup class.
supports RemoteFX USB - USBInstanceID: Redirect a

redirection. specific USB device identified
by the instance ID.
Display settings
Desktop Services
Multiple use multimon:i:value ✔ ✔ Determines whether the - 0: Don't enable 0

displays remote session will use multiple display
one or multiple displays support.
from the local - 1: Enable multiple

computer. display support.
Selected selectedmonitors:s:value ✔ ✔ Specifies which local Comma separated list All

monitors displays to use from the of machine-specific displays.
remote session. The display IDs. You can
selected displays must retrieve IDs by calling
be contiguous. Requires mstsc.exe /l . The first
use multimon to be set ID listed will be set as
to 1.
the primary display in
the session.
Only available on the
Windows Inbox (MSTSC)
and Windows Desktop
(MSRDC) clients.
Maximize maximizetocurrentdisplays:i:value ✔ ✔ Determines which - 0: Session goes full 0

to current display the remote screen on the displays
displays session goes full screen initially selected when
on when maximizing. maximizing.
Requires use multimon - 1: Session dynamically

to be set to 1.
goes full screen on the
displays touched by the
Only available on the session window when
Windows Desktop maximizing.
(MSRDC) client.
Desktop Services
Multi to singlemoninwindowedmode:i:value ✔ ✔ Determines whether a - 0: Session retains all 0

single multi display remote displays when exiting
display session automatically full screen.
switch switches to single - 1: Session switches to

display when exiting full single display when
screen. Requires use exiting full screen.
multimon to be set to 1.
Only available on the

Windows Desktop
(MSRDC) client.
Screen screen mode id:i:value ✔ ✔ Determines whether the - 1: The remote session 2
mode remote session window will appear in a
appears full screen window.
when you launch the - 2: The remote session

connection. will appear full screen.
Smart smart sizing:i:value ✔ ✔ Determines whether or - 0: The local window 0

sizing not the local computer content won't scale
scales the content of when resized.
the remote session to fit - 1: The local window

the window size. content will scale when
resized.
Dynamic dynamic resolution:i:value ✔ ✔ Determines whether the - 0: Session resolution 1

resolution resolution of the remote remains static during
session is automatically the session.
updated when the local - 1: Session resolution

window is resized. updates as the local
window resizes.
Desktop desktop size id:i:value ✔ ✔ Specifies the - 0: 640×480

Match the
size dimensions of the - 1: 800×600
local
remote session desktop - 2: 1024×768
computer.
from a set of predefined - 3: 1280×1024
options. This setting is - 4: 1600×1200

overridden if
desktopheight and
desktopwidth are
specified.
Desktop desktopheight:i:value ✔ ✔ Specifies the resolution Numerical value Match the

height height (in pixels) of the between 200 and 8192. local
remote session. computer.
Desktop desktopwidth:i:value ✔ ✔ Specifies the resolution Numerical value Match the

width width (in pixels) of the between 200 and 8192. local
remote session. computer.
Desktop desktopscalefactor:i:value ✔ ✔ Specifies the scale Numerical value from Match the
scale factor of the remote the following list:
local
factor session to make the - 100
computer.
content appear larger. - 125
- 150
- 175
- 200
- 250
- 300
- 400
- 500.
RemoteApp
Desktop Services
Command-line remoteapplicationcmdline:s:value ✗ ✔ Optional command- Valid N/A

parameters line parameters for the command-
RemoteApp. line
parameters.
Command-line remoteapplicationexpandcmdline:i:value ✗ ✔ Determines whether - 0: 1

variables environment variables Environment
contained in the variables
RemoteApp should be
command-line expanded to
parameter should be the values of
expanded locally or the local
remotely. computer.
- 1:
Environment
variables
should be
expanded to
the values of
the remote
computer.
Working remoteapplicationexpandworkingdir:i:value ✗ ✔ Determines whether - 0: 1

directory environment variables Environment
variables contained in the variables
RemoteApp working should be
directory parameter expanded to
should be expanded the values of
locally or remotely. the local
computer.
- 1:
Environment
variables
should be
expanded to
the values of
the remote
computer.
The
RemoteApp
working
directory is
specified
through the
shell working
directory
parameter.
Open file remoteapplicationfile:s:value ✗ ✔ Specifies a file to be Valid file N/A

opened on the remote path.
computer by the
RemoteApp.
For local files to be

opened, you must also
enable drive
redirection for the
source drive.
Desktop Services
Icon file remoteapplicationicon:s:value ✗ ✔ Specifies the icon file Valid file N/A
to be displayed in the path.
client UI while
launching a
RemoteApp. If no file
name is specified, the
client will use the
standard Remote
Desktop icon. Only
.ico files are
supported.
Application remoteapplicationmode:i:value ✗ ✔ Determines whether a - 0: Don't 1

mode connection is launch a
launched as a RemoteApp
RemoteApp session. session.
- 1: Launch a
RemoteApp
session.
Application remoteapplicationname:s:value ✗ ✔ Specifies the name of App display N/A

display name the RemoteApp in the name. For
client interface while example,
starting the Excel 2016.
RemoteApp.
Alias/executable remoteapplicationprogram:s:value ✗ ✔ Specifies the alias or Valid alias or N/A

name executable name of name. For
the RemoteApp. example,
EXCEL.
Uniform Resource Identifier schemes
with the Remote Desktop client for
Azure Virtual Desktop (preview)
） Important
The ms-avd Uniform Resource Identifier scheme for Azure Virtual Desktop is
currently in PREVIEW.
See the Supplemental Terms of Use for Microsoft Azure
You can use Uniform Resource Identifier (URI) schemes to invoke the Remote Desktop
client with specific commands, parameters, and values for use with Azure Virtual
Desktop. For example, you can subscribe to a workspace or connect to a particular
desktop or Remote App.
This article details the available commands and parameters, along with some examples.
Supported clients
The following table lists the supported clients for use with the URI schemes:
Client Version
Remote Desktop client for Windows 1.2.4065 and later
Available URI schemes

There are two URI schemes for supported Remote Desktop clients, ms-avd and ms-rd.
With ms-avd, you can specify a particular Azure Virtual Desktop resource and user with
which to connect. With ms-rd, you can automatically subscribe to a workspace in the
Remote Desktop client, rather than having to manually add the workspace.
The following sections detail the commands and parameters you can use with each URI
scheme.
ms-avd
Here's the list of currently supported commands for ms-avd and their corresponding
parameters.
ms-avd:connect
ms-avd:connect locates a specified Azure Virtual Desktop resource and initiates the RDP
session, directly connecting a specified user to that resource.
） Important
The ms-avd:connect command is currently in preview and shouldn't be used in

production.
Command name: connect
Command parameters:
Parameter Values Description
workspaceid Object ID (GUID). Specify the object ID of a valid workspace.
To get the object ID value using PowerShell, see Retrieve

the object ID of a host pool, workspace, application group,
or application. You can also use Desktop Virtualization
REST APIs.
resourceid Object ID (GUID). Specify the object ID of a published resource contained in

the workspace. The value can be for a desktop or Remote
App.
To get the object ID value using PowerShell, see Retrieve

the object ID of a host pool, workspace, application group,
or application. You can also use Desktop Virtualization
REST APIs.
user User Principal Specify a valid user with access to specified resource.
Name (UPN), for
example
user@contoso.com .
env (optional) avdarm Specify the Azure cloud where resources are located.
(commercial
Azure)
avdgov (Azure
Government)
version 0 Specify the version of the connect URI scheme to use.
launchpartnerid GUID. Specify the partner or customer-provided ID that you can

(optional) use with Azure Virtual Desktop Diagnostics to help with
troubleshooting. We recommend using a GUID, which you
can generate with the New-Guid PowerShell cmdlet.
peeractivityid GUID. Specify the partner or customer-provided ID that you can

(optional) use with Azure Virtual Desktop Diagnostics to help with
troubleshooting. We recommend using a GUID, which you
can generate with the New-Guid PowerShell cmdlet.
Example:
ms-avd:connect?workspaceId=1638e073-63b2-46d8-bd84-
ea02ea905467&resourceid=c2f5facc-196f-46af-991e-
a90f3252c185&username=user@contoso.com&version=0
ms-rd
Here's the list of currently supported commands for ms-rd and their corresponding
parameters.
 Tip
Using ms-rd: without any commands launches the Remote Desktop client.
ms-rd:subscribe
ms-rd:subscribe launches the Remote Desktop client and starts the subscription
process.
Command name: subscribe
Command parameters:
url A valid URL, such as https://rdweb.wvd.microsoft.com . Specify a workspace URL.

Example:
ms-rd:subscribe?url=https://rdweb.wvd.microsoft.com
Known Limitations
Here are known limitations with the URI schemes:
Display properties cannot be configured via URI. You can configure display
properties as an admin on a host pool or end users can configure display
properties in the Azure Virtual Desktop client.
Next steps
Learn how to Connect to Azure Virtual Desktop with the Remote Desktop client for
Windows.
Understanding multimedia redirection
for Azure Virtual Desktop
Multimedia redirection (MMR) gives you smooth video playback while watching videos
in a browser in Azure Virtual Desktop. Multimedia redirection redirects the media
content from Azure Virtual Desktop to your local machine for faster processing and
rendering. Both Microsoft Edge and Google Chrome support this feature.
７ Note
Multimedia redirection isn't supported on Azure Virtual Desktop for Microsoft 365
Government (GCC), GCC-High environments, and Microsoft 365 DoD.
Multimedia redirection on Azure Virtual Desktop is only available for the Windows
Desktop client, version 1.2.3916 or later. on Windows 11, Windows 10, or Windows
10 IoT Enterprise devices.
Websites that work with multimedia redirection

The following list shows websites that are known to work with MMR. MMR works with
these sites by default.
AnyClip
AWS Training
BBC
Big Think
Bleacher Report
Brightcove
CNBC
Coursera
Daily Mail
Facebook
Fidelity
Flashtalking
Fox Sports
Fox Weather
IMDB
Infosec Institute
LinkedIn Learning
Microsoft Learn
Microsoft Stream
NBC Sports
The New York Times
Pluralsight
Politico
Reddit
Reuters
Skillshare
The Guardian
Twitch
Twitter
Udemy
UMU
U.S. News
Vidazoo
Vimeo
The Wall Street Journal
Yahoo
Yammer
YouTube (including sites with embedded YouTube videos).
Microsoft Teams live events aren't media-optimized for Azure Virtual Desktop and
Windows 365 when using the native Teams app. However, if you use Teams live events
with a supported browser, MMR is a workaround that provides smoother Teams live
events playback on Azure Virtual Desktop. MMR supports Enterprise Content Delivery
Network (ECDN) for Teams live events.
The multimedia redirection status icon

To quickly tell if multimedia redirection is active in your browser, we've added the
following icon states:
Icon Definition
State
A greyed out icon means that multimedia content on the website can't be redirected or
the extension isn't loading.
The red square with an "X" inside of it means that the client can't connect to multimedia
redirection. You may need to uninstall and reinstall the extension, then try again.
Icon Definition
State
The default icon appearance with no status applied. This icon state means that multimedia
content on the website can be redirected and is ready to use.
The green square with a play button icon inside of it means that the extension is currently
redirecting video playback.
The green square with a phone icon inside of it means that the extension is currently
redirecting a WebRTC call.
Selecting the icon in your browser will display a pop-up menu where it lists the features
supported on the current page, you can select to enable or disable multimedia
redirection on all websites, and collect logs. It also lists the version numbers for each
component of the service.
You can use the icon to check the status of the extension by following the directions in
Check the extension status.
Next steps
To learn how to use this feature, see Multimedia redirection for Azure Virtual Desktop.
To troubleshoot issues or view known issues, see our troubleshooting article.
If you're interested in video streaming on other parts of Azure Virtual Desktop, check
out Teams for Azure Virtual Desktop.
 Documentation
Azure Advisor Azure Virtual Desktop Walkthrough - Azure

How to resolve Azure Advisor recommendations for Azure Virtual Desktop.
Collect and query Azure Virtual Desktop connection quality data (preview) - Azure
How to set up and query the connection quality data table for Azure Virtual Desktop to diagnose
connection issues.




examples.
Show 5 more
 Training
Printing on Azure Virtual Desktop using
Universal Print
７ Note
The improvements described in this article apply to Windows 11 multi-session

22H2 and later.
Windows 10 users and users on older Windows 11 versions will still
experience the issues described in the Universal Print Known Issues article here.
Experience improvements
The improvements made in Windows 11 22H2 address user experience issues on Azure
Virtual Desktop.
There are 3 major improvements to the print scenario
Printers are installed as part of the user profile

Instead of printers being installed as a machine-wide resource (i.e., all installed printers
are visible to all users who sign in to the VM), each user sees only the printers they
install.
Printers roam with user profiles

When user profiles are configured to roam (e.g. using FSLogix), printers that the user
installs on one VM will be automatically installed on other VMs the user signs into. This
behavior also works when users remove printers from their profile.
Location-based printer search the local device location

Instead of finding printers close to the location of the VM where the user is signed in,
location-based printer search will find printers based on the device the user is
connecting from. This requires the location override functionality to be enabled.
Relevant information and caveats
Location override configuration

To enable location-based printer search using the AVD client location, location services
must be configured on all VMs as follows:
1. Open the Settings app in Windows and go to Privacy & security.

2. In the App permissions section, click Location.
3. Enable Location services.
4. Enable Allow location override.
Printer redirection
Printer redirection affects whether the printers installed on the PC the user is connecting
from will be available in the remote session.
While there is no recommended setting,
this configuration affects the printers that will be available to the user in the remote
session. Therefore, the admin should decide what the correct configuration is for their
users.
Configure printer redirection
1. Go to https://portal.azure.com
2. Under Azure services, click Azure Virtual Desktop.
3. Click on Host pools and click on the host pool you would like to configure.
4. On the host pool configuration page, click on RDP Properties, then click on Device
redirection.
5. Choose your preferred printer redirection setting.
７ Note
Printer redirection affects the default printer behavior.

When you choose to have
printers on the local computer be available in the remote session, the default
printer on the local computer will become the default printer in the remote session.
Printing preferences and printer properties

Printing preferences are the options the user chooses every time they print. Depending
on what the printer supports, this could be things like paper size, stapling, color vs.
greyscale, etc.
When a user sets their printing preferences defaults, these user
preferences roam with the user across different sessions hosts.
Printer properties are the configuration of a printer on a particular PC. These are things
like the printer driver, the ports where the printer is installed on this PC, and other
printer settings.
This configuration is machine-specific, and does not roam with the user
across session hosts.
Known issues
Removing a printer while multiple users are signed in

When a user removes a printer, that printer gets removed from other users who
installed it, if they are signed in to the same VM as the user who removed that printer.
See also
Universal Print discussions on the Microsoft Tech Community at
https://aka.ms/UPDiscussion .
Estimate Azure Virtual Desktop
monitoring costs
Azure Virtual Desktop uses the Azure Monitor Logs service to collect, index, and store
data generated by your environment. Because of this, the Azure Monitor pricing model
is based on the amount of data that's brought into and processed (or "ingested") by
your Log Analytics workspace in gigabytes per day. The cost of a Log Analytics
workspace isn't only based on the volume of data collected, but also which Azure
payment plan you've selected and how long you choose to store the data your
environment generates.
This article will explain the following things to help you understand how pricing in Azure
Monitor works:
How to estimate data ingestion and storage costs upfront before you enable this
feature
How to measure and control your ingestion and storage to reduce costs when
using this feature
７ Note
All sizes and pricing listed in this article are just examples to demonstrate how
estimation works. For a more accurate assessment based on your Azure Monitor
Log Analytics pricing model and Azure region, see Azure Monitor pricing .
Estimate data ingestion and storage costs

We recommend you use a predefined set of data written as logs in your Log Analytics
workspace. In the following example estimates, we'll look at billable data in the default
configuration
The predefined datasets for Azure Virtual Desktop Insights include:
Performance counters from the session hosts

Windows Event Logs from the session hosts
Azure Virtual Desktop diagnostics from the service infrastructure
Your data ingestion and storage costs depend on your environment size, health, and
usage. The example estimates we'll use in this article to calculate the cost ranges you
can expect are based on healthy virtual machines running light to power usage, based
on our virtual machine sizing guidelines, to calculate a range of data ingestion and
storage costs you could expect.
The light usage VM we'll be using in our example includes the following components:
4 vCPUs, 1 disk
16 sessions per day
An average session duration of 2 hours (120 minutes)
100 processes per session
The power usage VM we'll be using in our example includes the following components:
6 vCPUs, 1 disk
6 sessions per day
Average session duration of 4 hours (240 minutes)
200 processes per session
Estimating performance counter ingestion

Performance counters show how the system resources are performing. Performance
counter data ingestion depends on your environment size and usage. In most cases,
performance counters should make up 80 to 99% of your data ingestion for Azure
Virtual Desktop Insights.
Before you start estimating, it’s important that you understand that each performance
counter sends data at a specific frequency. We set a default sample rate-per-minute
(you can also edit this rate in your settings), but that rate will be applied at different
multiplying factors depending on the counter. The following factors affect the rate:
For the per virtual machine (VM) factor, each counter sends data per VM in your
environment at the default sample rate per minute while the VM is running. You
can estimate the number of records these counters send per day by multiplying
the default sample rate per minute by the number of VMs in your environment,
then multiplying that number by the average VM running time per day.
To summarize:
Default sample rate per minute × number of CPU cores in the VM SKU × number
of VMs × average VM running time per day = number of records sent per day
For the per CPU factor, each counter sends at the default sample rate per minute
per vCPU in each VM in your environment while the VM is running. You can
estimate the number of records the counters will send per day by multiplying the
default sample rate per minute by the number of CPU cores in the VM SKU, then
multiplying that number by the number of minutes the VM runs and the number
of VMs in your environment.
To summarize:
Default sample rate per minute × number of CPU cores in the VM SKU × number
of minutes the VM runs × number of VMs = number of records sent per day
For the per disk factor, each counter sends data at the default sample rate for each
disk in each VM in your environment. The number of records these counters will
send per day equals the default sample rate per minute multiplied by number of
disks in the VM SKU, multiplied by 60 minutes per hour, and finally multiplied by
the average active hours for a VM.
To summarize:
Default sample rate per minute × number of disks in VM SKU × 60 minutes per
hour × number of VMs × average VM running time per day = number of records
sent per day
For the per session factor, each counter sends data at the default sample rate for
each session in your environment while the session is connected. You can estimate
the number of records these counters will send per day can by multiplying the
default sample rate per minute by the average number of sessions per day and the
average session duration.
To summarize:
Default sample rate per minute × sessions per day × average session duration =
number of records sent per day
For the per-process factor, each counter sends data at the default rate for each
process in each session in your environment. You can estimate the number of
records these counters will send per day by multiplying the default sample rate per
minute by the average number of sessions per day, then multiplying that by the
average session duration and the average number of processes per session.
To summarize:
Default sample rate per minute × sessions per day × average session duration ×
average number of processes per session = number of records sent per day
The following table lists the 20 performance counters Azure Virtual Desktop Insights
collects and their default rates:
Counter name Default sample rate Frequency factor
Logical Disk(C:)\% free space 60 seconds Per disk
Logical Disk(C:)\Avg. Disk Queue Length 30 seconds Per disk
Logical Disk(C:)\Avg. Disk sec/Transfer 60 seconds Per disk
Logical Disk(C:)\Current Disk Queue Length 30 seconds Per disk
Memory(*)\Available Mbytes 30 seconds Per VM
Memory(*)\Page Faults/sec 30 seconds Per VM
Memory(*)\Pages/sec 30 seconds Per VM
Memory(*)\% Committed Bytes in Use 30 seconds Per VM
PhysicalDisk(*)\Avg. Disk Queue Length 30 seconds Per disk
PhysicalDisk(*)\Avg. Disk sec/Read 30 seconds Per disk
PhysicalDisk(*)\Avg. Disk sec/Transfer 30 seconds Per disk
PhysicalDisk(*)\Avg. Disk sec/Write 30 seconds Per disk
Processor Information(_Total)\% Processor Time 30 seconds Per core/CPU
Terminal Services(*)\Active Sessions 60 seconds Per VM
Terminal Services(*)\Inactive Sessions 60 seconds Per VM
Terminal Services(*)\Total Sessions 60 seconds Per VM
User Input Delay per Process(*)\Max Input Delay 30 seconds Per process
User Input Delay per Session(*)\Max Input Delay 30 seconds Per session
RemoteFX Network(*)\Current TCP RTT 30 seconds Per VM
RemoteFX Network(*)\Current UDP Bandwidth 30 seconds Per VM
If we estimate each record size to be 200 bytes, an example VM running a light

workload on the default sample rate would send roughly 90 megabytes of performance
counter data per day per VM. Meanwhile, an example VM running a power workload
would send roughly 130 megabytes of performance counter data per day per VM.
However, record size and environment usage can vary, so the megabytes per day your
deployment uses may be different.
To learn more about input delay performance counters, see User Input Delay
performance counters.
Estimating Windows Event Log ingestion
Windows Event Logs are data sources collected by Log Analytics agents on Windows
virtual machines. You can collect events from standard logs like System and Application
as well as custom logs created by applications you need to monitor.
These are the default Windows Events for Azure Virtual Desktop Insights:
Application
Microsoft-Windows-TerminalServices-RemoteConnectionManager/Admin
Microsoft-Windows-TerminalServices-LocalSessionManager/Operational
System
Microsoft-FSLogix-Apps/Operational
Microsoft-FSLogix-Apps/Admin
Windows Events send whenever the terms of the event are met in the environment.
Machines in healthy states will send fewer events than machines in unhealthy states.
Since event count is unpredictable, we use a range of 1,000 to 10,000 events per VM per
day based on examples from healthy environments for this estimate. For example, if we
estimate each event record size in this example to be 1,500 bytes, this comes out to
roughly 2 to 15 megabytes of event data per day for the specified environment.
To learn more about Windows events, see Windows event records properties.
Estimating diagnostics ingestion

The diagnostics service creates activity logs for both user and administrative actions.
These are the names of the activity logs the diagnostic counter tracks:
WVDCheckpoints
WVDConnections
WVDErrors
WVDFeeds
WVDManagement
WVDAgentHealthStatus
The service sends diagnostic information whenever the environment meets the terms
required to make a record. Since diagnostic record count is unpredictable, we use a
range of 500 to 1000 events per VM per day based on examples from healthy
environments for this estimate.
For example, if we estimate each diagnostic record size in this example to be 200 bytes,
then the total ingested data would be less than 1 MB per VM per day.
To learn more about the activity log categories, see Azure Virtual Desktop diagnostics.
Estimating total costs

Finally, let's estimate the total cost. In this example, let's say we come up with the
following results based on the example values in the previous sections:
Data source Size estimate per day (in megabytes)
Performance counters 90-130
Events 2-15
Azure Virtual Desktop diagnostics <1
In this example, the total ingested data for Azure Virtual Desktop Insights is between 92
to 145 megabytes per VM per day. In other words, every 31 days, each VM ingests
roughly 3 to 5 gigabytes of data.
Using the default Pay-as-you-go model for Log Analytics pricing , you can estimate the
Azure Monitor data collection and storage cost per month. Depending on your data
ingestion, you may also consider the Capacity Reservation model for Log Analytics
pricing.
Manage your data ingestion to reduce costs

This section will explain how to measure and manage data ingestion to reduce costs.
To learn about managing rights and permissions to the workbook, see Access control.
７ Note
Removing data points will impact their corresponding visuals in Azure Virtual
Desktop Insights.
Log Analytics settings

Here are some suggestions to optimize your Log Analytics settings to manage data
ingestion:
Use a designated Log Analytics workspace for your Azure Virtual Desktop
resources to ensure that Log Analytics only collects performance counters and
events for the virtual machines in your Azure Virtual Desktop deployment.
Adjust your Log Analytics storage settings to manage costs. You can reduce the
retention period, evaluate whether a fixed storage pricing tier would be more cost-
effective, or set boundaries on how much data you can ingest to limit impact of an
unhealthy deployment. To learn more, see Azure Monitor Logs pricing details.
Remove excess data

Our default configuration is the only set of data we recommend for Azure Virtual
Desktop Insights. You always have the option to add additional data points and view
them in the Host Diagnostics: Host browser or build custom charts for them, however
added data will increase your Log Analytics cost. These can be removed for cost savings.
Measure and manage your performance counter data

Your true monitoring costs will depend on your environment size, usage, and health. To
understand how to measure data ingestion in your Log Analytics workspace, see Analyze
usage in Log Analytics workspace.
The performance counters the session hosts use will probably be your largest source of
ingested data for Azure Virtual Desktop Insights. The following custom query template
for a Log Analytics workspace can track frequency and megabytes ingested per
performance counter over the last day:
azure
let WVDHosts = dynamic(['Host1.MyCompany.com', 'Host2.MyCompany.com']);
Perf
| where TimeGenerated > ago(1d)
| where Computer in (WVDHosts)
| extend PerfCounter = strcat(ObjectName, ":", CounterName)
| summarize Records = count(TimeGenerated), InstanceNames =

dcount(InstanceName), Bytes=sum(_BilledSize) by PerfCounter
| extend Billed_MBytes = Bytes / (1024 * 1024), BytesPerRecord = Bytes /

Records
| sort by Records desc
７ Note
Make sure to replace the template's placeholder values with the values your
environment uses, otherwise the query won't work.
This query will show all performance counters you have enabled on the environment,
not just the default ones for Azure Virtual Desktop Insights. This information can help
you understand which areas to target to reduce costs, like reducing a counter’s
frequency or removing it altogether.
You can also reduce costs by removing performance counters. To learn how to remove
performance counters or edit existing counters to reduce their frequency, see
Configuring performance counters.
Manage Windows Event Logs

Windows Events are unlikely to cause a spike in data ingestion when all hosts are
healthy. An unhealthy host can increase the number of events sent to the log, but the
information can be critical to fixing the host's issues. We recommend keeping them. To
learn more about how to manage Windows Event Logs, see Configuring Windows Event
logs.
Manage diagnostics
Azure Virtual Desktop diagnostics should make up less than 1% of your data storage
costs, so we don't recommend removing them. To manage Azure Virtual Desktop
diagnostics, Use Log Analytics for the diagnostics feature.
Next steps
Learn more about Azure Virtual Desktop Insights at these articles:
Use Azure Virtual Desktop Insights to monitor your deployment.

Use the glossary to learn more about terms and concepts.
If you encounter a problem, check out our troubleshooting guide for help.
Check out Monitoring usage and estimated costs in Azure Monitor to learn more
about managing your monitoring costs.
 Documentation


Set up diagnostics for monitoring agent updates

How to set up diagnostic reports to monitor agent updates.
Scale session hosts using Azure Automation and Azure Logic Apps for Azure Virtual
Desktop - Azure
Learn about scaling Azure Virtual Desktop session hosts with Azure Automation and Azure Logic
Apps.


Show 5 more
Azure Virtual Desktop Insights glossary
This article lists and briefly describes key terms and concepts related to Azure Virtual
Desktop Insights.
Alerts
Any active Azure Monitor alerts that you've configured on the subscription and
classified as severity 0 will appear in the Overview page. To learn how to set up alerts,
see Azure Monitor Log Alerts.
Available sessions
Available sessions shows the number of available sessions in the host pool. The service
calculates this number by multiplying the number of virtual machines (VMs) by the
maximum number of sessions allowed per virtual machine, then subtracting the total
sessions.
Client operating system (OS)

The client operating system (OS) shows which version of the OS end-users accessing
Azure Virtual Desktop resources are currently using. The client OS also shows which
version of the web (HTML) client and the full Remote Desktop client the users have. For
a full list of Windows OS versions, see Operating System Version.
Connection success
This item shows connection health. "Connection success" means that the connection
could reach the host, as confirmed by the stack on that virtual machine. A failed
connection means that the connection couldn't reach the host.
Daily active users (DAU)

The total number of users that have started a session in the last 24 hours.
Daily alerts
The total number of alerts triggered each day.
Daily connections and reconnections

The total number of connections and reconnections started or completed within the last
24 hours.
Daily connected hours

The total number of hours spent connected to a session across users in the last 24
hours.
Diagnostics and errors

When an error or alert appears in Azure Virtual Desktop Insights, it's categorized by
three things:
Activity type: this category is how the error is categorized by Azure Virtual Desktop
diagnostics. The categories are management activities, feeds, connections, host
registrations, errors, and checkpoints. Learn more about these categories at Use
Log Analytics for the diagnostics feature.
Kind: this category shows the error's location.

Errors marked as "service" or "ServiceError = TRUE" happened in the Azure
Virtual Desktop service.
Errors marked as "deployment" or tagged "ServiceError = FALSE" happened
outside of the Azure Virtual Desktop service.
To learn more about the ServiceError tag, see Common error scenarios.
Source: this category gives a more specific description of where the error
happened.
Diagnostics: the service role responsible for monitoring and reporting service
activity to let users observe and diagnose deployment issues.
RDBroker: the service role responsible for orchestrating deployment activities,

maintaining the state of objects, validating authentication, and more.
RDGateway: the service role responsible for handling network connectivity

between end-users and virtual machines.
RDStack: a software component that's installed on your VMs to allow them to
communicate with the Azure Virtual Desktop service.
Client: software running on the end-user machine that provides the interface to
the Azure Virtual Desktop service. It displays the list of published resources and
hosts the Remote Desktop connection once you've made a selection.
Each diagnostics issue or error includes a message that explains what went wrong. To
learn more about troubleshooting errors, see Identify and diagnose Azure Virtual
Desktop issues.
Input delay
"Input delay" in Azure Virtual Desktop Insights means the input delay per process
performance counter for each session. In the host performance page at
aka.ms/azmonwvdi , this performance counter is configured to send a report to the
service once every 30 seconds. These 30-second intervals are called "samples," and the
report the worst case in that window. The median and p95 values reflect the median and
95th percentile across all samples.
Under Input delay by host, you can select a session host row to filter all other visuals in
the page to that host. You can also select a process name to filter the median input
delay over time chart.
We put delays in the following categories:
Good: below 150 milliseconds.

Acceptable: 150-500 milliseconds.
Poor: 500-2,000 milliseconds (below 2 seconds).
Bad: over 2,000 milliseconds (2 seconds and up).
To learn more about how the input delay counter works, see User Input Delay
Monthly active users (MAU)

The total number of users that have started a session in the last 28 days. If you store
data for 30 days or less, you may see lower-than-expected MAU and Connection values
during periods where you have fewer than 28 days of data available.
Performance counters
Performance counters show the performance of hardware components, operating
systems, and applications.
The following table lists the recommended performance counters and time intervals that
Azure Monitor uses for Azure Virtual Desktop:
Performance counter name Time interval
Logical Disk(C:)\Avg. Disk Queue Length 30 seconds
Logical Disk(C:)\Avg. Disk sec/Transfer 60 seconds
Logical Disk(C:)\Current Disk Queue Length 30 seconds
Memory(*)\Available Mbytes 30 seconds
Memory(*)\Page Faults/sec 30 seconds
Memory(*)\Pages/sec 30 seconds
Memory(*)\% Committed Bytes in Use 30 seconds
PhysicalDisk(*)\Avg. Disk Queue Length 30 seconds
PhysicalDisk(*)\Avg. Disk sec/Read 30 seconds
PhysicalDisk(*)\Avg. Disk sec/Transfer 30 seconds
PhysicalDisk(*)\Avg. Disk sec/Write 30 seconds
Processor Information(_Total)\% Processor Time 30 seconds
Terminal Services(*)\Active Sessions 60 seconds
Terminal Services(*)\Inactive Sessions 60 seconds
Terminal Services(*)\Total Sessions 60 seconds
*User Input Delay per Process(*)\Max Input Delay 30 seconds
*User Input Delay per Session(*)\Max Input Delay 30 seconds
RemoteFX Network(*)\Current TCP RTT 30 seconds
RemoteFX Network(*)\Current UDP Bandwidth 30 seconds
To learn more about how to read performance counters, see Configuring performance
counters.
To learn more about input delay performance counters, see User Input Delay
Potential connectivity issues
Potential connectivity issues shows the hosts, users, published resources, and clients
with a high connection failure rate. Once you choose a "report by" filter, you can
evaluate the issue's severity by checking the values in these columns:
Attempts (number of connection attempts)

Resources (number of published apps or desktops)
Hosts (number of VMs)
Clients
For example, if you select the By user filter, you can check to see each user's connection
attempts in the Attempts column.
If you notice that a connection issue spans multiple hosts, users, resources, or clients, it's
likely that the issue affects the whole system. If it doesn't, it's a smaller issue that lower
priority.
You can also select entries to view additional information. You can view which hosts,
resources, and client versions were involved with the issue. The display will also show
any errors reported during the connection attempts.
Round-trip time (RTT)

Round-trip time (RTT) is an estimate of the connection's round-trip time between the
end-user’s location and the session host's Azure region. To see which locations have the
best latency, look up your desired location in the Azure Virtual Desktop Experience
Estimator tool .
Session history
The Sessions item shows the status of all sessions, connected and disconnected. Idle
sessions only shows the disconnected sessions.
Severity 0 alerts
The most urgent items that you need to take care of right away. If you don't address
these issues, they could cause your Azure Virtual Desktop deployment to stop working.
Time to connect
Time to connect is the time between when a user opens a resource to start their session
and when their desktop has loaded and is ready to use. For example, for RemoteApps,
this is the time it takes to launch the application.
Time to connect has two stages:
Connection, which is how long it takes for the Azure service to route the user to a
session host.
"Logon," which is how long it takes for the service to perform tasks related to
signing in the user and establishing the session on the session host.
When monitoring time to connect, keep in mind the following things:
Time to connect is measured with the following checkpoints from Azure Virtual
Desktop service diagnostics data. The checkpoints Insights uses to determine when
the connection is established are different for a desktop versus a remote
application scenario.
Begins: WVDConnection state = started
Ends: WVDCheckpoints Name = ShellReady (desktops); Name =

RdpShellAppExecuted (RemoteApp. For timing, consider the first app launch
only)
For example, Insights measures the time for a desktop experience to launch based on
how long it takes to launch Windows Explorer. Insights also measures the time for a
remote application to launch based on the time taken to launch the first instance of the
shell app for a connection.
７ Note
If a user launches more than one remote application, sometimes the shell app can
execute multiple times during a single connection. For an accurate measurement of
time to connect, you should only use the first execution checkpoint for each
connection.
Establishing new sessions usually takes longer than reestablishing connections to

existing sessions due to differences in the "logon" process for new and established
connections.
The time it takes for the user to provide credentials is subtracted from their time to
connect to account for situations where a user either takes a while to enter
credentials or use alternative authentication methods to sign in.
When troubleshooting a high time to connect, Azure Monitor will break down total
connection time data into four components to help you identify how to reduce sign-in
time.
７ Note
The components in this section only show the primary connection stages. These
components can run in parallel, which means they won't add up to equal the total
time to connect. The total time to connect is a measurement that Azure Monitor
determines in a separate process.
The following flowchart shows the four stages of the sign-in process:
The flowchart shows the following four components:
User route: the time it takes from when the user selects the Azure Virtual Desktop
icon to launch a session to when the service identifies a host to connect to. High
network load, high service load, or unique network traffic routing can lead to high
routing times. To troubleshoot user route issues, look at your network paths.
Stack connected: the time it takes from when the service resolves a target session
host for the user to when the service establishes a connection between the session
host and the user’s remote client. Like user routing, the network load, server load,
or unique network traffic routing can affect connection time. For this component,
you'll also need to pay attention to your network routing. To reduce connection
time, make sure you've appropriately configured all proxy configurations on both
the client and session hosts, and that routing to the service is optimal.
Logon: the time it takes between when a connection to a host is established to

when the shell starts to load. Logon time includes several processes that can
contribute to high connection times. You can view data for the "logon" stage in
Insights to see if there are unexpected peaks in average times.
The "logon" process is divided into four stages:
Profiles: the time it takes to load a user’s profile for new sessions. How long
loading takes depends on user profile size or the user profile solutions you're
using (such as User Experience Virtualization). If you're using a solution that
depends on network-stored profiles, excess latency can also lead to longer
profile loading times.
Group Policy Objects (GPOs): the time it takes to apply group policies to new
sessions. A spike in this area of the data is a sign that you have too many group
policies, the policies take too long to apply, or the session host is experiencing
resource issues. One thing you can do to optimize processing times is make
sure the domain controller is close to session hosts as possible.
Shell Start: the time it takes to launch the shell (usually explorer.exe).
FSLogix (Frxsvc): the time it takes to launch FSLogix in new sessions. A long
launch time may indicate issues with the shares used to host the FSLogix user
profiles. To troubleshoot these issues, make sure the shares are collocated with
the session hosts and appropriately scaled for the average number of users
signing in to the hosts. Another area you should look at is profile size. Large
profile sizes can slow down launch times.
Shell start to shell ready: the time from when the shell starts to load to when it's
fully loaded and ready for use. Delays in this phase can be caused by session host
overload (high CPU, memory, or disk activity) or configuration issues.
User report
The user report page lets you view a specific user’s connection history and diagnostic
information. Each user report shows usage patterns, user feedback, and any errors users
have encountered during their sessions. Most smaller issues can be resolved with user
feedback. If you need to dig deeper, you can also filter information about a specific
connection ID or period of time.
Users per core

This is the number of users in each virtual machine core. Tracking the
maximum number
of users per core over time can help you identify whether the
environment consistently
runs at a high, low, or fluctuating number of users per
core. Knowing how many users
are active will help you efficiently resource and scale the environment.
Windows Event Logs

Windows Event Logs are data sources collected by Log Analytics agents on Windows
virtual machines. You can collect events from standard logs like System and Application
as well as custom logs created by applications you need to monitor.
The following table lists the required Windows Event Logs for Azure Virtual Desktop
Insights:
Event name Event type
Application Error and Warning
Microsoft-Windows-TerminalServices- Error, Warning, and

RemoteConnectionManager/Admin Information
Microsoft-Windows-TerminalServices- Error, Warning, and

LocalSessionManager/Operational Information
System Error and Warning
Microsoft-FSLogix-Apps/Operational Error, Warning, and

Information
Microsoft-FSLogix-Apps/Admin Error, Warning, and

Information
To learn more about Windows Event Logs, see Windows Event records properties.
Next steps
To get started, see Use Azure Virtual Desktop Insights to monitor your deployment.
To estimate, measure, and manage your data storage costs, see Estimate Azure
Monitor costs.
If you encounter a problem, check out our troubleshooting guide for help and
known issues.
You can also set up Azure Advisor to help you figure out how to resolve or prevent
common issues. Learn more at Introduction to Azure Advisor.
If you need help or have any questions, check out our community resources:
Ask questions or make suggestions to the community at the Azure Virtual Desktop
TechCommunity .
To learn how to leave feedback, see Troubleshooting overview, feedback, and

You can also leave feedback for Azure Virtual Desktop at the Azure Virtual Desktop
feedback hub
 Documentation
Estimate Azure Virtual Desktop Insights monitoring costs - Azure

How to estimate costs and pricing for using Azure Virtual Desktop Insights.



Set up diagnostics for monitoring agent updates

How to set up diagnostic reports to monitor agent updates.
Troubleshoot Monitor Azure Virtual Desktop - Azure

How to troubleshoot issues with Azure Virtual Desktop Insights.

Show 5 more
 Training
Learning path
Implement an Azure Virtual Desktop infrastructure - Training
Implement an Azure Virtual Desktop infrastructure
Certification
Create a host pool in Azure Virtual
Desktop
This article shows you how to create a host pool by using the Azure portal, Azure CLI, or
Azure PowerShell. When using the Azure portal, you can optionally create session hosts,
a workspace, register the default desktop application group from this host pool, and
enable diagnostics settings in the same process, but you can also do this separately.
For more information on the terminology used in this article, see Azure Virtual Desktop
terminology.
You can create host pools in the following Azure regions:
Australia East
Canada Central
Canada East
Central India
Central US
East US
East US 2
Japan East
North Central US
North Europe
South Central US
UK South
UK West
West Central US
West Europe
West US
West US 2
West US 3
This list refers to the list of regions where the metadata for the host pool will be stored.
Session hosts added to a host pool can be located in any Azure region, and on-premises
when using Azure Virtual Desktop on Azure Stack HCI.
Prerequisites
Review the Prerequisites for Azure Virtual Desktop for a general idea of what's required.
In addition, you'll need:
An Azure account with an active subscription.
The account must have the following built-in role-based access control (RBAC)
roles on a resource group or subscription to create the following resource types. If
you want to assign the roles to a resource group, you'll need to create this first.
Resource type RBAC role
Host pool Desktop Virtualization Host Pool Contributor
Workspace Desktop Virtualization Workspace Contributor
Application group Desktop Virtualization Application Group Contributor
Session hosts Virtual Machine Contributor
Alternatively you can assign the Contributor RBAC role to create all of these
resource types.
If you want to use Azure CLI or Azure PowerShell locally, see Use Azure CLI and
Azure PowerShell with Azure Virtual Desktop to make sure you have the
desktopvirtualization Azure CLI extension or the Az.DesktopVirtualization
PowerShell module installed. Alternatively, use the Azure Cloud Shell.
Create a host pool

To create a host pool, select the relevant tab for your scenario and follow the steps.
Portal
Here's how to create a host pool using the Azure portal.
2. In the search bar, type Azure Virtual Desktop and select the matching service
entry.
3. Select Host pools, then select Create.
Subscription Select the subscription you want to create the host pool in from the
drop-down list.
Resource Select an existing resource group or select Create new and enter a
group name.
Host pool Enter a name for the host pool, for example hostpool01.
name
Location Select the Azure region where your host pool will be deployed.
Validation Select Yes to create a host pool that is used as a validation

environment environment.
Select No (default) to create a host pool that isn't used as a

validation environment.
Preferred app Select the preferred application group type for this host pool from
group type Desktop or Remote App.
Host pool type Select whether your host pool will be Personal or Pooled.
If you select Personal, a new option will appear for Assignment type.
Select either Automatic or Direct.
If you select Pooled, two new options will appear for Load balancing
algorithm and Max session limit.
- For Load balancing algorithm, choose either breadth-first or

depth-first, based on your usage pattern.
- For Max session limit, enter the maximum number of users you
want load-balanced to a single session host.
 Tip
Once you've completed this tab, you can continue to optionally create
session hosts, a workspace, register the default desktop application
group from this host pool, and enable diagnostics settings. Alternatively,
if you want to create and configure these separately, select Next: Review
+ create and go to step 9.
5. Optional: If you want to add session hosts in this process, on the Virtual
machines tab, complete the following information:
Add Azure Select Yes. This shows several new options.

virtual
machines
Resource This automatically defaults to the resource group you chose your host
group pool to be in on the Basics tab, but you can also select an alternative.
This will be used as the prefix for your session host VMs. Each session
host has a hyphen and then a sequential number added to the end,
for example aad-hp01-sh-0. This name prefix can be a maximum of
11 characters and is used in the computer name in the operating
system.
Virtual Select the Azure region where your session host VMs will be
machine deployed. This must be the same region that your virtual network is
location in.
Availability Select from availability zones, availability set, or No infrastructure

options dependency required. If you select availability zones or availability
set, complete the extra parameters that appear.
Security type Select from Standard, Trusted launch virtual machines, or

Confidential virtual machines.
Image Select the OS image you want to use from the list, or select See all
images to see more, including any images you've created and stored
as an Azure Compute Gallery shared image or a managed image.
Virtual Select a SKU. If you want to use different SKU, select Change size,
machine size then select from the list.
Number of Enter the number of virtual machines you want to deploy. You can
VMs deploy up to 400 session host VMs at this point if you wish
(depending on your subscription quota), or you can add more later.
For more information, see Azure Virtual Desktop service limits and
Virtual Machines limits.
OS disk type Select the disk type to use for your session hosts. We recommend
only Premium SSD is used for production workloads.
Boot Select whether you want to enable boot diagnostics.

Diagnostics
Network and
security
Virtual Select your virtual network. An option to select a subnet will appear.
network
Subnet Select a subnet from your virtual network.
Network Select whether you want to use a network security group (NSG).
security
group - None won't create a new NSG.
- Basic will create a new NSG for the VM NIC.
- Advanced enables you to select an existing NSG.
We recommend that you don't create an NSG here, but create an

NSG on the subnet instead.
Public You can select a port to allow from the list. Azure Virtual Desktop
inbound ports doesn't require public inbound ports, so we recommend you select
No.
Domain to
join
Select which Select from Azure Active Directory or Active Directory and complete
directory you the relevant parameters for the option you select.
would like to
join
Virtual
Machine
Administrator
account
Username Enter a name to use as the local administrator account for the new
session host VMs.

password
Custom
configuration
ARM If you want to use an extra ARM template during deployment you can
template file enter the URL here.
URL
ARM Enter the URL to the parameters file for the ARM template.
template
parameter file
URL
Once you've completed this tab, select Next: Workspace.
6. Optional: If you want to create a workspace and register the default desktop
application group from this host pool in this process, on the Workspace tab,
complete the following information:
Register desktop Select Yes. This registers the default desktop application group to
app group the selected workspace.
To this Select an existing workspace from the list, or select Create new
workspace and enter a name, for example aad-ws01.
Once you've completed this tab, select Next: Advanced.
7. Optional: If you want to enable diagnostics settings in this process, on the

Advanced tab, complete the following information:
Enable diagnostics settings Check the box.
Choosing destination details to send logs to Select one of the following:
- Send to Log Analytics workspace
- Archive to storage account
- Stream to an event hub
Once you've completed this tab, select Next: Tags.
8. Optional: On the Tags tab, you can enter any name/value pairs you need, then
select Next: Review + create.
9. On the Review + create tab, ensure validation passes and review the
information that will be used during deployment.
10. Select Create to create the host pool.

11. Once the host pool has been created, select Go to resource to go to the
overview of your new host pool, then select Properties to view its properties.
Optional: Post deployment

If you also added session hosts to your host pool, there's some extra configuration
you may need to do, which is covered in the following sections.
Licensing
To ensure your session hosts have licenses applied correctly, you'll need to do the
following tasks:
If you have the correct licenses to run Azure Virtual Desktop workloads, you
can apply a Windows or Windows Server license to your session hosts as part
of Azure Virtual Desktop and run them without paying for a separate license.
This is automatically applied when creating session hosts with the Azure
Virtual Desktop service, but you may have to apply the license separately if
you create session hosts outside of Azure Virtual Desktop. For more
information, see Apply a Windows license to session host virtual machines.
If your session hosts are running a Windows Server OS, you'll also need to
issue them a Remote Desktop Services (RDS) Client Access License (CAL) from
a Remote Desktop Licensing Server. For more information, see License your
RDS deployment with client access licenses (CALs).
Azure AD-joined session hosts

If your users are going to connect to session hosts joined to Azure Active Directory,
you'll need to do the following tasks:
If your users are going to connect to session hosts joined to Azure Active
Directory, you must assign them the Virtual Machine User Login or Virtual
Machine Administrator Login RBAC role either on each virtual machine, the
resource group containing the virtual machines, or the subscription. We
recommend you assign the Virtual Machine User Login RBAC role on the
resource group containing your session hosts to the same user group as you
assign to the application group. For more information, see Log in to a
Windows virtual machine in Azure by using Azure AD.
For users connecting from Windows devices that aren't joined to Azure AD or
non-Windows devices, add the custom RDP property targetisaadjoined:i:1
to the host pool's RDP properties. These connections are restricted to entering
user name and password credentials when signing in to a session host. For
more information, see Customize RDP properties for a host pool.
For more information about using session hosts joined to Azure AD, see Azure AD-
joined session hosts.
Next steps
Portal
If you didn't complete the optional sections when creating a host pool, you'll still
need to do the following tasks separately:
Create an application group and a workspace, then add the application group
to a workspace and assign users.
Add session hosts to a host pool.
Enable diagnostics settings.

Create an application group, a
workspace, and assign users in Azure
Virtual Desktop
This article shows you how to create an application group and a workspace, then add
the application group to a workspace and assign users by using the Azure portal, Azure
CLI, or Azure PowerShell. Before you complete these steps, you should have already
created a host pool.
For more information on the terminology used in this article, see Azure Virtual Desktop
terminology.
Prerequisites
An existing host pool. See Create a host pool to find out how to create one.
The account must have the following built-in role-based access control (RBAC)
roles on the resource group, or on a subscription to create the resources.
Resource type RBAC role
Workspace Desktop Virtualization Workspace Contributor
Application group Desktop Virtualization Application Group Contributor
Alternatively you can assign the Desktop Virtualization Contributor RBAC role to
create all of these resource types.
To assign users to the application group, you'll also need

Microsoft.Authorization/roleAssignments/write permissions on the application
group. Built-in RBAC roles that include this permission are User Access
Administrator and Owner.
Create an application group

To create an application group, select the relevant tab for your scenario and follow the
steps.
Portal
Here's how to create an application group using the Azure portal.
entry.
3. Select Application groups, then select Create.
Subscription Select the subscription you want to create the application group in
from the drop-down list.
Resource group Select an existing resource group or select Create new and enter a
name.
Host pool Select the host pool for the application group.
Location Metadata is stored in the same location as the host pool.
Application Select the application group type for this host pool from Desktop
group type or RemoteApp.
Application Enter a name for the application group, for example Session
group name Desktop.
 Tip
Once you've completed this tab, select Next: Review + create. You don't
need to complete the other tabs to create an application group, but you'll
need to create a workspace, add an application group to a workspace
and assign users to the application group before users can access the
resources.
If you created an application group for RemoteApp, you will also need to
add applications. For more information, see Add applications to an
application group
6. Select Create to create the application group.
7. Once the application group has been created, select Go to resource to go to

the overview of your new application group, then select Properties to view its
properties.
Create a workspace
Next, to create a workspace, select the relevant tab for your scenario and follow the
steps.
Portal
Here's how to create a workspace using the Azure portal.
entry.
3. Select Workspaces, then select Create.
Subscription Select the subscription you want to create the workspace in from the
drop-down list.
Resource Select an existing resource group or select Create new and enter a
group name.
Workspace Enter a name for the workspace, for example workspace01.

name
Friendly Optional: Enter a friendly name for the workspace.

name
Description Optional: Enter a description for the workspace.
Location Select the Azure region where your workspace will be deployed.
 Tip
Once you've completed this tab, select Next: Review + create. You don't
need to complete the other tabs to create a workspace, but you'll need to
add an application group to a workspace and assign users to the
application group before they can access its applications.
6. Select Create to create the workspace.
7. Once the workspace has been created, select Go to resource to go to the

overview of your new workspace, then select Properties to view its properties.
Add an application group to a workspace

Next, to add an application group to a workspace, select the relevant tab for your
scenario and follow the steps.
Portal
Here's how to add an application group to a workspace using the Azure portal.
entry.
3. Select Workspaces, then select the name of the workspace you want to assign
an application group to.
4. From the workspace overview, select Application groups, then select + Add.
5. Select the plus icon (+) next to an application group from the list. Only
application groups that aren't already assigned to a workspace are listed.
6. Select Select. The application group will be added to the workspace.
Assign users to an application group

Finally, to assign users or user groups to an application group, select the relevant tab for
your scenario and follow the steps. We recommend you assign user groups to
application groups to make ongoing management simpler.
Portal
Here's how to assign users or user groups to an application group to a workspace

using the Azure portal.
1. From the host pool overview, select Application groups.
2. Select the application group from the list.
3. From the application group overview, select Assignments.
4. Select + Add, then search for and select the user account or user group you
want to assign to this application group.
5. Finish by selecting Select.
Next steps
Now that you've created an application group and a workspace, added the application
group to a workspace and assigned users, you'll need to:
Add session hosts to the host pool, if you haven't done so already.
Add applications to an application group, if you created a RemoteApp application

group.
Add session hosts to a host pool
Once you've created a host pool, workspace, and an application group, you need to add
session hosts to the host pool for your users to connect to. You may also need to add
more session hosts for extra capacity.
You can create new virtual machines to use as session hosts and add them to a host
pool natively using the Azure Virtual Desktop service in the Azure portal. Alternatively
you can also create virtual machines outside of the Azure Virtual Desktop service, such
as an automated pipeline, then add them as session hosts to a host pool. When using
Azure CLI or Azure PowerShell you'll need to create the virtual machines outside of
Azure Virtual Desktop, then add them as session hosts to a host pool separately.
This article shows you how to generate a registration key using the Azure portal, Azure
CLI, or Azure PowerShell, then how to add session hosts to a host pool using the Azure
Virtual Desktop service or adding them to a host pool separately.
Prerequisites
An existing host pool.
If you're joining session hosts to Azure Active Directory (Azure AD), you need an
account that can join computers to your tenant. To learn more about joining
session hosts to Azure AD, see Azure AD-joined session hosts.
If you're joining session hosts to Active Directory domain using Active Directory
Domain Services (AD DS) or Azure Active Directory Domain Services (Azure AD DS),
you need a domain account that can join computers to your domain. For Azure AD
DS, you would need to be a member of the AAD DC Administrators group.
A virtual network and subnet in the same Azure region you want to create session
hosts. You don't need a public IP address or open inbound ports for your session
hosts.
If you have existing session hosts in the host pool, make a note of the virtual
machine size, the image, and name prefix that was used. All session hosts in a host
pool should be the same configuration, including the same identity provider. For
example, a host pool shouldn't contain some session hosts joined to Azure AD and
some session hosts joined to an Active Directory domain.
If you're creating virtual machines outside of the Azure Virtual Desktop service,
make sure you're using a supported operating system (OS). Remember to use a
multi-session OS for a pooled host pool.
A minimum of Contributor built-in role-based access control (RBAC) role on the

resource group.
） Important
If you want to create Azure Active Directory-joined session hosts, we only support
this using the Azure portal with the Azure Virtual Desktop service.
Generate a registration key

When you add session hosts to a host pool, first you'll need to generate a registration
key. A registration key needs to be generated per host pool and it authorizes session
hosts to join that host pool. It's only valid for the duration you specify. If an existing
registration key has expired, you can also use these steps to generate a new key.
To generate a registration key, select the relevant tab for your scenario and follow the
steps.
Portal
Here's how to generate a registration key using the Azure portal.
entry.
3. Select Host pools, then select the name of the host pool you want to generate
a registration key for.
4. On the host pool overview, select Registration key.

5. Select Generate new key, then enter an expiration date and time and select
OK. The registration key will be created.
6. Select Download to download a text file containing the registration key, or

copy the registration key to your clipboard to use later. You can also retrieve
the registration key later by returning to the host pool overview.
Create and register session hosts with the

Azure Virtual Desktop service
You can create session hosts and register them to a host pool in a single end-to-end
process with the Azure Virtual Desktop service using the Azure portal or an ARM
template. You can find some example ARM templates in our GitHub repo .
） Important
If you want to create virtual machines using an alternative method outside of Azure
Virtual Desktop, such as an automated pipeline, you'll need to register them
separately as session hosts to a host pool. Skip to the section Register session
hosts to a host pool.
Here's how to create session hosts and register them to a host pool using the Azure
Virtual Desktop service in the Azure portal. Make sure you're generated a registration
key first.
3. Select Host pools, then select the name of the host pool you want to add session
hosts to.
4. On the host pool overview, select Session hosts, then select + Add.
5. The Basics tab will be greyed out because you're using the existing host pool.
Select Next: Virtual Machines.
6. On the Virtual machines tab, complete the following information:
Resource This automatically defaults to the same resource group as your host pool,
group but you can select an alternative existing one from the drop-down list.
This will be used as the prefix for your session host VMs. Each session host
will have a hyphen and then a sequential number added to the end, for
example aad-hp01-sh-0. This name prefix can be a maximum of 11
characters and will also be in the computer name in the operating system.
Session host names must be unique.
Virtual Select the Azure region where your session host VMs will be deployed. This
machine must be the same region that your virtual network is in.
location
Availability Select from availability zones, availability set, or No infrastructure

options dependency required. If you select availability zones or availability set,
complete the extra parameters that appear.
Security type Select from Standard, Trusted launch virtual machines, or Confidential
virtual machines.
Image Select the OS image you want to use from the list, or select See all images
to see more, including any images you've created and stored as an Azure
Compute Gallery shared image or a managed image.
Virtual Select a SKU. If you want to use different SKU, select Change size, then
machine size select from the list.
Number of Enter the number of virtual machines you want to deploy. You can deploy
VMs up to 400 session host VMs at this point if you wish (depending on your
subscription quota), or you can add more later.
For more information, see Azure Virtual Desktop service limits and Virtual
Machines limits.
OS disk type Select the disk type to use for your session hosts. We recommend only
Premium SSD is used for production workloads.
Boot Select whether you want to enable boot diagnostics.

Diagnostics
Network and
security
Virtual Select your virtual network. An option to select a subnet will appear.
network
Subnet Select a subnet from your virtual network.

Network Select whether you want to use a network security group (NSG).
security
group - Basic will create a new NSG for the VM NIC.
- Advanced enables you to select an existing NSG.
Public We recommend you select No.

inbound ports
Domain to
join
Select which Select from Azure Active Directory or Active Directory and complete the
directory you relevant parameters for the option you select.
would like to
join
Virtual
Machine
Administrator
account
Username Enter a name to use as the local administrator account for the new session
host VMs.

password
Custom
configuration
ARM If you want to use an extra ARM template during deployment you can
template file enter the URL here.
URL
ARM Enter the URL to the parameters file for the ARM template.
template
parameter file
URL
Once you've completed this tab, select Next: Tags.
7. On the Tags tab, you can optionally enter any name/value pairs you need, then
select Next: Review + create.
8. On the Review + create tab, ensure validation passes and review the information
that will be used during deployment. If validation doesn't pass, review the error
message and check what you entered in each tab.
9. Select Create. Once your deployment is complete, the session hosts should appear
in the host pool.
） Important
Once you've added session hosts with the Azure Virtual Desktop service, skip to the
section Post deployment for some extra configuration you may need to do.
Register session hosts to a host pool

If you created virtual machines using an alternative method outside of Azure Virtual
Desktop, such as an automated pipeline, you'll need to register them separately as
session hosts to a host pool. To register session hosts to a host pool, you need to install
the Azure Virtual Desktop Agent and the Azure Virtual Desktop Agent Bootloader on
each virtual machine and use the registration key you generated. You can register
session hosts to a host pool using the agent installers' graphical user interface (GUI) or
using msiexec from a command line. Once complete, four applications will be listed as
installed applications:
Remote Desktop Agent Boot Loader.

Remote Desktop Services Infrastructure Agent.
Remote Desktop Services Infrastructure Geneva Agent.
Remote Desktop Services SxS Network Stack.
Select the relevant tab for your scenario and follow the steps.
GUI
1. Make sure the virtual machines you want to use as session hosts are joined to
Azure Active Directory or an Active Directory domain (AD DS or Azure AD DS).
2. If your virtual machines are running a Windows Server OS, you'll need to
install the Remote Desktop Session Host role, then restart the virtual machine.
For more information, see Install roles, role services, and features by using the
add Roles and Features Wizard.
3. Sign in to your virtual machine as an administrator.

4. Download the Agent and the Agent Bootloader installation files using the
following links You may need to unblock them; right-click each file and select
Properties, then select Unblock, and finally select OK.
Azure Virtual Desktop Agent
Azure Virtual Desktop Agent Bootloader
5. Run the Microsoft.RDInfra.RDAgent.Installer-x64-<version>.msi file to install

the Remote Desktop Services Infrastructure Agent.
6. Follow the prompts and when the installer prompts for the registration token,
paste it into the text box, which will appear on a single line. Select Next, then
complete the installation.
7. Run the Microsoft.RDInfra.RDAgentBootLoader.Installer-x64.msi file to install

the remaining components.
8. Follow the prompts and complete the installation.
9. The virtual machines should now appear as a session host in the host pool.
Finally, restart the virtual machines.
Post deployment
After you've added session hosts to your host pool, there's some extra configuration
you may need to do, which is covered in the following sections.
Licensing
To ensure your session hosts have licenses applied correctly, you'll need to do the
following tasks:
If you have the correct licenses to run Azure Virtual Desktop workloads, you can
apply a Windows or Windows Server license to your session hosts as part of Azure
Virtual Desktop and run them without paying for a separate license. This is
automatically applied when creating session hosts with the Azure Virtual Desktop
service, but you may have to apply the license separately if you create session
hosts outside of Azure Virtual Desktop. For more information, see Apply a
Windows license to session host virtual machines.
If your session hosts are running a Windows Server OS, you'll also need to issue
them a Remote Desktop Services (RDS) Client Access License (CAL) from a Remote
Desktop Licensing Server. For more information, see License your RDS deployment
with client access licenses (CALs).
Azure AD-joined session hosts

If your users are going to connect to session hosts joined to Azure Active Directory,
you'll need to do the following tasks:
If your users are going to connect to session hosts joined to Azure Active
Directory, you must assign them the Virtual Machine User Login or Virtual Machine
Administrator Login RBAC role either on each virtual machine, the resource group
containing the virtual machines, or the subscription. We recommend you assign
the Virtual Machine User Login RBAC role on the resource group containing your
session hosts to the same user group as you assign to the application group. For
more information, see Log in to a Windows virtual machine in Azure by using
Azure AD.
For users connecting from Windows devices that aren't joined to Azure AD or non-
Windows devices, add the custom RDP property targetisaadjoined:i:1 to the
host pool's RDP properties. These connections are restricted to entering user name
and password credentials when signing in to a session host. For more information,
see Customize RDP properties for a host pool.
For more information about using session hosts joined to Azure AD, see Azure AD-
joined session hosts.
Next steps
Now that you've expanded your existing host pool, you can sign in to an Azure Virtual
Desktop client to test them as part of a user session. You can connect to a session with
any of the following clients:

Deploy Azure Virtual Desktop with the
getting started feature
You can quickly deploy Azure Virtual Desktop with the getting started feature in the
Azure portal. This can be used in smaller scenarios with a few users and apps, or you can
use it to evaluate Azure Virtual Desktop in larger enterprise scenarios. It works with
existing Active Directory Domain Services (AD DS) or Azure Active Directory Domain
Services (Azure AD DS) deployments, or it can deploy Azure AD DS for you. Once you've
finished, a user will be able to sign in to a full virtual desktop session, consisting of one
host pool (with one or more session hosts), one app group, and one user. To learn about
the terminology used in Azure Virtual Desktop, see Azure Virtual Desktop terminology.
Joining session hosts to Azure Active Directory with the getting started feature is not
supported. If you want to want to join session hosts to Azure Active Directory, follow the
tutorial to create a host pool.
 Tip
Enterprises should plan an Azure Virtual Desktop deployment using information

from Enterprise-scale support for Microsoft Azure Virtual Desktop. You can also
find more a granular deployment process in a series of tutorials, which also cover
programmatic methods and less permission.
You can see the list of resources that will be deployed further down in this article.
Prerequisites
Please review the Prerequisites for Azure Virtual Desktop to start for a general idea of
what's required, however there are some differences when using the getting started
feature that you'll need to meet. Select a tab below to show instructions that are most
relevant to your scenario.
 Tip
If you don't already have other Azure resources, we recommend you select the
New Azure AD DS tab. This scenario will deploy everything you need to be ready to
connect to a full virtual desktop session. If you already have AD DS or Azure AD DS,
select the relevant tab for your scenario instead.
New Azure AD DS
At a high level, you'll need:
An Azure account with an active subscription

An account with the global administrator Azure AD role assigned on the Azure
tenant and the owner role assigned on subscription you're going to use.
No existing Azure AD DS domain deployed in your Azure tenant.
User names you choose must not include any keywords that the username
guideline list doesn't allow, and you must use a unique user name that's not
already in your Azure AD subscription.
The user name for AD Domain join UPN should be a unique one that doesn't
already exist in Azure AD. The getting started feature doesn't support using
existing Azure AD user names when also deploying Azure AD DS.
） Important
The getting started feature doesn't currently support accounts that use multi-factor
authentication. It also does not support personal Microsoft accounts (MSA) or
Azure AD B2B collaboration users (either member or guest accounts).
Deployment steps
New Azure AD DS
Here's how to deploy Azure Virtual Desktop and a new Azure AD DS domain using
the getting started feature:
entry.
3. Select Getting started to open the landing page for the getting started
feature, then select Start.
4. On the Basics tab, complete the following information, then select Next:
Virtual Machines >:
Subscription The subscription you want to use from the drop-down list.
Identity No identity provider.

provider
Identity Azure AD Domain Services.

service type
Resource Enter a name. This will be used as the prefix for the resource groups
group that are deployed.
Location The Azure region where your Azure Virtual Desktop resources will be
deployed.
Azure The user principal name (UPN) of the account with the global
admin user administrator Azure AD role assigned on the Azure tenant and the
name owner role on the subscription that you selected.
Make sure this account meets the requirements noted in the

prerequisites.
Azure The password for the Azure admin account.

admin
password
Domain The user principal name (UPN) for a new Azure AD account that will be
admin user added to a new AAD DC Administrators group and used to manage
name your Azure AD DS domain. The UPN suffix will be used as the Azure AD
DS domain name.
Make sure this user name meets the requirements noted in the
prerequisites.
Domain The password for the domain admin account.

admin
password
5. On the Virtual machines tab, complete the following information, then select
Next: Assignments >:
Users per Select Multiple users or One user at a time depending on whether you
virtual want users to share a session host or assign a session host to an
machine individual user. Learn more about host pool types. Selecting Multiple
users will also create an Azure Files storage account joined to the same
Azure AD DS domain.
Image Select Gallery to choose from a predefined list, or storage blob to enter
type a URI to the image.
Image If you chose Gallery for image type, select the operating system image
you want to use from the drop-down list. You can also select See all
images to choose an image from the Azure Compute Gallery.
If you chose Storage blob for image type, enter the URI of the image.
Virtual The Azure virtual machine size used for your session host(s)
machine
size
Name The name prefix for your session host(s). Each session host will have a
prefix hyphen and then a number added to the end, for example avd-sh-1. This
name prefix can be a maximum of 11 characters and will also be used as
the device name in the operating system.
Number of The number of session hosts you want to deploy at this time. You can
virtual add more later.
machines
Link Azure Tick the box if you want to link a separate ARM template for custom
template configuration on your session host(s) during deployment. You can specify
inline deployment script, desired state configuration, and custom script
extension. Provisioning other Azure resources in the template isn't
supported.
Untick the box if you don't want to link a separate ARM template during
deployment.
ARM The URL of the ARM template file you want to use. This could be stored
template in a storage account.
file URL
ARM The URL of the ARM template parameter file you want to use. This could
template be stored in a storage account.
parameter
file URL
6. On the Assignments tab, complete the following information, then select

Next: Review + create >:
Create test Tick the box if you want a new user account created during deployment
user for testing purposes.
account
Test user The user principal name (UPN) of the test account you want to be
name created, for example testuser@contoso.com . This user will be created in
your new Azure AD tenant, synchronized to Azure AD DS, and made a
member of the AVDValidationUsers security group that is also created
during deployment. It must contain a valid UPN suffix for your domain
that is also added as a verified custom domain name in Azure AD.
Make sure this user name meets the requirements noted in the
prerequisites.
Test The password to be used for the test account.

password
Confirm Confirmation of the password to be used for the test account.

password
8. Select Create.
Connect to the desktop

Once the deployment has completed successfully, if you created a test account or
assigned an existing user during deployment, you can connect to it following the steps
for one of the supported Remote Desktop clients. For example, you can follow the steps
to Connect with the Windows Desktop client.
If you didn't create a test account or assigned an existing user during deployment, you'll
need to add users to the AVDValidationUsers security group before you can connect.
Resources that will be deployed

New Azure AD DS
Resource Name Resource Notes
type group
name
Resource your prefix-avd N/A This is a predefined

group name.
Resource your prefix-deployment N/A This is a predefined

group name.
Resource your prefix-prerequisite N/A This is a predefined

group name.
Azure AD your domain name your prefix- Deployed with the

DS prerequisite Enterprise SKU .
You can change the
SKU after
deployment.
Automation ebautomationrandom string your prefix- This is a predefined

Account deployment name.
Automation inputValidationRunbook(Automation Account your prefix- This is a predefined

Account name) deployment name.
runbook
Automation prerequisiteSetupCompletionRunbook(Automation your prefix- This is a predefined

Account Account name) deployment name.
runbook
Automation resourceSetupRunbook(Automation Account your prefix- This is a predefined

runbook
Automation roleAssignmentRunbook(Automation Account your prefix- This is a predefined

runbook
Managed easy-button-fslogix-identity your prefix- Only created if

Identity avd Multiple users is
selected for Users
per virtual
machine. This is a
predefined name.
Host pool EB-AVD-HP your prefix- This is a predefined

avd name.
Application EB-AVD-HP-DAG your prefix- This is a predefined

group avd name.
type group
name
Workspace EB-AVD-WS your prefix- This is a predefined

avd name.
Storage ebrandom string your prefix- This is a predefined

account avd name.
Virtual your prefix-number your prefix- This is a predefined

machine avd name.
Virtual avdVnet your prefix- The address space

network prerequisite used is 10.0.0.0/16.
The address space
and name are
predefined.
Network virtual machine name-nic your prefix- This is a predefined

interface avd name.
Network aadds-random string-nic your prefix- This is a predefined

interface prerequisite name.
Network aadds-random string-nic your prefix- This is a predefined

interface prerequisite name.
Disk virtual machine name_OsDisk_1_random string your prefix- This is a predefined

avd name.
Load aadds-random string-lb your prefix- This is a predefined

balancer prerequisite name.
Public IP aadds-random string-pip your prefix- This is a predefined

address prerequisite name.
Network avdVnet-nsg your prefix- This is a predefined

security prerequisite name.
group
Group AVDValidationUsers N/A Created in your

new Azure AD
tenant and
synchronized to
Azure AD DS. It
contains a new test
user (if created)
and users you
selected. This is a
predefined name.
type group
name
User your test user N/A If you select to

create a test user, it
will be created in
your new Azure AD
tenant,
synchronized to
Azure AD DS, and
made a member of
the
AVDValidationUsers
security group.
Clean up resources
If you want to remove Azure Virtual Desktop resources from your environment, you can
safely remove them by deleting the resource groups that were deployed. These are:
your-prefix-deployment
your-prefix-avd
your-prefix-prerequisite (only if you deployed the getting started feature with a
new Azure AD DS domain)
To delete the resource groups:
2. In the search bar, type Resource groups and select the matching service entry.
3. Select the name of one of resource groups, then select Delete resource group.
4. Review the affected resources, then type the resource group name in the box, and
select Delete.
5. Repeat these steps for the remaining resource groups.
Next steps
If you want to publish apps as well as the full virtual desktop, see the tutorial to Manage
app groups with the Azure portal.
If you'd like to learn how to deploy Azure Virtual Desktop in a more in-depth way, with
less permission required, or programmatically, check out our series of tutorials, starting
with Create a host pool with the Azure portal.
Configure graphics processing unit
(GPU) acceleration for Azure Virtual
Desktop
） Important
Azure Virtual Desktop supports GPU-accelerated rendering and encoding for improved
app performance and scalability. GPU acceleration is particularly crucial for graphics-
intensive apps and is supported in the following operating systems:
Windows 10 version 1511 or newer

Windows Server 2016 or newer
７ Note
Multi-session versions of Windows are not specifically listed, however each GPU in
NV-series Azure virtual machine comes with a GRID license that supports 25
concurrent users. For more information, see NV-series.
Follow the instructions in this article to create a GPU optimized Azure virtual machine,
add it to your host pool, and configure it to use GPU acceleration for rendering and
encoding. This article assumes you have already created a host pool and an application
group.
Select an appropriate GPU-optimized Azure

virtual machine size
Select one of Azure's NV-series, NVv3-series, NVv4-series or NCasT4_v3-series VM sizes
to use as a session host. These are tailored for app and desktop virtualization and
enable most apps and the Windows user interface to be GPU accelerated. The right
choice for your host pool depends on a number of factors, including your particular app
workloads, desired quality of user experience, and cost. In general, larger and more
capable GPUs offer a better user experience at a given user density, while smaller and
fractional-GPU sizes allow more fine-grained control over cost and quality. Consider NV
series VM retirement when selecting VM, details on NV retirement
７ Note
Azure's NC, NCv2, NCv3, ND, and NDv2 series VMs are generally not appropriate
for Azure Virtual Desktop session hosts. These VMs are tailored for specialized,
high-performance compute or machine learning tools, such as those built with
NVIDIA CUDA. They do not support GPU acceleration for most apps or the
Windows user interface.
Install supported graphics drivers in your

virtual machine
To take advantage of the GPU capabilities of Azure N-series VMs in Azure Virtual
Desktop, you must install the appropriate graphics drivers. Follow the instructions at
Supported operating systems and drivers to install drivers. Only drivers distributed by
Azure are supported.
For Azure NV-series, NVv3-series or NCasT4_v3-series VMs, only NVIDIA GRID

drivers, and not NVIDIA CUDA drivers, support GPU acceleration for most apps and
the Windows user interface. If you choose to install drivers manually, be sure to
install GRID drivers. If you choose to install drivers using the Azure VM extension,
GRID drivers will automatically be installed for these VM sizes.
For Azure NVv4-series VMs, install the AMD drivers provided by Azure. You may
install them automatically using the Azure VM extension, or you may install them
manually.
After driver installation, a VM restart is required. Use the verification steps in the above
instructions to confirm that graphics drivers were successfully installed.
Configure GPU-accelerated app rendering

By default, apps and desktops running on Windows Server are rendered with the CPU
and do not leverage available GPUs for rendering. Configure Group Policy for the
session host to enable GPU-accelerated rendering:
1. Connect to the desktop of the VM using an account with local administrator

privileges.
2. Open the Start menu and type "gpedit.msc" to open the Group Policy Editor.
3. Navigate the tree to Computer Configuration > Administrative Templates >
Windows Components > Remote Desktop Services > Remote Desktop Session
Host > Remote Session Environment.
4. Select policy Use hardware graphics adapters for all Remote Desktop Services
sessions and set this policy to Enabled to enable GPU rendering in the remote
session.
Configure GPU-accelerated frame encoding

Remote Desktop encodes all graphics rendered by apps and desktops (whether
rendered with GPU or with CPU) for transmission to Remote Desktop clients. When part
of the screen is frequently updated, this part of the screen is encoded with a video
codec (H.264/AVC). By default, Remote Desktop does not leverage available GPUs for
this encoding. Configure Group Policy for the session host to enable GPU-accelerated
frame encoding. Continuing the steps above:
７ Note
GPU-accelerated frame encoding is not available in NVv4-series VMs.
1. Select policy Configure H.264/AVC hardware encoding for Remote Desktop

connections and set this policy to Enabled to enable hardware encoding for
AVC/H.264 in the remote session.
７ Note
In Windows Server 2016, set option Prefer AVC Hardware Encoding to Always
attempt.
2. Now that the group policies have been edited, force a group policy update. Open
the Command Prompt and type:
Windows Command Prompt
gpupdate.exe /force
3. Sign out from the Remote Desktop session.

Configure fullscreen video encoding
７ Note
Fullscreen video encoding can be enabled even without a GPU present.
If you often use applications that produce a high-frame rate content, such as 3D
modeling, CAD/CAM and video applications, you may choose to enable a fullscreen
video encoding for a remote session. Fullscreen video profile provides a higher frame
rate and better user experience for such applications at expense of network bandwidth
and both session host and client resources. It is recommended to use GPU-accelerated
frame encoding for a full-screen video encoding. Configure Group Policy for the session
host to enable fullscreen video encoding. Continuing the steps above:
1. Select policy Prioritize H.264/AVC 444 Graphics mode for Remote Desktop
connections and set this policy to Enabled to force H.264/AVC 444 codec in the
remote session.
2. Now that the group policies have been edited, force a group policy update. Open
the Command Prompt and type:
gpupdate.exe /force
3. Sign out from the Remote Desktop session.
Verify GPU-accelerated app rendering

To verify that apps are using the GPU for rendering, try any of the following:
For Azure VMs with a NVIDIA GPU, use the nvidia-smi utility as described in Verify
driver installation to check for GPU utilization when running your apps.
On supported operating system versions, you can use the Task Manager to check
for GPU utilization. Select the GPU in the "Performance" tab to see whether apps
are utilizing the GPU.
Verify GPU-accelerated frame encoding

To verify that Remote Desktop is using GPU-accelerated encoding:
1. Connect to the desktop of the VM using Azure Virtual Desktop client.
2. Launch the Event Viewer and navigate to the following node: Applications and
Services Logs > Microsoft > Windows > RemoteDesktopServices-RdpCoreCDV >
Operational
3. To determine if GPU-accelerated encoding is used, look for event ID 170. If you see
"AVC hardware encoder enabled: 1" then GPU encoding is used.
Verify fullscreen video encoding

To verify that Remote Desktop is using fullscreen video encoding:
1. Connect to the desktop of the VM using Azure Virtual Desktop client.

2. Launch the Event Viewer and navigate to the following node: Applications and
Services Logs > Microsoft > Windows > RemoteDesktopServices-RdpCoreCDV >
Operational
3. To determine if fullscreen video encoding is used, look for event ID 162. If you see
"AVC Available: 1 Initial Profile: 2048" then AVC 444 is used.
Next steps
These instructions should have you up and running with GPU acceleration on one
session host (one VM). Some additional considerations for enabling GPU acceleration
across a larger host pool:
Consider using a VM extension to simplify driver installation and updates across a

number of VMs. Use the NVIDIA GPU Driver Extension for VMs with NVIDIA GPUs,
and use the AMD GPU Driver Extension for VMs with AMD GPUs.
Consider using Active Directory Group Policy to simplify group policy configuration
across a number of VMs. For information about deploying Group Policy in the
Active Directory domain, see Working with Group Policy Objects.
 Documentation
Azure N-series NVIDIA GPU driver setup for Windows - Azure Virtual Machines
How to set up NVIDIA GPU drivers for N-series VMs running Windows Server or Windows in Azure
AMD GPU Driver Extension - Azure Windows VMs - Azure Virtual Machines
Microsoft Azure extension for installing AMD GPU drivers on NVv4-series VMs running Windows.
Azure N-series AMD GPU driver setup for Windows - Azure Virtual Machines
How to set up AMD GPU drivers for N-series VMs running Windows Server or Windows in Azure
NVIDIA GPU Driver Extension - Azure Windows VMs - Azure Virtual Machines
Azure extension for installing NVIDIA GPU drivers on N-series compute VMs running Windows.
NVv4-series - Azure Virtual Machines

Specifications for the NVv4-series VMs.
NV series retirement - Azure Virtual Machines

NV series retirement starting September 1, 2021
NVv3-series - Azure Virtual Machines

Specifications for the NVv3-series VMs.
NV-series - Azure Virtual Machines

Specifications for the NV-series VMs.
Show 5 more
 Training
Certification
Manage app groups with the Azure
portal
） Important
The default app group created for a new Azure Virtual Desktop host pool also publishes
the full desktop. In addition, you can create one or more RemoteApp application groups
for the host pool. Follow this tutorial to create a RemoteApp app group and publish
individual Start menu apps.
７ Note
You can dynamically attach MSIX apps to user sessions or add your app packages
to a custom virtual machine (VM) image to publish your organization's apps. Learn
more at How to host custom apps with Azure Virtual Desktop.
＂ Create a RemoteApp group.

＂ Grant access to RemoteApp programs.
Create a RemoteApp group

If you've already created a host pool and session host VMs using the Azure portal or
PowerShell, you can add application groups from the Azure portal with the following
process:
７ Note
If you're signing in to the US Gov portal, go to https://portal.azure.us/

instead.
If you're accessing the Azure China portal, go to https://portal.azure.cn/ .
2. Search for and select Azure Virtual Desktop.
3. You can add an application group directly or you can add it from an existing host
pool. Choose an option below:
Select Application groups in the menu on the left side of the page, then
select + Add.
Select Host pools in the menu on the left side of the screen, select the name
of the host pool, select Application groups from the menu on the left side,
then select + Add. In this case, the host pool will already be selected on the
Basics tab.
4. On the Basics tab, select the Subscription and Resource group you want to create
the app group for. You can also choose to create a new resource group instead of
selecting an existing one.
5. Select the Host pool that will be associated with the application group from the
drop-down menu.
７ Note
You must select the host pool associated with the application group. App
groups have apps or desktops that are served from a session host and session
hosts are part of host pools. The app group needs to be associated with a
host pool during creation.
6. Select RemoteApp under Application group type, then enter a name for your
RemoteApp.
7. Select Next: Assignments > tab.
8. To assign individual users or user groups to the app group, select +Add Azure AD
users or user groups.
9. Select the users you want to have access to the apps. You can select single or
multiple users and user groups.
10. Select Select.
11. Select Next: Applications >, then select +Add applications.

12. To add an application from the start menu:
Under Application source, select Start menu from the drop-down menu.
Next, under Application, choose the application from the drop-down menu.
In Display name, enter the name for the application that will be shown to the
user on their client.
Leave the other options as-is and select Save.
13. To add an application from a specific file path:
Under Application source, select File path from the drop-down menu.
In Application path, enter the path to the application on the session host
registered with the associated host pool.
Enter the application's details in the Application name, Display name, Icon
path, and Icon index fields.
Select Save.
14. Repeat this process for every application you want to add to the application group.
15. Next, select Next: Workspace >.

16. If you want to register the app group to a workspace, select Yes for Register
application group. If you'd rather register the app group at a later time, select No.
17. If you select Yes, you can select an existing workspace to register your app group
to.
７ Note
You can only register the app group to workspaces created in the same
location as the host pool. Also. if you've previously registered another app
group from the same host pool as your new app group to a workspace, it will
be selected and you can't edit it. All app groups from a host pool must be
registered to the same workspace.
18. Optionally, if you want to create tags to make your workspace easy to organize,
select Next: Tags > and enter your tag names.
19. When you're done, select Review + create.
20. Wait a bit for the validation process to complete. When it's done, select Create to
deploy your app group.
The deployment process will do the following things for you:
Create the RemoteApp app group.

Add your selected apps to the app group.
Publish the app group published to users and user groups you selected.
Register the app group, if you chose to do so.
Create a link to an Azure Resource Manager template based on your configuration
that you can download and save for later.
） Important
You can only create 500 application groups for each Azure Active Directory tenant.
We added this limit because of service limitations for retrieving feeds for our users.
This limit doesn't apply to app groups created in Azure Virtual Desktop (classic).
Edit or remove an app

To edit or remove an app from an app group:
７ Note
If you're signing in to the US Gov portal, go to https://portal.azure.us/

instead.
3. You can either add an application group directly or from an existing host pool by
choosing one of the following options:
To add a new application group directly, select Application groups in the

menu on the left side of the page, then select the app group you want to
edit.
To edit an app group in an existing host pool, select Host pools in the menu
on the left side of the screen, select the name of the host pool, then select
Application groups in the menu that appears on the left side of the screen,
and then select the app group you want to edit.
4. Select Applications in the menu on the left side of the page.
5. If you want to remove an application, select the check box next to the application,
then select Remove from the menu on the top of the page.
6. If you want to edit the details of an application, select the application name. This
will open up the editing menu.
7. When you're done making changes, select Save.
Next steps
In this tutorial, you learned how to create an app group, populate it with RemoteApp
programs, and assign users to the app group. To learn how to create a validation host
pool, see the following tutorial. You can use a validation host pool to monitor service
updates before rolling them out to your production environment.
Create a host pool to validate service updates
 Documentation

production.

examples.
Configure Azure Virtual Desktop load-balancing - Azure

How to configure the load-balancing method for a Azure Virtual Desktop environment.



Show 5 more
Manage app groups using PowerShell or
the Azure CLI
） Important
The default app group created for a new Azure Virtual Desktop host pool also publishes
the full desktop. In addition, you can create one or more RemoteApp application groups
for the host pool. Follow this tutorial to create a RemoteApp app group and publish
individual Start menu apps.
＂ Create a RemoteApp group.

＂ Grant access to RemoteApp programs.
Prerequisites
Azure PowerShell
This article assumes you've followed the instructions in Set up the PowerShell
module to set up your PowerShell module and sign in to your Azure account.
Create a RemoteApp group

Azure PowerShell
To create a RemoteApp group with PowerShell:
1. Run the following PowerShell cmdlet to create a new empty RemoteApp app
group.
PowerShell
New-AzWvdApplicationGroup -Name <appgroupname> -ResourceGroupName
<resourcegroupname> -ApplicationGroupType "RemoteApp" -
HostPoolArmPath
'/subscriptions/SubscriptionId/resourcegroups/ResourceGroupName/pro
viders/Microsoft.DesktopVirtualization/hostPools/HostPoolName'-
Location <azureregion>
2. (Optional) To verify that the app group was created, you can run the following
cmdlet to see a list of all app groups for the host pool.
PowerShell
Get-AzWvdApplicationGroup -Name <appgroupname> -ResourceGroupName

<resourcegroupname>
3. Run the following cmdlet to get a list of Start menu apps on the host pool's
virtual machine image. Write down the values for FilePath, IconPath,
IconIndex, and other important information for the application that you want
to publish.
PowerShell
Get-AzWvdStartMenuItem -ApplicationGroupName <appgroupname> -

ResourceGroupName <resourcegroupname> | Format-List | more
The output should show all the Start menu items in a format like this:
PowerShell
AppAlias : access
CommandLineArgument :
FilePath : C:\Program Files\Microsoft

Office\root\Office16\MSACCESS.EXE
FriendlyName :
IconIndex : 0
IconPath : C:\Program Files\Microsoft

Office\Root\VFS\Windows\Installer\{90160000-000F-0000-1000-
0000000FF1CE}\accicons.exe
Id :
/subscriptions/resourcegroups/providers/Microsoft.DesktopVirtualiza
tion/applicationgroups/startmenuitems/Access
Name : 0301RAG/Access
Type :
Microsoft.DesktopVirtualization/applicationgroups/startmenuitems
AppAlias : charactermap
FilePath : C:\windows\system32\charmap.exe
FriendlyName :
IconIndex : 0
IconPath : C:\windows\system32\charmap.exe
Id :
/subscriptions/resourcegroups/providers/Microsoft.DesktopVirtualiza
tion/applicationgroups/startmenuitems/Character Map
Name : 0301RAG/Character Map
Type :
Microsoft.DesktopVirtualization/applicationgroups/startmenuitems
4. Run the following cmdlet to install the application based on AppAlias .

AppAlias becomes visible when you run the output from step 3.
PowerShell
New-AzWvdApplication -AppAlias <appalias> -GroupName <appgroupname>

-Name <remoteappname> -ResourceGroupName <resourcegroupname> -
CommandLineSetting <DoNotAllow|Allow|Require>
5. (Optional) Run the following cmdlet to publish a new RemoteApp program to

the application group created in step 1.
PowerShell
New-AzWvdApplication -GroupName <appgroupname> -Name

<remoteappname> -ResourceGroupName <resourcegroupname> -Filepath
<filepath> -IconPath <iconpath> -IconIndex <iconindex> -
CommandLineSetting <DoNotAllow|Allow|Require>
6. To verify that the app was published, run the following cmdlet.
PowerShell
Get-AzWvdApplication -GroupName <appgroupname> -ResourceGroupName

<resourcegroupname>
7. Repeat steps 1–5 for each application that you want to publish for this app
group.
8. Run the following cmdlet to grant users access to the RemoteApp programs in
the app group.
PowerShell
New-AzRoleAssignment -SignInName <userupn> -RoleDefinitionName

"Desktop Virtualization User" -ResourceName <appgroupname> -
ResourceGroupName <resourcegroupname> -ResourceType
Next steps
If you came to this How-to guide from our tutorials, check out Create a host pool to
validate service updates. You can use a validation host pool to monitor service updates
before rolling them out to your production environment.
 Documentation
Use Azure CLI and Azure PowerShell with Azure Virtual Desktop
Learn about Azure CLI and Azure PowerShell with Azure Virtual Desktop and some useful example
commands you can run.
Az.DesktopVirtualization Module
Microsoft Azure PowerShell: DesktopVirtualization cmdlets
Add session hosts to a host pool - Azure Virtual Desktop

Learn how to add session hosts virtual machines to a host pool in Azure Virtual Desktop.
Create Azure Virtual Desktop host pool - Azure

How to create a host pool in Azure Virtual Desktop with PowerShell or the Azure CLI.
Azure Virtual Desktop PowerShell - Azure

How to troubleshoot issues with PowerShell when you set up a Azure Virtual Desktop environment.
Set up Start VM on Connect for Azure Virtual Desktop

How to set up the Start VM on Connect feature for Azure Virtual Desktop to turn on session host
virtual machines only when they're needed.

Show 5 more
 Training
Learning path
Certification
Publish built-in apps in Azure Virtual
Desktop
） Important
This article will tell you how to publish apps in your Azure Virtual Desktop environment.
Publish built-in apps

To publish a built-in app:
1. Connect to one of the virtual machines in your host pool.
2. Get the PackageFamilyName of the app you want to publish by following the
instructions in this article.
3. Finally, run the following cmdlet with <PackageFamilyName> replaced by the

PackageFamilyName you found in the previous step:
PowerShell
$parameters = @{
Name = '<ApplicationName>'
ResourceGroupName = '<ResourceGroupName>'
ApplicationGroupName = '<ApplicationGroupName>'
FilePath = 'shell:appsFolder\<PackageFamilyName>!App'
CommandLineSetting = '<Allow|Require|DoNotAllow>'
IconIndex = '0'
IconPath = '<IconPath>'
ShowInPortal = $true
New-AzWvdApplication @parameters
７ Note
Azure Virtual Desktop only supports publishing apps with install locations that
begin with C:\Program Files\WindowsApps .
Update app icons

After you publish an app, it will have the default Windows app icon instead of its regular
icon picture. To change the icon to its regular icon, put the image of the icon you want
on a network share. Supported image formats are PNG, BMP, GIF, JPG, JPEG, and ICO.
Publish Microsoft Edge

To publish Microsoft Edge with the default homepage, run this cmdlet:
PowerShell
$parameters = @{
Name = '<ApplicationName>'
ResourceGroupName = '<ResourceGroupName>'
ApplicationGroupName = '<ApplicationGroupName>'
FilePath =
'shell:Appsfolder\Microsoft.MicrosoftEdge_8wekyb3d8bbwe!MicrosoftEdge'
CommandLineSetting = '<Allow|Require|DoNotAllow>'
IconIndex = '0'
IconPath =
'C:\Windows\SystemApps\Microsoft.MicrosoftEdge_8wekyb3d8bbwe\microsoftedge'
ShowInPortal = $true
New-AzWvdApplication @parameters
Next steps
Learn about how to configure feeds to organize how apps are displayed for users
at Customize feed for Azure Virtual Desktop users.
Learn about the MSIX app attach feature at Set up MSIX app attach.
 Documentation

Troubleshoot RDP Shortpath for public networks - Azure Virtual Desktop

Learn how to troubleshoot RDP Shortpath for public networks for Azure Virtual Desktop, which
establishes a UDP-based transport between a Remote Desktop client and session host.
Azure Virtual Desktop personal desktop assignment type - Azure

How to configure automatic or direct assignment for an Azure Virtual Desktop personal desktop host
pool.





configure settings.
Show 5 more
 Training

Install and configure apps on a session host - Training
Install and configure apps on a session host
Set up MSIX app attach with the Azure
portal
This article will walk you through how to set up MSIX app attach in a Azure Virtual
Requirements
Here's what you need to configure MSIX app attach:
A functioning Azure Virtual Desktop deployment. To learn how to deploy Azure

Virtual Desktop (classic), see Create a tenant in Azure Virtual Desktop. To learn how
to deploy Azure Virtual Desktop with Azure Resource Manager integration, see
Create a host pool with the Azure portal.
An Azure Virtual Desktop host pool with at least one active session host.
The MSIX packaging tool.
An MSIX-packaged application expanded into an MSIX image that's uploaded into
a file share.
A file share in your Azure Virtual Desktop deployment where the MSIX package will
be stored.
The file share where you uploaded the MSIX image must also be accessible to all
virtual machines (VMs) in the host pool. Users will need read-only permissions to
access the image.
All MSIX application packages include a certificate. You're responsible for making
sure the certificates for MSIX applications are trusted in your environment.
Turn off automatic updates for MSIX app attach

applications
Before you get started, you must disable automatic updates for MSIX app attach
applications. To disable automatic updates, you'll need to run the following commands
in an elevated command prompt:
rem Disable Store auto update:
reg add HKLM\Software\Policies\Microsoft\WindowsStore /v AutoDownload /t

REG_DWORD /d 2 /f
Schtasks /Change /Tn "\Microsoft\Windows\WindowsUpdate\Scheduled Start"

/Disable
rem Disable Content Delivery auto download apps that they want to promote to
users:
reg add
HKCU\Software\Microsoft\Windows\CurrentVersion\ContentDeliveryManager /v
PreInstalledAppsEnabled /t REG_DWORD /d 0 /f
reg add
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\ContentDeliveryManager\Debug
/v ContentDeliveryAllowedOverride /t REG_DWORD /d 0x2 /f
Add an MSIX image to the host pool

Next you'll need to add the MSIX image to your host pool.
To add the MSIX image:
1. Open the Azure portal.
2. Enter Azure Virtual Desktop into the search bar, then select the service name.
3. Select the host pool where you plan to put the MSIX apps.
4. Select MSIX packages to open the data grid with all MSIX packages currently
added to the
host pool.
5. Select + Add to open the Add MSIX package tab.
6. In the Add MSIX package tab, enter the following values:
For MSIX image path, enter a valid UNC path pointing to the MSIX image on
the file share. (For example,
\\storageaccount.file.core.windows.net\msixshare\appfolder\MSIXimage.vhd .
) When you're done, select Add to interrogate the MSIX container to check if
the path is valid.
For MSIX package, select the relevant MSIX package name from the drop-
down menu. This menu will only be populated if you've entered a valid image
path in MSIX image path.
For Package applications, make sure the list contains all MSIX applications
you want to be available to users in your MSIX package.
Optionally, enter a Display name if you want your package to have a more
user-friendly in your user deployments.
Make sure the Version has the correct version number.
Select the Registration type you want to use. Which one you use depends on
your needs:
On-demand registration postpones the full registration of the MSIX

application until the user starts the application. This is the registration type
we recommend you use.
Log on blocking only registers while the user is signing in. We don't
recommend this type because it can lead to longer sign-in times for users.
7. For State, select your preferred state.
The Active status lets users interact with the package.

The Inactive status causes Azure Virtual Desktop to ignore the package and
not deliver it to users.
8. When you're done, select Add.
Publish MSIX apps to an application group

Next, you'll need to publish the apps to an application group. You'll need to do this for
both desktop and remote app application groups.
To publish the apps:
1. In the Azure Virtual Desktop resource provider, select the Application groups tab.
2. Select the application group you want to publish the apps to.
７ Note
MSIX applications can be delivered with MSIX app attach to both remote app
and desktop app groups. When a MSIX package is assigned to a remote app
group and desktop app group from the same host pool the desktop app
group will be displayed in the feed.
3. Once you're in the app group, select the Applications tab. The Applications grid
will display all existing apps within the app group.
4. Select + Add to open the Add application tab.
5. For Application source, choose the source for your application.
If you're using a Desktop app group, choose MSIX package.
If you're using a remote app group, choose one of the following options:
Start menu
App path
MSIX package
For Application name, enter a descriptive name for the application.
You can also configure the following optional features:
For Display name, enter a new name for the package that your users will see.
For Description, enter a short description of the app package.
If you're using a remote app group, you can also configure these options:
Icon path
Icon index
6. When you're done, select Save.
Assign a user to an app group

After assigning MSIX apps to an app group, you'll need to grant users access to them.
You can assign access by adding users or user groups to an app group with published
MSIX applications. Follow the instructions in Manage app groups with the Azure portal
to assign your users to an app group.
Change MSIX package state

Next, you'll need to change the MSIX package state to either Active or Inactive,
depending on what you want to do with the package. Active packages are packages
your users can interact with once they're published. Inactive packages are ignored by
Azure Virtual Desktop, so your users can't interact with the apps inside.
Change state with the Applications list

To change the package state with the Applications list:
1. Go to your host pool and select MSIX packages. You should see a list of all existing
MSIX packages within the host pool.
2. Select the MSIX packages whose states you need to change, then select Change
state.
Change state with update package

To change the package state with an update package:
1. Go to your host pool and select MSIX packages. You should see a list of all existing
MSIX packages within the host pool.
2. Select the name of the package whose state you want to change from the MSIX
package list. This will open the Update package tab.
3. Toggle the State switch to either Inactive or Active, then select Save.
Change MSIX package registration type

To change the package's registration type:
1. Select MSIX packages. You should see a list of all existing MSIX packages within
the host pool.
2. Select Package name in the MSIX packages grid this will open the blade to update
the package.
3. Toggle the Registration type via the On-demand/Log on blocking button as

desired and select Save.
Remove an MSIX package

To remove an MSIX package from your host pool:
1. Select MSIX packages. You should see a list of all existing MSIX packages within
the host pool.
2. Select the ellipsis on the right side the name of the package you want to delete,
then select Remove.
Remove MSIX apps

To remove individual MSIX apps from your package:
1. Go to the host pool and select Application groups.
2. Select the application group you want to remove MSIX apps from.
3. Open the Applications tab.
4. Select the app you want to remove, then select Remove.
Next steps
Ask our community questions about this feature at the Azure Virtual Desktop
TechCommunity .
feedback hub .
Here are some other articles you might find helpful:

MSIX app attach FAQ
 Documentation
Azure Virtual Desktop prepare MSIX app attach image - Azure

How to create an MSIX app attach image for a Azure Virtual Desktop host pool.
Azure Virtual Desktop MSIX app attach FAQ - Azure

Frequently asked questions about MSIX app attach for Azure Virtual Desktop.
Configure Azure Virtual Desktop MSIX app attach PowerShell scripts - Azure
How to create PowerShell scripts for MSIX app attach for Azure Virtual Desktop.
Create a file share for MSIX app attach - Azure Virtual Desktop
How to set up a file share for MSIX app attach for Azure Virtual Desktop.
Using MSIXMGR tool - Azure

How to use the MSIXMGR tool for Azure Virtual Desktop.
Azure Virtual Desktop MSIX app attach overview - Azure

What is MSIX app attach? Find out in this article.
Azure Virtual Desktop MSIX app attach glossary - Azure

A glossary of MSIX app attach terms and concepts.
Azure Virtual Desktop MSIX app attach PowerShell - Azure

How to set up MSIX app attach for Azure Virtual Desktop using PowerShell.
Show 5 more
 Training

Deploy applications by using MSIX app attach for Azure Virtual Desktop - Training
Learn how to deliver applications by using MSIX app attach. MSIX app attach is an application
delivery technology that separates applications and their state from the operating system and
assigns applications to users dynamically.
Set up MSIX app attach using
PowerShell
In addition to the Azure portal, you can also set up MSIX app attach manually with
PowerShell. This article will walk you through how to use PowerShell to set up MSIX app
attach.
Requirements
Here's what you need to configure MSIX app attach:

A Azure Virtual Desktop host pool with at least one active session host.
A Desktop remote app group.
The MSIX packaging tool.
An MSIX-packaged application expanded into an MSIX image that's uploaded into

a file share.
A file share in your Azure Virtual Desktop deployment where the MSIX package will
be stored.
The file share where you uploaded the MSIX image must also be accessible to all
virtual machines (VMs) in the host pool. Users will need read-only permissions to
access the image.
Download and install PowerShell Core.
Download the public preview Azure PowerShell module and expand it to a local
folder.
Install the Azure module by running the following cmdlet:
PowerShell
Install-Module -Name Az -Force
Sign in to Azure and import the module

Once you've got all the requirements ready, open PowerShell core in an elevated
command prompt and run this cmdlet:
PowerShell
Connect-AzAccount
After you run it, authenticate your account using your credentials. In this case, you might
be asked for a device URL or a token.
Import the Az.WindowsVirtualDesktop module

You'll need the Az.DesktopVirtualization module to follow the instructions in this article.
７ Note
For the public preview, we will provide the module as separate ZIP files that you
must manually import.
Before you start, you can run the following cmdlet to see if the Az.DesktopVirtualization
module is already installed on your session or VM:
PowerShell
Get-Module | Where-Object { $_.Name -Like "desktopvirtualization" }
If you wan to uninstall an existing copy of the module and start over, run this cmdlet:
PowerShell
Uninstall-Module Az.DesktopVirtualization
If the module is blocked on your VM, run this cmdlet to unblock it:
PowerShell
Unblock-File "<path>\Az.DesktopVirtualization.psm1"
With that cleanup out of the way, it's time to import the module.
1. Run the following cmdlet, then press the R key when prompted to agree to run the
custom code.
PowerShell
Import-Module -Name "<path>\Az.DesktopVirtualization.psm1" -Verbose
2. Once you've run the import cmdlet, check to see if it has the cmdlets for MSIX by
running the following cmdlet:
PowerShell
Get-Command -Module Az.DesktopVirtualization | Where-Object { $_.Name -

match "MSIX" }
If the cmdlets are there, the output should look like this:
PowerShell
CommandType Name
Version Source
----------- ---- ----

--- ------
Function Expand-AzWvdMsixImage 0.0

Az.DesktopVirtualization
Function Get-AzWvdMsixPackage 0.0

Function New-AzWvdMsixPackage 0.0

Function Remove-AzWvdMsixPackage 0.0

Function Update-AzWvdMsixPackage 0.0

If you don't see this output, close all PowerShell and PowerShell Core sessions and
try again.
Set up helper variables

Once you've imported the module, you'll need to set up the helper variables. The
following examples will show you how to do each one.
To get your subscription ID:
PowerShell
Get-AzContext -ListAvailable | fl
To select the context of an Azure tenant and subscription with a name:
PowerShell
$obj = Select-AzContext -Name "<Name>"
To set the subscription variable:
PowerShell
$subId = $obj.Subscription.Id
To set the workspace name:
PowerShell
$ws = "<WorksSpaceName>"
To set the host pool name:
PowerShell
$hp = "<HostPoolName>"
To set up the resource group where the session host VMs are configured:
PowerShell
$rg = "<ResourceGroupName>"
And finally, to confirm you've correctly set all the variables:
PowerShell
Get-AzWvdWorkspace -Name $ws -ResourceGroupName $rg -SubscriptionId $subID
Add an MSIX package to a host pool

Once you've set everything up, it's time to add the MSIX package to a host pool. To do
that, you'll first need to get UNC path to the MSIX image.
Using the UNC path, run this cmdlet to expand the MSIX image:
PowerShell
$obj = Expand-AzWvdMsixImage -HostPoolName $hp -ResourceGroupName $rg -

SubscriptionId $subID -Uri <UNCPath>
Run this cmdlet to add the MSIX package to your desired host pool:
PowerShell
New-AzWvdMsixPackage -HostPoolName $hp -ResourceGroupName $rg -

SubscriptionId $subId -PackageAlias $obj.PackageAlias -DisplayName
<DisplayName> -ImagePath <UNCPath> -IsActive:$true
Once you're done, confirm the package was created with this cmdlet:
PowerShell
Get-AzWvdMsixPackage -HostPoolName $hp -ResourceGroupName $rg -

SubscriptionId $subId | Where-Object {$_.PackageFamilyName -eq
$obj.PackageFamilyName}
Remove an MSIX package from a host pool

To remove a package from a host pool:
Get a list of all packages associated with a host pool with this cmdlet, then find the
name of the package you want to remove in the output:
PowerShell

SubscriptionId $subId
Alternatively, you can also get a particular package based on its display name with this
cmdlet:
PowerShell

SubscriptionId $subId | Where-Object { $_.Name -like "Power" }
To remove the package, run this cmdlet:
PowerShell
Remove-AzWvdMsixPackage -FullName $obj.PackageFullName -HostPoolName $hp -

ResourceGroupName $rg
Publish MSIX apps to an app group

You can only follow the instructions in this section if you've finished following the
instructions in the previous sections. If you have a host pool with an active session host,
at least one Desktop app group, and have added an MSIX package to the host pool,
you're ready to go.
To publish an app from the MSIX package to an app group, you'll need to find its name,
then use that name in the publishing cmdlet.
To publish an app:
Run this cmdlet to list all available app groups:
PowerShell
Get-AzWvdApplicationGroup -ResourceGroupName $rg -SubscriptionId $subId
When you've found the name of the app group you want to publish apps to, use its
name in this cmdlet:
PowerShell
$grName = "<AppGroupName>"
Finally, you'll need to publish the app.
To publish MSIX application to a desktop app group, run this cmdlet:
PowerShell
New-AzWvdApplication -ResourceGroupName $rg -SubscriptionId $subId -
Name PowerBi -ApplicationType MsixApplication -ApplicationGroupName
$grName -MsixPackageFamilyName $obj.PackageFamilyName -
CommandLineSetting 0
To publish the app to a remote app group, run this cmdlet instead:
PowerShell
New-AzWvdApplication -ResourceGroupName $rg -SubscriptionId $subId -

Name PowerBi -ApplicationType MsixApplication -ApplicationGroupName
$grName -MsixPackageFamilyName $obj.PackageFamilyName -
CommandLineSetting 0 -MsixPackageApplicationId
$obj.PackageApplication.AppId
７ Note
If a user is assigned to both a remote app group and a desktop app group in the
same host pool, when the user connects to their remote desktop, they will see
MSIX apps from both groups.
Next steps
TechCommunity .
feedback hub .

MSIX app attach FAQ
Test and troubleshoot MSIX packages
with MSIX app attach
This article will show you how to use MSIX app attach to mount MSIX packages outside
of Azure Virtual Desktop for testing and troubleshooting.
To use MSIX app attach with Azure Virtual Desktop, you can use the Azure portal or
Azure PowerShell to add and publish applications.
Prerequisites
Before you can use MSIX app attach to follow the directions in this article, you'll need
the following things:
A Windows 10 or 11 client.
An application you've expanded from MSIX format into app attach format. To learn
how to expand an MSIX application, see Using the MSIXMGR tool.
If you're using a CimFS image, you'll need to install the following module before
you can get started:
PowerShell
Install-Module CimDiskImage
Import-Module CimDiskImage
These instructions don't require an Azure Virtual Desktop deployment because they
describe a process for testing outside of Azure Virtual Desktop.
７ Note
Microsoft Support doesn't currently support this CimFS disk image module, so if
you run into any problems, you'll need to submit a request on the module's GitHub
repository .
Phases of MSIX app attach

To use MSIX packages outside of Azure Virtual Desktop, there are four distinct phases
that you must perform in the following order, otherwise it won't work:
1. Stage
2. Register
3. Deregister
4. Destage
Staging and destaging are machine-level operations, while registering and deregistering
are user-level operations. The commands you'll need to use will vary based on which
version of PowerShell you're using and whether your disk images are in CimFS or
VHD(X) format.
７ Note
All MSIX application packages include a certificate. You're responsible for making
sure the certificates for MSIX applications are trusted in your environment.
Stage the MSIX package

The staging script prepares your machine to receive the MSIX package and mounts the
relevant package to your machine. You'll only need to run the following commands once
per machine.
However, if you're using an image in CimFS format or a version of PowerShell greater

than 5.1, the instructions will look a bit different. Later versions of PowerShell are multi-
platform, which means the Windows application parts are split off into their own
package called Windows Runtime. You'll need to use a slightly different version of the
commands to install a package with a multi-platform version of PowerShell.
You'll need to run PowerShell as an Administrator to run the commands in the following
sections.
Next, you'll need to decide which instructions you need to follow to stage your package
based on which version of PowerShell you're using.
PowerShell 6 and later

To stage packages at boot using PowerShell 6 or later, you'll need to run the following
commands before the staging operations to bring the capabilities of the Windows
Runtime package you previously installed into the PowerShell session.
1. First, run this command to get the Windows Runtime Package:
PowerShell
#Required for PowerShell 6 and later
$nuGetPackageName = 'Microsoft.Windows.SDK.NET.Ref'
Register-PackageSource -Name MyNuGet -Location

https://www.nuget.org/api/v2 -ProviderName NuGet
Find-Package $nuGetPackageName | Install-Package
2. Next, run the following command to make the Windows Runtime components
available in your PowerShell session.
PowerShell
#Required for PowerShell 6 and later
$nuGetPackageName = 'Microsoft.Windows.SDK.NET.Ref'
$winRT = Get-Package $nuGetPackageName
$dllWinRT = Get-Childitem (Split-Path -Parent $winRT.Source) -Recurse -

File WinRT.Runtime.dll
$dllSdkNet = Get-Childitem (Split-Path -Parent $winRT.Source) -Recurse

-File Microsoft.Windows.SDK.NET.dll
Add-Type -AssemblyName $dllWinRT.FullName
Add-Type -AssemblyName $dllSdkNet.FullName
PowerShell 5.1 and earlier

To stage packages at boot with PowerShell version 5.1 or earlier, run this command:
PowerShell
#Required for PowerShell versions less than or equal to 5.1
[Windows.Management.Deployment.PackageManager,Windows.Management.Deployment,
ContentType=WindowsRuntime] | Out-Null
Add-Type -AssemblyName System.Runtime.WindowsRuntime
Mount your disk image

Now that you've prepared your machine to stage MSIX app attach packages, you'll need
to mount your disk image. This process will vary depending on whether you're using the
VHD(X) or CimFs format for your disk image.
７ Note
Make sure to record the the Device Id for each application in the command output.
You'll need this information to follow directions later in this article.
CimFS
To mount a CimFS disk image:
1. Run this command:
PowerShell
$diskImage = "<UNC path to the Disk Image>"
$mount = Mount-CimDiskimage -ImagePath $diskImage -PassThru -

NoMountPath
#We can now get the Device Id for the mounted volume, this will be
useful for the destage step.
Write-Output $mount.DeviceId
2. When you're done, proceed to Finish staging your disk image.
Finish staging your disk image

Finally, you'll need to run the following command for all image formats to complete
staging the disk image. This command will use the $mount variable you created when
you mounted your disk image in the previous section.
PowerShell
#Once the volume is mounted we can retrieve the application information
$manifest = Get-Childitem -LiteralPath $mount.DeviceId -Recurse -File

AppxManifest.xml
$manifestFolder = $manifest.DirectoryName
#We can now get the MSIX package full name, this will be needed for later
steps.
$msixPackageFullName = $manifestFolder.Split('\')[-1]
Write-Output $msixPackageFullName
#We need to create an absolute uri for the manifest folder for the Package
Manager API
$folderUri = $maniFestFolder.Replace('\\?\','file:\\\')
$folderAbsoluteUri = ([Uri]$folderUri).AbsoluteUri
#Package Manager will now use the absolute uri to stage the application
package
$asTask = ([System.WindowsRuntimeSystemExtensions].GetMethods() | Where-

Object { $_.ToString() -eq 'System.Threading.Tasks.Task`1[TResult]
AsTask[TResult,TProgress]
(Windows.Foundation.IAsyncOperationWithProgress`2[TResult,TProgress])' })[0]
$asTaskAsyncOperation =
$asTask.MakeGenericMethod([Windows.Management.Deployment.DeploymentResult],
[Windows.Management.Deployment.DeploymentProgress])
$packageManager = New-Object -TypeName

Windows.Management.Deployment.PackageManager
$asyncOperation = $packageManager.StagePackageAsync($folderAbsoluteUri,
$null, "StageInPlace")
$stagingResult = $asTaskAsyncOperation.Invoke($null, @($asyncOperation))
#You can check the $stagingResult variable to monitor the staging progress
for the application package
Write-Output $stagingResult
Your MSIX package is now ready to be registered.
Register the MSIX package

To register your MSIX package, run the following PowerShell cmdlets with the
placeholder values replaced with values that apply to your environment.
The $msixPackageFullName parameter should be the full name of the package from the
previous section, but the format should be similar to the following example:
Publisher.Application_version_Platform__HashCode .
If you didn't retrieve the parameter after staging your app, you can also find it as the
folder name for the app itself in C:\Program Files\WindowsApps.
PowerShell
$msixPackageFullName = "<package full name>"
$manifestPath = Join-Path (Join-Path $Env:ProgramFiles 'WindowsApps') (Join-

Path $msixPackageFullName AppxManifest.xml)
Add-AppxPackage -Path $manifestPath -DisableDevelopmentMode -Register
Now that your MSIX package is registered, your application should be available for use
in your session. You can now open the application for testing and troubleshooting.
Deregister the MSIX package

If you're finished with your package and are ready to remove it, now it's time to
deregister it. In order to deregister, you'll need the $msixPackageFullName parameter
again.
To deregister your package, run the following command after replacing the placeholder
text with the relevant values:
PowerShell
Remove-AppxPackage $msixPackageFullName -PreserveRoamableApplicationData
Destage the MSIX package

To destage your MSIX package, make sure you're running an elevated PowerShell
prompt. You'll need to run the following PowerShell command to get the disk's
DeviceId parameter. Replace the placeholder for $packageFullName with the name of
the package you're testing. In a production deployment, we recommend only running
this command when shutting down your system.
PowerShell
#If you don't know the DeviceId of the mounted disk, you can find it using
the following code.
$appPath = Join-Path (Join-Path $Env:ProgramFiles 'WindowsApps')

$msixPackageFullName
$folderInfo = Get-Item $appPath
$DeviceId = '\\?\' + $folderInfo.LinkTarget.Split('\')[0] +'\'
Write-Output $DeviceId #Save this for later
Remove-AppxPackage -AllUsers -Package $msixPackageFullName
Remove-AppxPackage -Package $msixPackageFullName
Dismount the disks from the system

To finish the destaging process, you'll need to dismount the disks from the system. The
command you'll need to use depends on the format of your disk image.
CimFS
If your image is in CimFS format, run this cmdlet:

PowerShell
DisMount-CimDiskimage -DeviceId $DeviceId
Once you finish dismounting your disks, you've safely removed your MSIX package.
Set up simulation scripts for the MSIX app

attach agent
If you want to add and remove MSIX packages automatically, you can use the
PowerShell commands in this article to create scripts that run at startup, logon, logoff,
and shutdown. To learn more about these types of scripts, see Using startup, shutdown,
logon, and logoff scripts in Group Policy.
Each of these automatic scripts runs one phase of the app attach scripts:
The startup script runs the stage script.

The logon script runs the register script.
The logoff script runs the deregister script.
The shutdown script runs the destage script.
７ Note
You can run the task scheduler with the stage script. To run the script, set the task
trigger to When the computer starts, then enable Run with highest privileges.
Use packages offline

If you're using packages from the Microsoft Store for Business or the Microsoft Store
for Education within your network or on devices that aren't connected to the internet,
you need to get the package licenses from the Microsoft Store and install them on your
device to successfully run the app. If your device is online and can connect to the
Microsoft Store for Business, the required licenses should download automatically, but if
you're offline, you'll need to set up the licenses manually.
To install the license files, you'll need to use a PowerShell script that calls the
MDM_EnterpriseModernAppManagement_StoreLicenses02_01 class in the WMI Bridge
Provider.
Here's how to set up the licenses for offline use:

1. Download the app package, licenses, and required frameworks from the Microsoft
Store for Business. You need both the encoded and unencoded license files.
Detailed download instructions can be found here.
2. Update the following variables in the script for step 3:
$contentID is the ContentID value from the Unencoded license file (.xml). You
can open the license file in a text editor of your choice.

$licenseBlob is the entire string for the license blob in the Encoded license
file (.bin). You can open the encoded license file in a text editor of your
choice.
3. Run the following script from PowerShell running as an administrator. A good

place to perform license installation is at the end of the staging phase because at
that point you also need to run PowerShell as an administrator.
PowerShell
$namespaceName = "root\cimv2\mdm\dmmap"
$className = "MDM_EnterpriseModernAppManagement_StoreLicenses02_01"
$methodName = "AddLicenseMethod"
$parentID =
"./Vendor/MSFT/EnterpriseModernAppManagement/AppLicenses/StoreLicenses"
#TODO - Update $contentID with the ContentID value from the unencoded
license file (.xml)
$contentID = "{'ContentID'_in_unencoded_license_file}"
#TODO - Update $licenseBlob with the entire String in the encoded

license file (.bin)
$licenseBlob = "{Entire_String_in_encoded_license_file}"
$session = New-CimSession
#The final string passed into the AddLicenseMethod should be of the

form <License Content="encoded license blob" />
$licenseString = '<License Content='+ '"' + $licenseBlob +'"' + ' />'
$params = New-Object
Microsoft.Management.Infrastructure.CimMethodParametersCollection
$param =
[Microsoft.Management.Infrastructure.CimMethodParameter]::Create("param
",$licenseString ,"String", "In")
$params.Add($param)
try
$instance = New-CimInstance -Namespace $namespaceName -ClassName

$className -Property @{ParentID=$parentID;InstanceID=$contentID}
$session.InvokeMethod($namespaceName, $instance, $methodName,

$params)
catch [Exception]
write-host $_ | out-string
Demonstration scripts
You can find demonstration scripts for all four stages of the MSIX App Attach package
process and syntax help for how to use them at our template . These scripts will work
with any version of PowerShell and any disk image format.
Next steps
If you have any questions, you can ask them at the Azure Virtual Desktop
TechCommunity .
feedback hub .
Prepare an MSIX image for Azure Virtual
Desktop
MSIX app attach is an application layering solution that allows you to dynamically attach
apps from an MSIX package to a user session. The MSIX package system separates apps
from the operating system, making it easier to build images for virtual machines. MSIX
packages also give you greater control over which apps your users can access in their
virtual machines. You can even separate apps from the master image and give them to
users later.
Instructions on how to convert a desktop installer (such as MSI, EXE, ClickOnce, App-V,
or Script) to MSIX are available in Create an MSIX package from any desktop installer
(MSI, EXE, ClickOnce, or App-V).
Create a VHD or VHDX package for MSIX

MSIX packages need to be in a VHD or VHDX format to work properly. This means that,
to get started, you'll need to create a VHD or VHDX package.
７ Note
If you haven't already, make sure you enable Hyper-V by following the instructions
in Install Hyper-V on Windows 10.
To create a VHD or VHDX package for MSIX:
1. First, open PowerShell.
2. Next, run the following cmdlet to create a VHD:
PowerShell
New-VHD -SizeBytes <size>MB -Path c:\temp\<name>.vhd -Dynamic -

Confirm:$false
７ Note
Make sure the VHD is large enough to hold the expanded MSIX package.
3. Run the following cmdlet to mount the VHD you just created:
PowerShell
$vhdObject = Mount-VHD c:\temp\<name>.vhd -Passthru
4. Next, run this cmdlet to initialize the mounted VHD:
PowerShell
$disk = Initialize-Disk -Passthru -Number $vhdObject.Number
5. After that, run this cmdlet to create a new partition for the initialized VHD:
PowerShell
$partition = New-Partition -AssignDriveLetter -UseMaximumSize -

DiskNumber $disk.Number
6. Run this cmdlet to format the partition:
PowerShell
Format-Volume -FileSystem NTFS -Confirm:$false -DriveLetter

$partition.DriveLetter -Force
7. Finally, create a parent folder on the mounted VHD. This step is required because
the MSIX package must have a parent folder to work properly. It doesn't matter
what you name the parent folder, so long as the parent folder exists.
Expand MSIX
After that, you'll need to expand the MSIX image by "unpacking" its files into the VHD.
To expand the MSIX image:
1. Download the msixmgr tool and save the .zip folder to a folder within a session
host VM.
2. Unzip the msixmgr tool .zip folder.
3. Put the source MSIX package into the same folder where you unzipped the
msixmgr tool.
4. Open a command prompt as Administrator and navigate to the folder where you
downloaded and unzipped the msixmgr tool.
5. Run the following cmdlet to unpack the MSIX into the VHD you created in the
previous section.
PowerShell
msixmgr.exe -Unpack -packagePath <package>.msix -destination "f:\<name

of folder you created earlier>" -applyacls
The following message should appear after you're done unpacking:
Successfully unpacked and applied ACLs for package: <package name>.msix
７ Note
If you're using packages from the Microsoft Store for Business or Education
on your network or on devices not connected to the internet, you'll need to
download and install package licenses from the Microsoft Store to run the
apps. To get the licenses, see Use packages offline.
6. Go to the mounted VHD and open the app folder to make sure the package
contents are there.
7. Unmount the VHD.
Upload MSIX image to share

After you've created the MSIX package, you'll need to upload the resulting VHD, VHDX,
or CIM file to a share where your users' virtual machines can access it.
Next steps
TechCommunity .
feedback hub .

MSIX app attach FAQ
Set up a file share for MSIX app attach
For a user to access MSIX images, the images must be stored on a network share. In this
article, you'll learn how to set up a file share for MSIX app attach.
MSIX app attach doesn't have dependencies on the type of storage fabric the file share
uses. The considerations for the MSIX app attach share are same as the considerations
for an FSLogix share. To learn more about storage requirements, see Storage options for
FSLogix profile containers in Azure Virtual Desktop.
Performance requirements
MSIX app attach image size limits for your system depend on:
The storage type you're using to store the VHD or VHDX files.
The size limitations of the VHD, VHDX or CIM files and the file system.
The following table gives an example of how many resources a single 1-GB MSIX image
with one MSIX app inside of it requires for each VM:
Resource Requirements
Steady state IOPs One IOP
Machine boot sign-in 10 IOPs
Latency 400 ms
Requirements can vary widely depending how many MSIX-packaged applications are
stored in the MSIX image. For larger MSIX images, you'll need to allocate more
bandwidth.
Storage recommendations
Azure offers multiple storage options that can be used for MISX app attach. We
recommend using Azure Files or Azure NetApp Files as those options offer the best
value between cost and management overhead. The article Storage options for FSLogix
profile containers in Azure Virtual Desktop compares the different managed storage
solutions Azure offers in the context of Azure Virtual Desktop.
Optimize MSIX app attach performance
Here are some other things we recommend you do to optimize MSIX app attach
performance:
The storage solution you use for MSIX app attach should be in the same
datacenter location as the session hosts.
To avoid performance bottlenecks, exclude the following VHD, VHDX, and CIM files
from antivirus scans:
<MSIXAppAttachFileShare\>\*.VHD
<MSIXAppAttachFileShare\>\*.VHDX
<MSIXAppAttachFileShare>.CIM
If you're using Azure Files, exclude the following locations from antivirus scans:
\\storageaccount.file.core.windows.net\share*.VHD
\\storageaccount.file.core.windows.net\share*.VHDX
\\storageaccount.file.core.windows.net\share**.CIM
Separate the storage fabrics for MSIX app attach from FSLogix profile containers.
Any disaster recovery plans for Azure Virtual Desktop must include replicating the
MSIX app attach file share in your secondary failover location. To learn more about
disaster recovery, see Set up a business continuity and disaster recovery plan. You'll
also need to ensure your file share path is accessible in the secondary location. You
can use Distributed File System (DFS) Namespaces to provide a single share name
across different file shares.
Configure file share permissions when using

Azure Files
The setup process for MSIX app attach file share is largely the same as the setup process
for FSLogix profile file shares. However, you'll need to assign different permissions. MSIX
app attach requires read-only permissions using the computer account of each session
host to access the file share.
When you store your MSIX applications in Azure Files, you must assign all session host
VMs both storage account role-based access permissions and file share New Technology
File System (NTFS) permissions on the share.
Azure object Required role Role function

Azure object Required role Role function
Session hosts (VM Storage File Data SMB Allows for read access to Azure File Share over
computer objects) Share Reader SMB
Admins on File Storage File Data SMB Allows for read, write, delete, and modify ACLs
Share Share Elevated on files and directories in Azure File Shares
Contributor
To assign session hosts VMs permissions for the storage account and file share:
1. Create an Active Directory Domain Services (AD DS) security group.
2. Add the computer accounts for all session hosts VMs as members of the group.
3. Sync the AD DS group to Azure Active Directory (Azure AD).
4. Create a storage account.
5. Create a file share under the storage account by following the instructions in
Create an Azure file share.
6. Join the storage account to AD DS by following the instructions in Part one: enable
AD DS authentication for your Azure file shares.
7. Assign the synced AD DS group the Storage File Data SMB Share Reader role on
the storage account.
8. Mount the file share to any session host by following the instructions in Part two:
assign share-level permissions to an identity.
9. Grant Modify NTFS permissions on the file share to the AD DS group.
Next steps
Once you're finished, here are some other resources you might find helpful:
Add and publish MSIX app attach packages with the Azure portal
TechCommunity .
feedback hub .
MSIX app attach FAQ
Using the MSIXMGR tool
The MSIXMGR tool is for expanding MSIX-packaged applications into MSIX images. The
tool takes an MSIX-packaged application (.MSIX) and expands it into a VHD, VHDx, or
CIM file. The resulting MSIX image is stored in the Azure Storage account that your
Azure Virtual Desktop deployment uses.This article will show you how to use the
MSIXMGR tool.
７ Note
To guarantee compatibility, make sure the CIM files storing your MSIX images are
generated on a version of Windows that is lower than or equal to the version of
Windows where you are planning to run the MSIX packages. For example, CIM files
generated on Windows 11 may not work on Windows 10.
Requirements
Before you can follow the instructions in this article, you'll need to do the following
things:
Download the MSIXMGR tool

Get an MSIX-packaged application (.MSIX file)
Get administrative permissions on the machine where you'll create the MSIX image
Create an MSIX image

Expansion is the process of taking an MSIX packaged application (.MSIX) and unzipping
it into a MSIX image (.VHD(x) or .CIM file).
To expand an MSIX file:
1. Download the MSIXMGR tool if you haven't already.
2. Unzip MSIXMGR.zip into a local folder.
3. Open a command prompt in elevated mode.
4. Find the local folder from step 2.
5. Run the following command in the command prompt to create an MSIX image.
msixmgr.exe -Unpack -packagePath <path to package> -destination <output

folder> [-applyacls] [-create] [-vhdSize <size in MB>] [-filetype <CIM
| VHD | VHDX>] [-rootDirectory <rootDirectory>]
Remember to replace the placeholder values with the relevant values. For example:
msixmgr.exe -Unpack -packagePath

"C:\Users\%username%\Desktop\packageName_3.51.1.0_x64__81q6ced8g4aa0.ms
ix" -destination "c:\temp\packageName.vhdx" -applyacls -create -vhdSize
200 -filetype "vhdx" -rootDirectory apps
6. Now that you've created the image, go to the destination folder and make sure
you successfully created the MSIX image (.VHDX).
Create an MSIX image in a CIM file

You can also use the command in step 5 to create CIM and VHDX files by replacing the
file type and destination path.
For example, here's how you'd use that command to make a CIM file:

"C:\Users\ssa\Desktop\packageName_3.51.1.0_x64__81q6ced8g4aa0.msix" -
destination "c:\temp\packageName.cim" -applyacls -create -vhdSize 200 -
filetype "cim" -rootDirectory apps
Here's how you'd use that command to make a VHDX:

"C:\Users\ssa\Desktop\packageName_3.51.1.0_x64__81q6ced8g4aa0.msix" -
destination "c:\temp\packageName.vhdx" -applyacls -create -vhdSize 200 -
filetype "vhdx" -rootDirectory apps
７ Note
This command doesn't support package names that are longer than 128 characters
or MSIX image names with spaces between characters.
Next steps
Learn more about MSIX app attach at What is MSIX app attach?
To learn how to set up app attach, check out these articles:
Set up MSIX app attach with the Azure portal

Set up MSIX app attach using PowerShell
Create PowerShell scripts for MSIX app attach
Prepare an MSIX image for Azure Virtual Desktop
Set up a file share for MSIX app attach
If you have questions about MSIX app attach, see our App attach FAQ and App attach
glossary.
Use Microsoft Teams on Azure Virtual
Desktop
Microsoft Teams on Azure Virtual Desktop supports chat and collaboration. With media
optimizations, it also supports calling and meeting functionality. To learn more about
how to use Microsoft Teams in Virtual Desktop Infrastructure (VDI) environments, see
Teams for Virtualized Desktop Infrastructure.
With media optimization for Microsoft Teams, the Remote Desktop client handles audio
and video locally for Teams calls and meetings by redirecting it to the local device. You
can still use Microsoft Teams on Azure Virtual Desktop with other clients without
optimized calling and meetings. Teams chat and collaboration features are supported on
all platforms.
Prerequisites
Before you can use Microsoft Teams on Azure Virtual Desktop, you'll need to do these
things:
Prepare your network for Microsoft Teams.

Install the Remote Desktop client on a Windows 10, Windows 10 IoT Enterprise,
Windows 11, or macOS 10.14 or later device that meets the hardware requirements
for Microsoft Teams.
Connect to an Azure Virtual Desktop session host running Windows 10 or 11
Multi-session or Windows 10 or 11 Enterprise.
The latest version of the Microsoft Visual C++ Redistributable .
Media optimization for Microsoft Teams is only available for the following two clients:
Windows Desktop client for Windows 10 or 11 machines, version 1.2.1026.0 or

later.
macOS Remote Desktop client, version 10.7.7 or later.
For more information about which features Teams on Azure Virtual Desktop supports
and minimum required client versions, see Supported features for Teams on Azure
Virtual Desktop.
Prepare to install the Teams desktop app

This section will show you how to install the Teams desktop app on your Windows 10 or
11 Enterprise multi-session or Windows 10 or 11 Enterprise VM image. To learn more,
check out Install or update the Teams desktop app on VDI.
Enable media optimization for Teams

To enable media optimization for Teams, set the following registry key on the host VM:
1. From the start menu, run Registry Editor as an administrator. Go to

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Teams . Create the Teams key if it doesn't
already exist.
2. Create the following value for the Teams key:
Name Type Data/Value
IsWVDEnvironment DWORD 1
Alternatively, you can create the registry entry by running the following commands from
an elevated PowerShell session:
PowerShell
New-Item -Path "HKLM:\SOFTWARE\Microsoft\Teams" -Force
New-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Teams" -Name

IsWVDEnvironment -PropertyType DWORD -Value 1 -Force
Install the Remote Desktop WebRTC Redirector Service

The Remote Desktop WebRTC Redirector Service is required to run Teams on Azure
Virtual Desktop. To install the service:
1. Sign in to a session host as a local administrator.
2. Download the Remote Desktop WebRTC Redirector Service installer .
3. Open the file that you downloaded to start the setup process.
4. Follow the prompts. Once it's completed, select Finish.
You can find more information about the latest version of the WebSocket service at
What's new in the Remote Desktop WebRTC Redirector Service.
Install Teams on Azure Virtual Desktop

You can deploy the Teams desktop app using a per-machine or per-user installation. To
install Teams on Azure Virtual Desktop:
1. Download the Teams MSI package that matches your environment. We

recommend using the 64-bit installer on a 64-bit operating system.
2. Run one of the following commands to install the MSI to the host VM:
For per-machine installation, run this command:
PowerShell
msiexec /i <path_to_msi> /l*v <install_logfile_name> ALLUSER=1

ALLUSERS=1
This process installs Teams to the %ProgramFiles(x86)% folder on a 64-bit

operating system and to the %ProgramFiles% folder on a 32-bit operating
system. At this point, the golden image setup is complete. Installing Teams
per-machine is required for non-persistent setups.
During this process, you can set the ALLUSER=1 and the ALLUSERS=1
parameters. The following table lists the differences between these two
parameters.
Parameter Purpose
ALLUSER=1 Used in virtual desktop infrastructure (VDI) environments to specify

per-machine installation.
ALLUSERS=1 Used in both non-VDI and VDI environments to make the Teams
Machine-Wide Installer appear in Programs and Features under the
Control Panel and in Apps & Features in Windows Settings. The
installer lets all users with admin credentials uninstall Teams.
When you install Teams with the MSI setting ALLUSER=1, automatic updates
will be disabled. We recommend you make sure to update Teams at least
once a month. To learn more about deploying the Teams desktop app, check
out Deploy the Teams desktop app to the VM.
７ Note
We recommend you use per-machine installation for better centralized

management for both pooled and personal host pool setups.
Users and admins can't disable automatic launch for Teams during sign-
in at this time.
For per-user installation, run the following command:
PowerShell
msiexec /i <path_to_msi> /l*v <install_logfile_name> ALLUSERS=1
This process installs Teams to the %AppData% user folder.
７ Note
Per-user installation only works on personal host pools. If your

deployment uses pooled host pools, we recommend using per-machine
installation instead.
Verify media optimizations loaded

After installing the WebSocket Service and the Teams desktop app, follow these steps to
verify that Teams media optimizations loaded:
1. Quit and restart the Teams application.
2. Select your user profile image, then select About.
3. Select Version.
If media optimizations loaded, the banner will show you Azure Virtual Desktop
Media optimized. If the banner shows you Azure Virtual Desktop Media not
connected, quit the Teams app and try again.
4. Select your user profile image, then select Settings.
If media optimizations loaded, the audio devices and cameras available locally will
be enumerated in the device menu. If the menu shows Remote audio, quit the
Teams app and try again. If the devices still don't appear in the menu, check the
Privacy settings on your local PC. Ensure the under Settings > Privacy > App
permissions - Microphone the setting "Allow apps to access your microphone" is
toggled On. Disconnect from the remote session, then reconnect and check the
audio and video devices again. To join calls and meetings with video, you must
also grant permission for apps to access your camera.
If optimizations don't load, uninstall then reinstall Teams and check again.
Enable registry keys for optional features

If you want to use certain optional features for Teams on Azure Virtual Desktop, you'll
need to enable certain registry keys. The following instructions only apply to Windows
client devices and session host VMs.
Enable hardware encode for teams on Azure Virtual

Desktop
Hardware encode lets you increase video quality for the outgoing camera during Teams
calls. In order to enable this feature, your client will need to be running version 1.2.3213
or later of the Windows Desktop client. You'll need to repeat the following instructions
for every client device.
To enable hardware encode:
1. On your client device, from the start menu, run Registry Editor as an administrator.
2. Go to HKCU\SOFTWARE\Microsoft\Terminal Server Client\Default\AddIns\WebRTC
Redirector .
3. Add the UseHardwareEncoding as a DWORD value.
4. Set the value to 1 to enable the feature.
5. Repeat these instructions for every client device.
Enable content sharing for Teams for Remote App

Enabling content sharing for Teams on Azure Virtual Desktop lets you share your screen
or application window. To enable this feature, your session host VM needs to be running
version 1.31.2211.15001 or later of the WebRTC service and version 1.2.3401 or later of
the Windows Desktop client.
To enable content sharing:
1. On your session host VM, from the start menu, run Registry Editor as an
administrator.
2. Go to HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\AddIns\WebRTC
Redirector\Policy .
3. Add the ShareClientDesktop as a DWORD value.
4. Set the value to 1 to enable the feature.
Disable desktop screen share for Teams for Remote App
You can disable desktop screen sharing for Teams on Azure Virtual Desktop. To enable
this feature, your session host VM needs to be running version 1.31.2211.15001 or later
of the WebRTC service and version 1.2.3401 or later of the Windows Desktop client.
７ Note
You must enable the ShareClientDesktop key before you can use this key.
To disable desktop screen share:
administrator.
Redirector\Policy .
3. Add the DisableRAILScreensharing as a DWORD value.

4. Set the value to 1 to disable desktop screen share.
Disable application window sharing for Teams for Remote

App
You can disable application window sharing for Teams on Azure Virtual Desktop. To
enable this feature, your session host VM needs to be running version 1.31.2211.15001
or later of the WebRTC service and version 1.2.3401 or later of the Windows Desktop
client.
７ Note
You must enable the ShareClientDesktop key before you can use this key.
To disable application window sharing:
administrator.
Redirector\Policy .
3. Add the DisableRAILAppSharing as a DWORD value.
4. Set the value to 1 to disable application window sharing.
Customize Remote Desktop Protocol properties
for a host pool
Customizing a host pool's Remote Desktop Protocol (RDP) properties, such as multi-
monitor experience or enabling microphone and audio redirection, lets you deliver an
optimal experience for your users based on their needs.
Enabling device redirections isn't required when using Teams with media optimization. If
you're using Teams without media optimization, set the following RDP properties to
enable microphone and camera redirection:
audiocapturemode:i:1 enables audio capture from the local device and redirects
audio applications in the remote session.
audiomode:i:0 plays audio on the local computer.
camerastoredirect:s:* redirects all cameras.
To learn more, check out Customize Remote Desktop Protocol properties for a host
pool.
Next steps
See Supported features for Teams on Azure Virtual Desktop for more information about
which features Teams on Azure Virtual Desktop supports and minimum required client
versions.
Learn about the latest version of the WebSocket Service at What's new in the
WebSocket Service for Azure Virtual Desktop.
 Documentation
Supported features for Microsoft Teams on Azure Virtual Desktop - Azure

Supported features for Microsoft Teams on Azure Virtual Desktop.
Troubleshoot Microsoft Teams on Azure Virtual Desktop - Azure

Known issues and troubleshooting instructions for Teams on Azure Virtual Desktop.
Desktop.

How to use multimedia redirection on Azure Virtual Desktop (preview).
Troubleshoot Azure Virtual Desktop connection quality

How to troubleshoot connection quality issues in Azure Virtual Desktop.
Profile Container vs. Office Container - FSLogix

This document is intended to help users understand the difference between using Office Container
and Profile Container

An overview of multimedia redirection on Azure Virtual Desktop (preview).
Azure Virtual Desktop troubleshooting overview - Azure

An overview for troubleshooting issues while setting up an Azure Virtual Desktop environment.
Show 5 more
 Training

Manage team collaboration with Microsoft Teams - Training
Manage team collaboration with Microsoft Teams introduces you to the features and capabilities of
Microsoft Teams, the central hub for team collaboration in Microsoft 365.
Microsoft 365 Certified: Teams Voice Engineer Expert - Certifications
Microsoft Teams voice engineers plan, design, configure, maintain, and troubleshoot an integrated
communications solution at an organization.
Set up Windows Sandbox in Azure
Virtual Desktop
This topic will walk you through how to publish Windows Sandbox for your users in an
Azure Virtual Desktop environment.
Prerequisites
Before you get started, here's what you need to configureWindows Sandbox in Azure
Virtual Desktop:
A working Azure profile that can access the Azure portal.

Azure Virtual Desktop session hosts that supported the nested virtualization
capability. To check if a specific VM size supports nested virtualization, navigate to
the description page matching your VM size from Sizes for virtual machines in
Azure.
Prepare the VHD image for Azure

First, you'll need to create a master VHD image. If you haven't created your master VHD
image yet, go to Prepare and customize a master VHD image and follow the instructions
there. When you're given the option to select an operating system (OS) for your master
image, select either Windows 10 or Windows 11.
When customizing your master image, you'll need to enable the Containers-
DisposableClientVM feature by running the following command:
PowerShell
Enable-WindowsOptionalFeature -FeatureName "Containers-DisposableClientVM" -

All -Online
７ Note
This change will require that you restart the virtual machine.
Once you've uploaded the VHD to Azure, create a host pool that's based on this new
image by following the instructions in the Create a host pool by using the Azure
Marketplace tutorial.
Publish Windows Sandbox on your host pool

Azure portal
To publish Windows Sandbox to your host pool:
1. Sign in to the Azure portal.
2. In the search bar, enter Azure Virtual Desktop and select the matching service
entry.
3. Select Application groups, then select the name of the application group in
the host pool you want to publish Windows Sandbox to.
4. Once you're in the application group, select the Applications tab. The
Applications grid will display all existing apps within the app group.
5. Select + Add to open the Add application tab.
6. For Application source, select File Path.
7. For Application path, enter C:\windows\system32\WindowsSandbox.exe.
8. Enter Windows Sandbox into the Application Name field.
9. When you're done, select Save.
That's it! Leave the rest of the options default. You should now have Windows Sandbox
Remote App published for your users.
Next steps
Learn more about sandboxes and how to use them to test Windows environments at
Windows Sandbox.
 Documentation
Run Microsoft Learn training exercises in your own subscription

How to run Microsoft Learn training exercises in your own subscription.
Linux on Azure - Training

This comprehensive learning path reviews deployment and management of Linux on Azure. Learn
about cloud computing concepts, Linux IaaS and PaaS solutions and benefits and Azure cloud
services. Discover how to migrate and extend your Linux-based workloads on Azure with improved…
Browse all learning paths and modules - Training

Learn new skills and discover the power of Microsoft products with step-by-step guidance. Start your
journey today by exploring our learning paths and modules.
Manage services with the Azure portal - Training

Get acquainted with the Azure cloud platform through the Azure portal, where you create and
manage all of your Azure resources.
Align requirements with cloud types and service models in Azure - Training
Discover Azure's three approaches to deploying cloud resources--public, private, and hybrid--and
learn the difference each makes in your Azure services.
Introduction to Azure DevTest Labs - Training

In this module, you'll learn how to evaluate whether Microsoft Azure DevTest Labs is appropriate for
setting up virtual machine environments for your team.
Introduction to Azure virtual machines - Training

Learn about the decisions you make before creating a virtual machine, the options to create and
manage the VM, and the extensions and services you use to manage your VM.
Show 4 more
 Training
Learning path
Certification
Create a golden image in Azure
This article will walk you through how to use the Azure portal to create a custom image
to use for your Azure Virtual Desktop session hosts. This custom image, which we'll call a
"golden image," contains all apps and configuration settings you want to apply to your
deployment.
There are other approaches to customizing your session hosts, such as
using device management tools like Microsoft Intune or automating your image build
using tools like Azure Image Builder with Azure DevOps. Which strategy works best
depends on the complexity and size of your planned Azure Virtual Desktop environment
and your current application deployment processes.
Create an image from an Azure VM

When creating a new VM for your golden image, make sure to choose an OS that's in
the list of supported virtual machine OS images. We recommend using a Windows 10
multi-session (with or without Microsoft 365) or Windows Server image for pooled host
pools. We recommend using Windows 10 Enterprise images for personal host pools. You
can use either Generation 1 or Generation 2 VMs; Gen 2 VMs support features that
aren't supported for Gen 1 machines. Learn more about Generation 1 and Generation 2
VMs at Support for generation 2 VMs on Azure.
） Important
The VM used for taking the image must be deployed without "Login with Azure
AD" flag. During the deployment of Session Hosts in Azure Virtual Desktop, if you
choose to add VMs to Azure Active Directory you are able to Login with AD
Credentials too.
Take your first snapshot

First, create the base VM for your chosen image. After you've deployed the image, take
a snapshot of the disk of your image VM. Snapshots are save states that will let you roll
back any changes if you run into problems while building the image. Since you'll be
taking many snapshots throughout the build process, make sure to give the snapshot a
name you can easily identify.
Customize your VM
Sign in to the VM and start customizing it with apps, updates, and other things you'll
need for your image. If the VM needs to be domain-joined during customization,
remove it from the domain before running sysprep. If you need to install many apps, we
recommend you take multiple snapshots to revert your VM if a problem happens.
Make
sure you've done the following things before taking the final snapshot:
Install the latest Windows updates.

Complete any necessary cleanup, such as cleaning up temporary files,
defragmenting disks, and removing unnecessary user profiles.
７ Note
1. If your machine will include an antivirus app, it may cause issues when you
start sysprep. To avoid this, disable all antivirus programs before running
sysprep.
2. Unified Write Filter (UWF) is not supported for session hosts. Please ensure it
is not enabled in your image.
3. Do not join your golden image VM to a host pool, by deploying the Azure
Virtual Desktop Agent. If you do this when you create additional session hosts
from this image at a later time, they will fail to join the host pool as the
Registration token will have expired. The host pool deployment process will
automatically join the session hosts to the required host pool during the
provisioning process.
Take the final snapshot

When you are done installing your applications to the image VM, take a final snapshot
of the disk. If sysprep or capture fails, you will be able to create a new base VM with
your applications already installed from this snapshot.
Run sysprep
Some optional things you can do before running Sysprep:
Reboot once
Clean up temp files in system storage
Optimize drivers (defrag)
Remove any user profiles
Generalize the VM by running sysprep
Capture the VM
After you've completed sysprep and shut down your machine in the Azure portal, open
the VM tab and select the Capture button to save the image for later use. When you
capture a VM, you can either add the image to a shared image gallery or capture it as a
managed image.
The Shared Image Gallery lets you add features and use existing
images in other deployments. Images from a Shared Image Gallery are highly-available,
ensure easy versioning, and you can deploy them at scale. However, if you have a
simpler deployment, you may want to use a standalone managed image instead.
） Important
We recommend using Azure Compute Gallery images for production environments

because of their enhanced capabilities, such as replication and image versioning.
When you create a capture, you'll need to delete the VM afterwards, as you'll no
longer be able to use it after the capture process is finished. Don't try to capture
the same VM twice, even if there's an issue with the capture. Instead, create a new
VM from your latest snapshot, then run sysprep again.
Once you've finished the
capture process, you can use your image to create your session hosts. To find the
image, open the Host pool tab, choose Gallery, then select all images. Next, select
My items and look for your managed images under My images. Your image
definitions should appear under the shared items section.
Other recommendations
Here are some extra things you should keep in mind when creating a golden image:
Don't capture a VM that already exists in your host pools. The image will conflict
with the existing VM's configuration, and the new VM won't work.
Make sure to remove the VM from the domain before running sysprep.
Delete the base VM once you've captured the image from it.
After you've captured your image, don't use the same VM you captured again.
Instead, create a new base VM from the last snapshot you created. You'll need to
periodically update and patch this new VM on a regular basis.
Don't create a new base VM from an existing custom image.
Next steps
If you want to add a language pack to your image, see Language packs.
Prepare and customize a VHD image for
This article tells you how to prepare a master virtual hard disk (VHD) image for upload
to Azure, including how to create virtual machines (VMs) and install software on them.
These instructions are for a Azure Virtual Desktop-specific configuration that can be
used with your organization's existing processes.
） Important
We recommend you use an image from the Azure Image Gallery. However, if you
do need to use a customized image, make sure you don't already have the Azure
Virtual Desktop Agent installed on your VM. Using a customized image with the
Azure Virtual Desktop Agent can cause problems with the image, such as blocking
registration as the host pool registration token will have expired which will prevent
user session connections.
Create a VM
Windows 10 Enterprise multi-session is available in the Azure Image Gallery. There are
two options for customizing this image.
The first option is to provision a virtual machine (VM) in Azure by following the
instructions in Create a VM from a managed image, and then skip ahead to Software
preparation and installation.
The second option is to create the image locally by downloading the image,
provisioning a Hyper-V VM, and customizing it to suit your needs, which we cover in the
following section.
Local image creation

You can download an image following the instructions in Export an image version to a
managed disk and then Download a Windows VHD from Azure. Once you've
downloaded the image to a local location, open Hyper-V Manager to create a VM with
the VHD you copied. The following instructions are a simple version, but you can find
more detailed instructions in Create a virtual machine in Hyper-V.
To create a VM with the copied VHD:
1. Open the New Virtual Machine Wizard.
2. On the Specify Generation page, select Generation 1.
3. Under Checkpoint Type, disable checkpoints by unchecking the check box.
You can also run the following cmdlet in PowerShell to disable checkpoints.
PowerShell
Set-VM -Name <VMNAME> -CheckpointType Disabled
Fixed disk
If you create a VM from an existing VHD, it creates a dynamic disk by default. It can be
changed to a fixed disk by selecting Edit Disk... as shown in the following image. For
more detailed instructions, see Prepare a Windows VHD or VHDX to upload to Azure.
You can also run the following PowerShell command to change the disk to a fixed disk.
PowerShell
Convert-VHD –Path c:\test\MY-VM.vhdx –DestinationPath c:\test\MY-NEW-VM.vhd

-VHDType Fixed
Software preparation and installation

This section covers how to prepare and install FSLogix and Windows Defender, as well as
some basic configuration options for apps and your image's registry.
If you're installing Microsoft 365 Apps for enterprise and OneDrive on your VM, go to
Install Office on a master VHD image and follow the instructions there to install the
apps. After you're done, return to this article.
If your users need to access certain LOB applications, we recommend you install them
after completing this section's instructions.
Set up user profile container (FSLogix)

To include the FSLogix container as part of the image, follow the instructions in Create a
profile container for a host pool using a file share. You can test the functionality of the
FSLogix container with this quickstart.
Configure Windows Defender

If Windows Defender is configured in the VM, make sure it's configured to not scan the
entire contents of VHD and VHDX files during attachment.
This configuration only removes scanning of VHD and VHDX files during attachment,
but won't affect real-time scanning.
For more detailed instructions for how to configure Windows Defender, see Configure
Windows Defender Antivirus exclusions on Windows Server.
To learn more about how to configure Windows Defender to exclude certain files from
scanning, see Configure and validate exclusions based on file extension and folder
location.
Disable Automatic Updates

To disable Automatic Updates via local Group Policy:
1. Open Local Group Policy Editor\Administrative Templates\Windows

Components\Windows Update.
2. Right-click Configure Automatic Update and set it to Disabled.
You can also run the following command from an elevated PowerShell prompt to disable
Automatic Updates.
PowerShell
New-ItemProperty -Path
"HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU" -Name
NoAutoUpdate -PropertyType DWORD -Value 1 -Force
Specify Start layout for Windows 10 PCs (optional)

Run the following command from an elevated PowerShell prompt to specify a Start
layout for Windows 10 PCs.
PowerShell
"HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer" -Name
SpecialRoamingOverrideAllowed -PropertyType DWORD -Value 1 -Force
Set up time zone redirection

Time zone redirection can be enforced on Group Policy level since all VMs in a host pool
are part of the same security group.
To redirect time zones:
1. On the Active Directory server, open the Group Policy Management Console.
2. Expand your domain and Group Policy Objects.
3. Right-click the Group Policy Object that you created for the group policy settings
and select Edit.
4. In the Group Policy Management Editor, navigate to Computer Configuration >
Policies > Administrative Templates > Windows Components > Remote Desktop
Services > Remote Desktop Session Host > Device and Resource Redirection.
5. Enable the Allow time zone redirection setting.
You can also run the following command from an elevated PowerShell prompt to
redirect time zones:
PowerShell
New-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows

NT\Terminal Services" -Name fEnableTimeZoneRedirection -PropertyType DWORD -
Value 1 -Force
Disable Storage Sense

For Azure Virtual Desktop session hosts that use Windows 10 Enterprise or Windows 10
Enterprise multi-session, we recommend disabling Storage Sense. Disks where the
operating system is installed are typically small in size and user data is stored remotely
through profile roaming. This scenario results in Storage Sense believing that the disk is
critically low on free space. You can disable Storage Sense in the Settings menu under
Storage, as shown in the following screenshot:
You can also run the following command from an elevated PowerShell prompt to disable
Storage Sense:
PowerShell
"HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\StorageSense\Parameters\Sto
ragePolicy" -Name 01 -PropertyType DWORD -Value 0 -Force
Include additional language support

This article doesn't cover how to configure language and regional support. For more
information, see the following articles:
Add languages to Windows images

Features on demand
Language and region features on demand (FOD)
Other applications and registry configuration

This section covers application and operating system configuration. All configuration in
this section is done through adding, changing, or removing registry entries.
For feedback hub collection of telemetry data on Windows 10 Enterprise multi-session,

run the following command from an elevated PowerShell prompt:
PowerShell
"HKLM:\SOFTWARE\Policies\Microsoft\Windows\DataCollection" -Name
AllowTelemetry -PropertyType DWORD -Value 3 -Force
To prevent Watson crashes, run the following command from an elevated PowerShell
prompt:
PowerShell
Remove-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows\Windows Error

Reporting" -Name Corporate* -Force -Verbose
To enable 5k resolution support, run the following commands from an elevated

PowerShell prompt. You must run the commands before you can enable the side-by-
side stack.
PowerShell
New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Terminal

Server\WinStations\RDP-Tcp" -Name MaxMonitors -PropertyType DWORD -Value 4 -
Force

Server\WinStations\RDP-Tcp" -Name MaxXResolution -PropertyType DWORD -Value
5120 -Force

Server\WinStations\RDP-Tcp" -Name MaxYResolution -PropertyType DWORD -Value
2880 -Force

Server\WinStations\rdp-sxs" -Name MaxMonitors -PropertyType DWORD -Value 4 -
Force

Server\WinStations\rdp-sxs" -Name MaxXResolution -PropertyType DWORD -Value
5120 -Force

Server\WinStations\rdp-sxs" -Name MaxYResolution -PropertyType DWORD -Value
2880 -Force
Prepare the image for upload to Azure

After you've finished configuration and installed all applications, follow the instructions
in Prepare a Windows VHD or VHDX to upload to Azure to prepare the image.
After preparing the image for upload, make sure the VM remains in the off or
deallocated state.
Upload master image to a storage account in

Azure
This section only applies when the master image was created locally.
The following instructions will tell you how to upload your master image into an Azure
storage account. If you don't already have an Azure storage account, follow the
instructions in this article to create one.
1. Convert the VM image (VHD) to Fixed if you haven't already. If you don't convert
the image to Fixed, you can't successfully create the image.
2. Upload the VHD to a blob container in your storage account. You can upload
quickly with the Storage Explorer tool . To learn more about the Storage Explorer
tool, see this article.
3. Next, go to the Azure portal in your browser and search for "Images." Your search
should lead you to the Create image page, as shown in the following screenshot:
4. Once you've created the image, you should see a notification like the one in the
following screenshot:
Next steps
Now that you have an image, you can create or update host pools. To learn more about
how to create and update host pools, see the following articles:
Create a host pool with an Azure Resource Manager template

Tutorial: Create a host pool with Azure Marketplace
Create a host pool with PowerShell
Create a profile container for a host pool using a file share
Configure the Azure Virtual Desktop load-balancing method
If you encountered a connectivity problem after preparing or customizing your VHD

image, check out the troubleshooting guide for help.
Install Office on a master VHD image
This article tells you how to install Microsoft 365 Apps for enterprise, OneDrive, and
other common applications on a master virtual hard disk (VHD) image for upload to
Azure. If your users need to access certain line of business (LOB) applications, we
recommend you install them after completing the instructions in this article.
This article assumes you've already created a virtual machine (VM). If not, see Prepare
and customize a master VHD image
This article also assumes you have elevated access on the VM, whether it's provisioned
in Azure or Hyper-V Manager. If not, see Elevate access to manage all Azure
subscription and management groups.
７ Note
These instructions are for a Azure Virtual Desktop-specific configuration that can be
used with your organization's existing processes.
Install Office in shared computer activation

mode
Shared computer activation lets you to deploy Microsoft 365 Apps for enterprise to a
computer in your organization that is accessed by multiple users. For more information
about shared computer activation, see Overview of shared computer activation for
Microsoft 365 Apps.
Use the Office Deployment Tool to install Office. Windows 10 Enterprise multi-session
only supports the following versions of Office:
Microsoft 365 Apps for enterprise

Microsoft 365 Apps for business that comes with a Microsoft 365 Business
Premium subscription
The Office Deployment Tool requires a configuration XML file. To customize the
following sample, see the Configuration Options for the Office Deployment Tool.
This sample configuration XML we've provided will do the following things:
Install Office from the Monthly Enterprise Channel and deliver updates from the
Monthly Enterprise Channel.
Use the x64 architecture.
Disable automatic updates.
Remove any existing installations of Office and migrate their settings.
Enable shared computer activation.
７ Note
Visio's stencil search feature may not work as expected in Azure Virtual Desktop.
Here's what this sample configuration XML won't do:
Install Skype for Business

Install OneDrive in per-user mode. To learn more, see Install OneDrive in per-
machine mode.
７ Note
Shared Computer Activation can be set up through Group Policy Objects (GPOs) or
registry settings. The GPO is located at Computer
Configuration\Policies\Administrative Templates\Microsoft Office 2016
(Machine)\Licensing Settings
The Office Deployment Tool contains setup.exe. To install Office, run the following
command in a command line:
Setup.exe /configure configuration.xml
Sample configuration.xml
The following XML sample will install the Monthly Enterprise Channel release.
XML
<Configuration>
<Add OfficeClientEdition="64" Channel="MonthlyEnterprise">
<Product ID="O365ProPlusRetail">
<Language ID="en-US" />
<Language ID="MatchOS" />
<ExcludeApp ID="Groove" />
<ExcludeApp ID="Lync" />
<ExcludeApp ID="OneDrive" />
<ExcludeApp ID="Teams" />
</Product>
</Add>
<RemoveMSI/>
<Updates Enabled="FALSE"/>
<Display Level="None" AcceptEULA="TRUE" />
<Logging Level="Standard" Path="%temp%\WVDOfficeInstall" />
<Property Name="FORCEAPPSHUTDOWN" Value="TRUE"/>
<Property Name="SharedComputerLicensing" Value="1"/>
</Configuration>
７ Note
The Office team recommends using 64-bit install for the OfficeClientEdition
parameter.
After installing Office, you can update the default Office behavior. Run the following
commands individually or in a batch file to update the behavior.
rem Mount the default user registry hive
reg load HKU\TempDefault C:\Users\Default\NTUSER.DAT
rem Must be executed with default registry hive mounted.
reg add HKU\TempDefault\SOFTWARE\Policies\Microsoft\office\16.0\common /v

InsiderSlabBehavior /t REG_DWORD /d 2 /f
rem Set Outlook's Cached Exchange Mode behavior
rem Must be executed with default registry hive mounted.
reg add
"HKU\TempDefault\software\policies\microsoft\office\16.0\outlook\cached
mode" /v enable /t REG_DWORD /d 1 /f
reg add
mode" /v syncwindowsetting /t REG_DWORD /d 1 /f
reg add
mode" /v CalendarSyncWindowSetting /t REG_DWORD /d 1 /f
reg add
mode" /v CalendarSyncWindowSettingMonths /t REG_DWORD /d 1 /f
rem Unmount the default user registry hive
reg unload HKU\TempDefault
rem Set the Office Update UI behavior.
reg add HKLM\SOFTWARE\Policies\Microsoft\office\16.0\common\officeupdate /v

hideupdatenotifications /t REG_DWORD /d 1 /f
reg add HKLM\SOFTWARE\Policies\Microsoft\office\16.0\common\officeupdate /v

hideenabledisableupdates /t REG_DWORD /d 1 /f
Install OneDrive in per-machine mode

OneDrive is normally installed per-user. In this environment, it should be installed per-
machine.
Here's how to install OneDrive in per-machine mode:
1. First, create a location to stage the OneDrive installer. A local disk folder or [\\unc]
(file://unc) location is fine.
2. Download OneDriveSetup.exe to your staged location.
3. If you installed Office with OneDrive by omitting <ExcludeApp ID="OneDrive" / ,

uninstall any existing OneDrive per-user installations from an elevated command
prompt by running the following command:
"[staged location]\OneDriveSetup.exe" /uninstall
4. Run this command from an elevated command prompt to set the AllUsersInstall
registry value:
REG ADD "HKLM\Software\Microsoft\OneDrive" /v "AllUsersInstall" /t

REG_DWORD /d 1 /reg:64
5. Run this command to install OneDrive in per-machine mode:
Run "[staged location]\OneDriveSetup.exe" /allusers
6. Run this command to configure OneDrive to start at sign in for all users:
REG ADD "HKLM\Software\Microsoft\Windows\CurrentVersion\Run" /v

OneDrive /t REG_SZ /d "C:\Program Files (x86)\Microsoft
OneDrive\OneDrive.exe /background" /f
7. Enable Silently configure user account by running the following command.
REG ADD "HKLM\SOFTWARE\Policies\Microsoft\OneDrive" /v

"SilentAccountConfig" /t REG_DWORD /d 1 /f
8. Redirect and move Windows known folders to OneDrive by running the following
command.
REG ADD "HKLM\SOFTWARE\Policies\Microsoft\OneDrive" /v "KFMSilentOptIn"

/t REG_SZ /d "<your-AzureAdTenantId>" /f
Microsoft Teams and Skype for Business

Azure Virtual Desktop doesn't support Skype for Business.
For help with installing Microsoft Teams, see Use Microsoft Teams on Azure Virtual
desktop.
Next steps
Now that you've added Office to the image, you can continue to customize your master
VHD image. See Prepare and customize a master VHD image.
Enforce Azure Active Directory Multi-
Factor Authentication for Azure Virtual
Desktop using Conditional Access
） Important
If you're visiting this page from the Azure Virtual Desktop (classic) documentation,
make sure to return to the Azure Virtual Desktop (classic) documentation once
you're finished.
Users can sign into Azure Virtual Desktop from anywhere using different devices and
clients. However, there are certain measures you should take to help keep yourself and
your users safe. Using Azure Active Directory (Azure AD) Multi-Factor Authentication
(MFA) with Azure Virtual Desktop prompts users during the sign-in process for another
form of identification in addition to their username and password. You can enforce MFA
for Azure Virtual Desktop using Conditional Access, and can also configure whether it
applies to the web client, mobile apps, desktop clients, or all clients.
How often a user is prompted to reauthenticate depends on Azure AD session lifetime

configuration settings. For example, if their Windows client device is registered with
Azure AD, it will receive a Primary Refresh Token (PRT) to use for single sign-on (SSO)
across applications. Once issued, a PRT is valid for 14 days and is continuously renewed
as long as the user actively uses the device.
While remembering credentials is convenient, it can also make deployments for

Enterprise scenarios using personal devices less secure. To protect your users, you can
make sure the client keeps asking for Azure AD Multi-Factor Authentication credentials
more frequently. You can use Conditional Access to configure this behavior.
Learn how to enforce MFA for Azure Virtual Desktop and optionally configure sign-in
frequency below.
Prerequisites
Here's what you'll need to get started:
Assign users a license that includes Azure Active Directory Premium P1 or P2.
An Azure Active Directory group with your Azure Virtual Desktop users assigned as
group members.
Enable Azure AD Multi-Factor Authentication for your users. For more information
about how to do that, see Enable Azure AD Multi-Factor Authentication.
Create a Conditional Access policy

Here's how to create a Conditional Access policy that requires multi-factor
authentication when connecting to Azure Virtual Desktop:
1. Sign in to the Azure portal as a global administrator, security administrator, or

Conditional Access administrator.
2. In the search bar, type Azure Active Directory and select the matching service entry.
3. Browse to Security > Conditional Access.
4. Select New policy > Create new policy.
5. Give your policy a name. We recommend that organizations create a meaningful

standard for the names of their policies.
6. Under Assignments, select Users or workload entities.
7. Under the Include tab, select Select users and groups and tick Users and groups.
On the right, search for and choose the group that contains your Azure Virtual
Desktop users as group members.
8. Select Select.
9. Under Assignments, select Cloud apps or actions.
10. Under the Include tab, select Select apps.
11. On the right, select one of the following apps based on which version of Azure
Virtual Desktop you're using.
If you're using Azure Virtual Desktop (based on Azure Resource Manager),

you can configure MFA on two different apps:
Azure Virtual Desktop (app ID 9cdead84-a844-4324-93f2-b2e6bb768d07),
which applies when the user subscribes to a feed and authenticates to the
Azure Virtual Desktop Gateway during a connection.
 Tip
The app name was previously Windows Virtual Desktop. If you registered
the Microsoft.DesktopVirtualization resource provider before the display
name changed, the application will be named Windows Virtual Desktop
with the same app ID as above.
Microsoft Remote Desktop (app ID a4a365df-50f1-4397-bc59-

1a1564b8bb9c), which applies when the user authenticates to the session
host when single sign-on is enabled.
If you're using Azure Virtual Desktop (classic), choose these apps:

Windows Virtual Desktop (app ID 5a0aa725-4958-4b0c-80a9-
34562e23f3b7)
Windows Virtual Desktop Client (app ID fa4345a4-a730-4230-84a8-
7d9651b86739), which will let you set policies on the web client
 Tip
If you're using Azure Virtual Desktop (classic) and if the Conditional

Access policy blocks all access excluding Azure Virtual Desktop app IDs,
you can fix this by also adding the Azure Virtual Desktop (app ID
9cdead84-a844-4324-93f2-b2e6bb768d07) to the policy. Not adding
this app ID will block feed discovery of Azure Virtual Desktop (classic)
resources.
） Important
Don't select the app called Azure Virtual Desktop Azure Resource Manager
Provider (app ID 50e95039-b200-4007-bc97-8d5790743a63). This app is only
used for retrieving the user feed and shouldn't have multi-factor
authentication.
12. Once you've selected your app, select Select.

13. Under Assignments, select Conditions > Client apps. On the right, for Configure,
select Yes, and then select the client apps this policy will apply to:
Select both check boxes if you want to apply the policy to all clients.
Select Browser if you want the policy to apply to the web client.
Select Mobile apps and desktop clients if you want to apply the policy to
other clients.
Deselect values for legacy authentication clients.
14. Once you've selected the client apps this policy will apply to, select Done.
15. Under Assignments, select Access controls > Grant, select Grant access, Require
multi-factor authentication, and then select Select.
16. At the bottom of the page, set Enable policy to On and select Create.
７ Note
When you use the web client to sign in to Azure Virtual Desktop through your
browser, the log will list the client app ID as a85cf173-4192-42f8-81fa-
777a763e6e2c (Azure Virtual Desktop client). This is because the client app is
internally linked to the server app ID where the conditional access policy was set.
 Tip
Some users may see a prompt titled Stay signed in to all your apps if the Windows
device they're using is not already registered with Azure AD. If they deselect Allow
my organization to manage my device and select No, sign in to this app only, this
may reappear frequently.
Configure sign-in frequency

To optionally configure the time period before a user is asked to sign-in again:
1. Open the policy you created previously.

2. Under Assignments, select Access controls > Session. On the right, select Sign-in
frequency. Set the value for the time period before a user is asked to sign-in again,
and then select Select. For example, setting the value to 1 and the unit to Hours,
will require multi-factor authentication if a connection is launched over an hour
after the last one.
3. At the bottom of the page, under Enable policy select Save.
Azure AD joined session host VMs

For connections to succeed, you must disable the legacy per-user multi-factor
authentication sign-in method. If you don't want to restrict signing in to strong
authentication methods like Windows Hello for Business, you'll also need to exclude the
Azure Windows VM Sign-In app from your Conditional Access policy.
Next steps
Learn more about Conditional Access policies
Learn more about user sign in frequency
 Documentation
Troubleshoot connections to Azure AD-joined VMs - Azure Virtual Desktop

How to resolve issues when connecting to Azure AD-joined VMs in Azure Virtual Desktop.
Configure single sign-on for Azure Virtual Desktop using Azure AD Authentication -
Azure
How to configure single sign-on for an Azure Virtual Desktop environment using Azure AD
Authentication.
Deploy Azure AD joined VMs in Azure Virtual Desktop - Azure

How to configure and deploy Azure AD joined VMs in Azure Virtual Desktop.
Azure Virtual Desktop identities and authentication - Azure

Identities and authentication methods for Azure Virtual Desktop.
Azure AD join for Azure Virtual Desktop - Azure Architecture Center

Learn how to configure Azure AD domain join for Azure Virtual Desktop host VMs without using
Active Directory Domain Services domain controllers.

pool.
Customize RDP properties with PowerShell - Azure

How to customize RDP Properties for Azure Virtual Desktop with PowerShell cmdlets.
Create a profile container with Azure Files and Azure Active Directory
Set up an FSLogix profile container on an Azure file share in an existing Azure Virtual Desktop host
pool with your Azure Active Directory domain.
Show 5 more
 Training

Configure single sign-on for Azure
Virtual Desktop using Azure AD
Authentication
） Important
Single sign-on using Azure AD authentication is currently in public preview.

This
preview version is provided without a service level agreement, and is not
recommended for production workloads. Certain features might not be supported
or might have constrained capabilities.
For more information, see Supplemental
Terms of Use for Microsoft Azure Previews .
This article will walk you through the process of configuring single sign-on (SSO) using
Azure Active Directory (Azure AD) authentication for Azure Virtual Desktop (preview).
When you enable SSO, you can use passwordless authentication and third-party Identity
Providers that federate with Azure AD to sign in to your Azure Virtual Desktop and
Remote Applications. When enabled, this feature provides a single sign-on experience
when authenticating to the session host and configures the session to provide single
sign-on to Azure AD-based resources inside the session.
For information on using passwordless authentication within the session, see In-session
passwordless authentication (preview).
７ Note
Azure Virtual Desktop (classic) doesn't support this feature.
Prerequisites
Single sign-on is available on session hosts using the following operating systems:
Windows 11 Enterprise single or multi-session with the 2022-10 Cumulative

Updates for Windows 11 (KB5018418) or later installed.
Windows 10 Enterprise single or multi-session, versions 20H2 or later with the
2022-10 Cumulative Updates for Windows 10 (KB5018410) or later installed.
Windows Server 2022 with the 2022-10 Cumulative Update for Microsoft server
operating system (KB5018421) or later installed.
Session hosts must be Azure AD-joined or Hybrid Azure AD-Joined.
７ Note
Azure Virtual Desktop doesn't support this solution with VMs joined to Azure AD
Domain Services or Active Directory only joined session hosts.
You must Create a Kerberos Server object when your session host is:
Hybrid Azure AD-joined. Azure AD Kerberos is needed to complete the

authentication to the domain controller.
Azure AD-joined and your environment contains Active Directory Domain
Controllers. Azure AD Kerberos is required in this case for users to access on-
premises resources, like SMB shares, and Windows-integrated authentication to
websites.
Clients currently supported:
Windows Desktop client on local PCs running Windows 10 or later. There's no

requirement for the local PC to be joined to a domain or Azure AD.
Web client.
Enable single sign-on

To enable SSO on your host pool, you must customize an RDP property. You can find the
Azure AD Authentication property under the Connection information tab in the Azure
portal or set the enablerdsaadauth property to 1 using PowerShell.
） Important
If you enable SSO on your Hybrid Azure AD-joined VMs before you create the
Kerberos server object, you won't be able to connect to the VMs, and you'll see an
error message saying the specific log on session doesn't exist.
Allow remote desktop connection dialog

When enabling single sign-on, you'll currently be prompted to authenticate to Azure AD
and allow the Remote Desktop connection when launching a connection to a new host.
Azure AD remembers up to 15 hosts for 30 days before prompting again. If you see this
dialogue, select Yes to connect.
Disconnection when the session is locked

When SSO is enabled, you sign in to Windows using an Azure AD authentication token,
which provides support for passwordless authentication to Windows. The Windows lock
screen in the remote session doesn't support Azure AD authentication tokens or
passwordless authentication methods like FIDO keys. The lack of support for these
authentication methods means that users can't unlock their screens in a remote session.
When you try to lock a remote session, either through user action or system policy, the
session is instead disconnected and the service sends a message to the user explaining
they've been disconnected.
Disconnecting the session also ensures that when the connection is relaunched after a
period of inactivity, Azure AD reevaluates the applicable conditional access policies.
Next steps
Check out In-session passwordless authentication (preview) to learn how to enable
passwordless authentication.
For more information about Azure AD Kerberos, see Deep dive: How Azure AD
Kerberos works
If you're accessing Azure Virtual Desktop from our Windows Desktop client, see
Connect with the Windows Desktop client.
If you're accessing Azure Virtual Desktop from our web client, see Connect with the
web client.
If you encounter any issues, go to Troubleshoot connections to Azure AD-joined
VMs.
Configure single sign-on for Azure
Virtual Desktop using AD FS
This article will walk you through the process of configuring Active Directory Federation
Service (AD FS) single sign-on (SSO) for Azure Virtual Desktop.
７ Note
Azure Virtual Desktop (Classic) doesn't support this feature.
Requirements
Before configuring AD FS single sign-on, you must have the following setup running in
your environment:
You must deploy the Active Directory Certificate Services (CA) role. All servers
running the role must be domain-joined, have the latest Windows updates
installed, and be configured as enterprise certificate authorities.
You must deploy the Active Directory Federation Services (AD FS) role. All servers
running this role must be domain-joined, have the latest Windows updates
installed, and be running Windows Server 2016 or later. See our federation tutorial
to get started setting up this role.
We recommend setting up the Web Application Proxy role to secure your
environment's connection to the AD FS servers. All servers running this role must
have the latest Windows updates installed, and be running Windows Server 2016
or later. See this Web Application Proxy guide to get started setting up this role.
You must deploy Azure AD Connect to sync users to Azure AD. Azure AD Connect
must be configured in federation mode.
Set up your PowerShell environment for Azure Virtual Desktop on the AD FS server.
When using Windows 10 20H1 or 20H2 to connect to Azure Virtual Desktop, you
must install the 2021-04 Cumulative Update for Windows 10 (KB5001330) or later
for single sign-on to function properly.
７ Note
This solution is not supported with Azure AD Domain Services. You must use an
Active Directory Domain Controller.
Supported clients
The following Azure Virtual Desktop clients support this feature:

Web client
Configure the certificate authority to issue

certificates
You must properly create the following certificate templates so that AD FS can use SSO:
First, you'll need to create the Exchange Enrollment Agent (Offline Request)
certificate template. AD FS uses the Exchange Enrollment Agent certificate
template to request certificates on the user's behalf.
You'll also need to create the Smartcard Logon certificate template, which AD FS
will use to create the sign in certificate.
After you create these certificate templates, you'll need to enable the templates on the
certificate authority so AD FS can request them.
７ Note
This solution generates new short-term certificates every time a user signs in, which
can fill up the Certificate Authority database if you have many users. You can avoid
overloading your database by setting up a CA for non-persistent certificate
processing. If you do this, on the duplicated smartcard logon certificate template,
make sure you enable only Do not store certificates and requests in the CA
database. Don't enable Do not include revocation information in issued
certificates or the configuration won't work.
Create the enrollment agent certificate template

Depending on your environment, you may already have configured an enrollment agent
certificate template for other purposes like Windows Hello for Business, Logon
certificates or VPN certificates. If so, you will need to modify it to support SSO. If not,
you can create a new template.
To determine if you are already using an enrollment agent certificate template, run the
following PowerShell command on the AD FS server and see if a value is returned. If it's
empty, create a new enrollment agent certificate template. Otherwise, remember the
name and update the existing enrollment agent certificate template.
PowerShell
Import-Module adfs
(Get-AdfsCertificateAuthority).EnrollmentAgentCertificateTemplateName
To create a new enrollment agent certificate template:
1. On the certificate authority, run mmc.exe from the Start menu to launch the
Microsoft Management Console.
2. Select File... > Add/Remote Snap-in... > Certificate Templates > Add > > OK to
view the list of certificate templates.
3. Expand the Certificate Templates, right-click Exchange Enrollment Agent (Offline

Request) and select Duplicate Template.
4. Select the General tab, then enter "ADFS Enrollment Agent" into the Template
display name field. This will automatically set the template name to
"ADFSEnrollmentAgent".
5. Select the Security tab, then select Add....
6. Next, select Object Types..., then Service Accounts, and then OK.
7. Enter the service account name for AD FS and select OK.
In an isolated AD FS setup, the service account will be named "adfssvc$"

If you set up AD FS using Azure AD Connect, the service account will be
named "aadcsvc$"
8. After the service account is added and is visible in the Security tab, select it in the
Group or user names pane, select Allow for both "Enroll" and "Autoenroll" in the
Permissions for the AD FS service account pane, then select OK to save.
To update an existing enrollment agent certificate template:
2. Select File... > Add/Remote Snap-in... > Certificate Templates > Add > > OK to
view the list of certificate templates.
3. Expand the Certificate Templates, double-click the template that corresponds to
the one configured on the AD FS server. On the General tab, the template name
should match the name you found above.
5. Next, select Object Types..., then Service Accounts, and then OK.
6. Enter the service account name for AD FS and select OK.

named "aadcsvc$"
Group or user names pane, select Allow for both "Enroll" and "Autoenroll" in the
Permissions for the AD FS service account pane, then select OK to save.
Create the Smartcard Logon certificate template

To create the Smartcard Logon certificate template:
2. Select File... > Add/Remote Snap-in... > Certificate Templates > Add > OK to view
the list of certificate templates.
3. Expand the Certificate Templates, right-click Smartcard Logon and select

Duplicate Template.
4. Select the General tab, then enter "ADFS SSO" into the Template display name
field. This will automatically set the template name to "ADFSSSO".
７ Note
Since this certificate is requested on-demand, we recommend shortening the

validity period to 8 hours and the renewal period to 1 hour.
5. Select the Subject name tab and then select Supply in the request. When you see
a warning message, select OK.

6. Select the Issuance Requirements tab.
7. Select This number of authorized signatures and enter the value of 1.
8. For Application policy, select Certificate Request Agent.
10. Select Object Types..., Service Accounts, and OK.
11. Enter the service account name for AD FS just like you did in the Create the
enrollment agent certificate template section.

named "aadcsvc$"
Group or user names pane, select Allow for both "Enroll" and "Autoenroll", then
select OK to save.
Enable the new certificate templates:
To enable the new certificate templates:
2. Select File... > Add/Remove Snap-in... > Certification Authority > Add > > Finish
> and OK to view the Certification Authority.
3. Expand the Certification Authority on the left-hand pane and open Certificate
Templates.
4. Right-click in the middle pane that shows the list of certificate templates, select
New, then select Certificate Template to Issue.
5. Select both ADFS Enrollment Agent and ADFS SSO, then select OK. You should
see both templates in the middle pane.
７ Note
If you already have an enrollment agent certificate template configured, you

only need to add the ADFS SSO template.
Configure the AD FS Servers
You must configure the Active Directory Federation Services (AD FS) servers to use the
new certificate templates and set the relying-party trust to support SSO.
The relying-party trust between your AD FS server and the Azure Virtual Desktop service
allows single sign-on certificate requests to be forwarded correctly to your domain
environment.
When configuring AD FS single sign-on you must choose shared key or certificate:
If you have a single AD FS server, you can choose shared key or certificate.
If you have multiple AD FS servers, it's required to choose certificate.
The shared key or certificate used to generate the token to sign in to Windows must be
stored securely in Azure Key Vault. You can store the secret in an existing Key Vault or
deploy a new one. In either case, you must ensure to set the right access policy so the
Azure Virtual Desktop service can access it.
When using a certificate, you can use any general purpose certificate and there is no
requirement on the subject name or Subject Alternative Name (SAN). While not
required, it's recommended to create a certificate issued by a valid Certificate Authority.
This certificate can be created directly in Azure Key Vault and needs to have an
exportable private key. The public key can be exported and used to configure the AD FS
server using the script below. Note that this certificate is different from the AD FS SSL
certificate that must have a proper subject name and valid Certificate Authority.
The PowerShell script ConfigureWVDSSO.ps1 available in the PowerShell Gallery will

configure your AD FS server for the relying-party trust and install the certificate if
needed.
This script only has one required parameter, ADFSAuthority, which is the URL that
resolves to your AD FS and uses "/adfs" as its suffix. For example,
https://adfs.contoso.com/adfs .
1. On the AD FS VMs, run the following PowerShell cmdlet to configure AD FS to use

the certificate templates from the previous section:
PowerShell
Set-AdfsCertificateAuthority -EnrollmentAgentCertificateTemplate
"ADFSEnrollmentAgent" -LogonCertificateTemplate "ADFSSSO" -
EnrollmentAgent
７ Note
If you already have an EnrollmentAgentCertificateTemplate configured, ensure

you use the existing template name instead of ADFSEnrollmentAgent.
2. Run the ConfigureWVDSSO.ps1 script.
７ Note
You need the $config variable values to complete the next part of the
instructions, so don't close the PowerShell window you used to complete the
previous instructions. You can either keep using the same PowerShell window
or leave it open while launching a new PowerShell session.
If you're using a shared key in the Key Vault, run the following PowerShell
cmdlet on the AD FS server with ADFSServiceUrl replaced with the full URL to
reach your AD FS service:
PowerShell
Install-Script ConfigureWVDSSO
$config = ConfigureWVDSSO.ps1 -ADFSAuthority "<ADFSServiceUrl>" [-

WvdWebAppAppIDUri "<WVD Web App URI>"] [-RdWebURL "<RDWeb URL>"]
７ Note
You need the WvdWebAppAppIDUri and RdWebURL properties to

configure an environment in a sovereign cloud like Azure Government.
In the Azure Commercial Cloud, these properties are automatically set to
https://www.wvd.microsoft.com and https://rdweb.wvd.microsoft.com
respectively.
If you're using a certificate in the Key Vault, run the following PowerShell
cmdlet on the AD FS server with ADFSServiceUrl replaced with the full URL to
reach your AD FS service:
PowerShell
Install-Script ConfigureWVDSSO
$config = ConfigureWVDSSO.ps1 -ADFSAuthority "<ADFSServiceUrl>" -

UseCert -CertPath "<Path to the pfx file>" -CertPassword <Password
to the pfx file> [-WvdWebAppAppIDUri "<WVD Web App URI>"] [-
RdWebURL "<RDWeb URL>"]
７ Note
You need the WvdWebAppAppIDUri and RdWebURL properties to

configure an environment in a sovereign cloud like Azure Government.
In the Azure Commercial Cloud, these properties are automatically set to
https://www.wvd.microsoft.com and https://rdweb.wvd.microsoft.com
respectively.
3. Set the access policy on the Azure Key Vault by running the following PowerShell
cmdlet:
PowerShell
Set-AzKeyVaultAccessPolicy -VaultName "<Key Vault Name>" -

ServicePrincipalName 9cdead84-a844-4324-93f2-b2e6bb768d07 -
PermissionsToSecrets get -PermissionsToKeys sign
4. Store the shared key or certificate in Azure Key Vault with a Tag containing a coma
separated list of subscription IDs allowed to use the secret.
If you're using a shared key in the Key Vault, run the following PowerShell
cmdlet to store the shared key and set the tag:
PowerShell
$hp = Get-AzWvdHostPool -Name "<Host Pool Name>" -

ResourceGroupName "<Host Pool Resource Group Name>"
$secret = Set-AzKeyVaultSecret -VaultName "<Key Vault Name>" -Name

"adfsssosecret" -SecretValue (ConvertTo-SecureString -String
$config.SSOClientSecret -AsPlainText -Force) -Tag @{
'AllowedWVDSubscriptions' = $hp.Id.Split('/')[2]}
If your certificate is already in the Key Vault, run the following PowerShell
cmdlet to set the tag:
PowerShell

$secret = Update-AzKeyVaultCertificate -VaultName "<Key Vault

Name>" -Name "<Certificate Name>" -Tag @{
'AllowedWVDSubscriptions' = $hp.Id.Split('/')[2]} -PassThru
If you have a local certificate, run the following PowerShell cmdlet to import
the certificate in the Key Vault and set the tag:
PowerShell

$secret = Import-AzKeyVaultCertificate -VaultName "<Key Vault

Name>" -Name "adfsssosecret" -Tag @{ 'AllowedWVDSubscriptions' =
$hp.Id.Split('/')[2]} -FilePath "<Path to pfx>" -Password
(ConvertTo-SecureString -String "<pfx password>" -AsPlainText -
Force)
７ Note
You can optionally configure how often users are prompted for credentials by
changing the AD FS single sign-on settings. By default, users will be prompted
every 8 hours on unregistered devices.
Configure your Azure Virtual Desktop host pool

It's time to configure the AD FS SSO parameters on your Azure Virtual Desktop host
pool. To do this, set up your PowerShell environment for Azure Virtual Desktop if you
haven't already and connect to your account.
After that, update the SSO information for your host pool by running one of the
following two cmdlets in the same PowerShell window on the AD FS VM:
If you're using a shared key in the Key Vault, run the following PowerShell cmdlet:
PowerShell
Update-AzWvdHostPool -Name "<Host Pool Name>" -ResourceGroupName "<Host

Pool Resource Group Name>" -SsoadfsAuthority "<ADFSServiceUrl>" -
SsoClientId "<WVD Web App URI>" -SsoSecretType SharedKeyInKeyVault -
SsoClientSecretKeyVaultPath $secret.Id
７ Note
You need to set the SsoClientId property to match the Azure cloud you're
deploying SSO in. In the Azure Commercial Cloud, this property should be set
to https://www.wvd.microsoft.com . However, the required setting for this
property will be different for other clouds, like the Azure Government cloud.
If you're using a certificate in the Key Vault, run the following PowerShell cmdlet:
PowerShell
Update-AzWvdHostPool -Name "<Host Pool Name>" -ResourceGroupName "<Host

Pool Resource Group Name>" -SsoadfsAuthority "<ADFSServiceUrl>" -
SsoClientId "<WVD Web App URI>" -SsoSecretType CertificateInKeyVault -
SsoClientSecretKeyVaultPath $secret.Id
７ Note
You need to set the SsoClientId property to match the Azure cloud you're
deploying SSO in. In the Azure Commercial Cloud, this property should be set
to https://www.wvd.microsoft.com . However, the required setting for this
property will be different for other clouds, like the Azure Government cloud.
Configure additional host pools

When you need to configure additional host pools, you can retrieve the settings you
used to configure an existing host pool to setup the new one.
To retrieve the settings from your existing host pool, open a PowerShell window and run
this cmdlet:
PowerShell
Get-AzWvdHostPool -Name "<Host Pool Name>" -ResourceGroupName "<Host Pool

Resource Group Name>" | fl *
You can follow the steps to Configure your Azure Virtual Desktop host pool using the
same SsoClientId, SsoClientSecretKeyVaultPath, SsoSecretType, and SsoadfsAuthority
values.
Removing SSO
To disable SSO on the host pool, run the following cmdlet:
PowerShell
Update-AzWvdHostPool -Name "<Host Pool Name>" -ResourceGroupName "<Host Pool
Resource Group Name>" -SsoadfsAuthority ''
If you also want to disable SSO on your AD FS server, run this cmdlet:
PowerShell
Install-Script UnConfigureWVDSSO
UnConfigureWVDSSO.ps1 -WvdWebAppAppIDUri "<WVD Web App URI>" -

WvdClientAppApplicationID "a85cf173-4192-42f8-81fa-777a763e6e2c"
７ Note
The WvdWebAppAppIDUri property needs to match the Azure cloud you are
deploying in. In the Azure Commercial Cloud, this property is
https://www.wvd.microsoft.com . It will be different for other clouds like the Azure
Government cloud.
Next steps
Now that you've configured single sign-on, you can sign in to a supported Azure Virtual
Desktop client to test it as part of a user session. If you want to learn how to connect to
a session using your new credentials, check out these articles:

 Documentation
Azure Virtual Desktop identities and authentication - Azure

Identities and authentication methods for Azure Virtual Desktop.
Configure single sign-on for Azure Virtual Desktop using Azure AD Authentication -
Azure
How to configure single sign-on for an Azure Virtual Desktop environment using Azure AD
Authentication.
Azure AD join for Azure Virtual Desktop - Azure Architecture Center

Learn how to configure Azure AD domain join for Azure Virtual Desktop host VMs without using
Active Directory Domain Services domain controllers.
Device redirections in Azure Virtual Desktop - Azure

How to resolve issues with device redirections in Azure Virtual Desktop.

examples.


configure settings.
Show 5 more
 Training
Certification
Configure a Kerberos Key Distribution
Center proxy
Security-conscious customers, such as financial or government organizations, often sign

in using Smartcards. Smartcards make deployments more secure by requiring
multifactor authentication (MFA). However, for the RDP portion of a Azure Virtual
Desktop session, Smartcards require a direct connection, or "line of sight," with an
Active Directory (AD) domain controller for Kerberos authentication. Without this direct
connection, users can't automatically sign in to the organization's network from remote
connections. Users in a Azure Virtual Desktop deployment can use the KDC proxy
service to proxy this authentication traffic and sign in remotely. The KDC proxy allows
for authentication for the Remote Desktop Protocol of a Azure Virtual Desktop session,
letting the user sign in securely. This makes working from home much easier, and allows
for certain disaster recovery scenarios to run more smoothly.
However, setting up the KDC proxy typically involves assigning the Windows Server
Gateway role in Windows Server 2016 or later. How do you use a Remote Desktop
Services role to sign in to Azure Virtual Desktop? To answer that, let's take a quick look
at the components.
There are two components to the Azure Virtual Desktop service that need to be
authenticated:
The feed in the Azure Virtual Desktop client that gives users a list of available
desktops or applications they have access to. This authentication process happens
in Azure Active Directory, which means this component isn't the focus of this
article.
The RDP session that results from a user selecting one of those available resources.
This component uses Kerberos authentication and requires a KDC proxy for remote
users.
This article will show you how to configure the feed in the Azure Virtual Desktop client
in the Azure portal. If you want to learn how to configure the RD Gateway role, see
Deploy the RD Gateway role.
Requirements
To configure a Azure Virtual Desktop session host with a KDC proxy, you'll need the
following things:
Access to the Azure portal and an Azure administrator account.
The remote client machines must be running at least Windows 10 and have the
Windows Desktop client installed. The web client isn't currently supported.
You must have a KDC proxy already installed on your machine. To learn how to do
that, see Set up the RD Gateway role for Azure Virtual Desktop.
The machine's OS must be Windows Server 2016 or later.
Once you've made sure you meet these requirements, you're ready to get started.
How to configure the KDC proxy

To configure the KDC proxy:
1. Sign in to the Azure portal as an administrator.
2. Go to the Azure Virtual Desktop page.
3. Select the host pool you want to enable the KDC proxy for, then select RDP
Properties.
4. Select the Advanced tab, then enter a value in the following format without
spaces:
kdcproxyname:s:<fqdn>
5. Select Save.
6. The selected host pool should now begin to issue RDP connection files that include
the kdcproxyname value you entered in step 4.
Next steps
To learn how to manage the Remote Desktop Services side of the KDC proxy and assign
the RD Gateway role, see Deploy the RD Gateway role.
If you're interested in scaling your KDC proxy servers, learn how to set up high
availability for KDC proxy at Add high availability to the RD Web and Gateway web front.
Required URL Check tool
In order to deploy and make Azure Virtual Desktop available to your users, you must
allow specific URLs that your session host virtual machines (VMs) can access them
anytime. You can find the list of URLs in Required URL list. The Required URL Check tool
will validate these URLs and show whether your session host VMs can access them. If
not, then the tool will list the inaccessible URLs so you can unblock them and then
retest, if needed.
７ Note
You can only use the Required URL Check tool for deployments in the Azure
public cloud, it does not check access for sovereign clouds.
The Required URL Check tool can't verify URLs that wildcard entries are
unblocked, only specific entries within those wildcards, so make sure the
wildcard entries are unblocked first.
Prerequisites
You need the following things to use the Required URL Check tool:
Your session host VM must have a .NET 4.6.2 framework

RDAgent version 1.0.2944.400 or higher
The WVDAgentUrlTool.exe file must be in the same folder as the
WVDAgentUrlTool.config file
Use the Required URL Check tool

To use the Required URL Check tool:
1. Open a command prompt as an administrator on one of your session host VMs.
2. Run the following command to change the directory to the same folder as the
current build agent (RDAgent_1.0.2944.1200 in this example):
Console
cd "C:\Program Files\Microsoft RDInfra\RDAgent_1.0.2944.1200"
3. Run the following command:
Console
WVDAgentUrlTool.exe
4. Once you run the file, you'll see a list of accessible and inaccessible URLs.
For example, the following screenshot shows a scenario where you'd need to
unblock two required non-wildcard URLs:
Here's what the output should look like once you've unblocked all required non-
wildcard URLs:
5. You can repeat these steps on your other session host VMs, particularly if they are
in a different Azure region or use a different virtual network.
Configure RDP Shortpath for Azure
Virtual Desktop
） Important
RDP Shortpath is a feature of Azure Virtual Desktop that establishes a direct UDP-based
transport between a supported Windows Remote Desktop client and session host. This
article shows you how to configure RDP Shortpath for managed networks and public
networks. For more information, see RDP Shortpath.
Prerequisites
Before you can enable RDP Shortpath, you'll need to meet the prerequisites. Select a tab
below for your scenario.
Managed networks
A client device running the Remote Desktop client for Windows, version
1.2.3488 or later. Currently, non-Windows clients aren't supported.
Direct line of sight connectivity between the client and the session host.
Having direct line of sight connectivity means that the client can connect
directly to the session host on port 3390 (default) without being blocked by
firewalls (including the Windows Firewall) or Network Security Group, and
using a managed network such as:
ExpressRoute private peering.
Site-to-site or Point-to-site VPN (IPsec), such as Azure VPN Gateway.
Enable RDP Shortpath

The steps to enable RDP Shortpath differ for session hosts depending on whether you
want to enable it for managed networks or public networks, but are the same for clients.
Select a tab below for your scenario.
Session hosts
Managed networks
To enable RDP Shortpath for managed networks, you need to enable the RDP
Shortpath listener on your session hosts. You can do this using Group Policy, either
centrally from your domain for session hosts that are joined to an Active Directory
(AD) domain, or locally for session hosts that are joined to Azure Active Directory
(Azure AD).
1. Download the Azure Virtual Desktop administrative template and extract

the contents of the .cab file and .zip archive.
2. Depending on whether you want to configure Group Policy centrally from

your AD domain, or locally for each session host:
a. AD Domain: Copy and paste the terminalserver-avd.admx file to the

Central Store for your domain, for example
\\contoso.com\SYSVOL\contoso.com\policies\PolicyDefinitions , where
contoso.com is your domain name. Then copy the en-us\terminalserver-
avd.adml file to the en-us subfolder.
b. Open the Group Policy Management Console (GPMC) and create or edit a
policy that targets your session hosts.
c. Locally: Copy and paste the terminalserver-avd.admx file to

%windir%\PolicyDefinitions . Then copy the en-us\terminalserver-
d. Open the Local Group Policy Editor on the session host.
3. Browse to Computer Configuration > Administrative Templates > Windows

Components > Remote Desktop Services > Remote Desktop Session Host >
Azure Virtual Desktop. You should see policy settings for Azure Virtual
Desktop, as shown in the following screenshot:

4. Open the policy setting Enable RDP Shortpath for managed networks and
set it to Enabled. If you enable this policy setting, you can also configure the
port number that Azure Virtual Desktop session hosts will use to listen for
incoming connections. The default port is 3390.
5. If you need to configure Windows Firewall to allow port 3390, run one of the
following commands, depending on whether you want to configure Windows
Firewall using Group Policy centrally from your AD domain, or locally for each
session host:
a. AD Domain: Open an elevated PowerShell prompt and run the following

command, replacing the value for $domainName with your own domain
name, the value for $writableDC with the hostname of a writeable domain
controller, and the value for $policyName with the name of an existing
Group Policy Object:
PowerShell
$domainName = "contoso.com"
$writableDC = "dc01"
$policyName = "RDP Shortpath Policy"
$gpoSession = Open-NetGPO -PolicyStore "$domainName\$policyName"

-DomainController $writableDC
New-NetFirewallRule -DisplayName 'Remote Desktop - RDP Shortpath

(UDP-In)' -Action Allow -Description 'Inbound rule for the
Remote Desktop service to allow RDP Shortpath traffic. [UDP
3390]' -Group '@FirewallAPI.dll,-28752' -Name 'RemoteDesktop-
UserMode-In-RDPShortpath-UDP' -Profile Domain, Private -Service
TermService -Protocol UDP -LocalPort 3390 -Program
'%SystemRoot%\system32\svchost.exe' -Enabled:True -GPOSession
$gpoSession
Save-NetGPO -GPOSession $gpoSession
b. Locally: Open an elevated PowerShell prompt and run the following

command:
PowerShell
New-NetFirewallRule -DisplayName 'Remote Desktop - RDP Shortpath

(UDP-In)' -Action Allow -Description 'Inbound rule for the
Remote Desktop service to allow RDP Shortpath traffic. [UDP
3390]' -Group '@FirewallAPI.dll,-28752' -Name 'RemoteDesktop-
UserMode-In-RDPShortpath-UDP' -PolicyStore PersistentStore -
Profile Domain, Private -Service TermService -Protocol UDP -
LocalPort 3390 -Program '%SystemRoot%\system32\svchost.exe' -
Enabled:True
6. Select OK and restart your session hosts to apply the policy setting.
Windows clients
The steps to ensure your clients are configured correctly are the same regardless of
whether you want to use RDP Shortpath for managed networks or public networks. You
can do this using Group Policy for managed clients that are joined to an Active Directory
domain, Intune for managed clients that are joined to Azure Active Directory (Azure AD)
and enrolled in Intune, or local Group Policy for clients that aren't managed.
７ Note
By default in Windows, RDP traffic will attempt to use both TCP and UDP protocols.
You will only need to follow these steps if the client has previously been configured
to use TCP only.
Enable RDP Shortpath on managed and unmanaged Windows

clients using Group Policy
To configure managed and unmanaged Windows clients using Group Policy:
1. Depending on whether you want to configure managed or unmanaged clients:
a. For managed clients, open the Group Policy Management Console (GPMC) and
create or edit a policy that targets your clients.
b. For unmanaged clients, open the Local Group Policy Editor on the client.

Components > Remote Desktop Services > Remote Desktop Connection Client.
3. Open the policy setting Turn Off UDP On Client and set it to Not Configured.
4. Select OK and restart your clients to apply the policy setting.
Enable RDP Shortpath on Windows clients using Intune

To configure managed Windows clients using Intune:
1. Sign in to the Microsoft Intune admin center .
2. Create or edit a configuration profile for Windows 10 and later devices, using
Administrative templates.
3. Browse to Windows Components > Remote Desktop Services > Remote Desktop
Connection Client.
4. Select the setting Turn Off UDP On Client and set it to Disabled. Select OK, then
select Next.
5. Apply the configuration profile, then restart your clients.
Teredo support
While not required for RDP Shortpath, Teredo adds extra NAT traversal candidates and
increases the chance of the successful RDP Shortpath connection in IPv4-only networks.
You can enable Teredo on both session hosts and clients by running the following
command from an elevated PowerShell prompt:
PowerShell
Set-NetTeredoConfiguration -Type Enterpriseclient
Verify RDP Shortpath is working

Next, you'll need to make sure your clients are connecting using RDP Shortpath. You can
verify the transport with either the Connection Information dialog from the Remote
Desktop client, or by using Log Analytics.
Connection Information dialog
To make sure connections are using RDP Shortpath, you can check the connection
information on the client. Select a tab below for your scenario.
Managed networks
1. Connect to Azure Virtual Desktop.
2. Open the Connection Information dialog by going to the Connection tool bar
on the top of the screen and select the signal strength icon, as shown in the
following screenshot:
3. You can verify in the output that the transport protocol is UDP (Private
Network), as shown in the following screenshot:
Event Viewer
To make sure connections are using RDP Shortpath, you can check the event logs on the
session host:
1. Connect to Azure Virtual Desktop.
2. On the session host, open Event Viewer.
3. Browse to Applications and Services Logs > Microsoft > Windows >
RemoteDesktopServices-RdpCoreCDV > Operational.
4. Filter by Event ID 135. Connections using RDP Shortpath will state the transport
type is using UDP with the message The multi-transport connection finished for
tunnel: 1, its transport type set to UDP.
Log Analytics
If you're using Azure Log Analytics, you can monitor connections by querying the
WVDConnections table. A column named UdpUse indicates whether Azure Virtual
Desktop RDP Stack is using UDP protocol on the current user connection.
The possible
values are:
1 - The user connection is using RDP Shortpath for managed networks.
2 - The user connection is using RDP Shortpath for public networks directly using
STUN.
4 - The user connection is using RDP Shortpath for public networks indirectly using
TURN.
For any other value, the user connection isn't using RDP Shortpath and is
connected using TCP.
The following query lets you review connection information. You can run this query in
the Log Analytics query editor. For each query, replace user@contoso.com with the UPN
of the user you want to look up.
Kusto
let Events = WVDConnections | where UserName == "user@contoso.com" ;
Events
| where State == "Connected"
| project CorrelationId, UserName, ResourceAlias, StartTime=TimeGenerated,

UdpUse, SessionHostName, SessionHostSxSStackVersion
| join (Events
| where State == "Completed"
| project EndTime=TimeGenerated, CorrelationId, UdpUse)
on CorrelationId
| project StartTime, Duration = EndTime - StartTime, ResourceAlias, UdpUse,

SessionHostName, SessionHostSxSStackVersion
| sort by StartTime asc
You can verify if RDP Shortpath is enabled for a specific user session by running the
following Log Analytics query:
Kusto
WVDCheckpoints
| where Name contains "Shortpath"
To learn more about error information you may see logged in Log Analytics,
Disable RDP Shortpath

The steps to disable RDP Shortpath differ for session hosts depending on whether you
want to disable it for managed networks only, public networks only, or both. Select a tab
below for your scenario.
Session hosts
Managed networks
To disable RDP Shortpath for managed networks on your session hosts, you need to
disable the RDP Shortpath listener. You can do this using Group Policy, either
centrally from your domain for session hosts that are joined to an AD domain, or
locally for session hosts that are joined to Azure AD.
Alternatively, you can block port 3390 (default) to your session hosts on a firewall
or Network Security Group.
1. Depending on whether you want to configure Group Policy centrally from

your domain, or locally for each session host:
a. AD Domain: Open the Group Policy Management Console (GPMC) and

edit the existing policy that targets your session hosts.
b. Locally: Open the Local Group Policy Editor on the session host.

Azure Virtual Desktop. You should see policy settings for Azure Virtual
Desktop providing you have the administrative template from when you
enabled RDP Shortpath for managed networks.
3. Open the policy setting Enable RDP Shortpath for managed networks and
set it to Not Configured.
4. Select OK and restart your session hosts to apply the policy setting.
Windows clients
On client devices, you can disable RDP Shortpath for managed networks and public
networks by configuring RDP traffic to only use TCP. You can do this using Group Policy
for managed clients that are joined to an Active Directory domain, Intune for managed
clients that are joined to (Azure AD) and enrolled in Intune, or local Group Policy for
clients that aren't managed.
） Important
If you have previously set RDP traffic to attempt to use both TCP and UDP
protocols using Group Policy or Intune, ensure the settings don't conflict.
Disable RDP Shortpath on managed and unmanaged Windows

clients using Group Policy
To configure managed and unmanaged Windows clients using Group Policy:
1. Depending on whether you want to configure managed or unmanaged clients:
a. For managed clients, open the Group Policy Management Console (GPMC) and
create or edit a policy that targets your clients.
b. For unmanaged clients, open the Local Group Policy Editor on the client.

Components > Remote Desktop Services > Remote Desktop Connection Client.
3. Open the policy setting Turn Off UDP On Client and set it to Enabled.
4. Select OK and restart your clients to apply the policy setting.

Disable RDP Shortpath on Windows clients using Intune
To configure managed Windows clients using Intune:
1. Sign in to the Microsoft Intune admin center .
2. Create or edit a configuration profile for Windows 10 and later devices, using
Administrative templates.
3. Browse to Windows Components > Remote Desktop Services > Remote Desktop
Connection Client.
4. Select the setting Turn Off UDP On Client and set it to Enabled. Select OK, then
select Next.
5. Apply the configuration profile, then restart your clients.
Next steps
Learn how to limit the port range used by clients using RDP Shortpath for public
networks.
If you're having trouble establishing a connection using the RDP Shortpath
transport for public networks, see Troubleshoot RDP Shortpath.
 Documentation






Show 5 more
Limit the port range when using RDP
Shortpath for public networks
By default, RDP Shortpath for public networks uses an ephemeral port range of 49152 to
65535 to establish a direct path between server and client. However, you may want to
configure your session hosts to use a smaller, predictable port range.
You can set a smaller default range of ports 38300 to 39299, or you can specify your
own port range to use. When enabled on your session hosts, the Remote Desktop client
will randomly select the port from the range you specify for every connection. If this
range is exhausted, clients will fall back to using the default port range (49152-65535).
When choosing the base and pool size, consider the number of ports you choose. The
range must be between 1024 and 49151, after which the ephemeral port range begins.
Prerequisites
A client device running the Remote Desktop client for Windows, version 1.2.3488
or later. Currently, non-Windows clients aren't supported.
Internet access for both clients and session hosts. Session hosts require outbound
UDP connectivity from your session hosts to the internet. For more information
you can use to configure firewalls and Network Security Group, see Network
configurations for RDP Shortpath.
Enable a limited port range

To enable a limited port range when using RDP Shortpath for public networks, you can
use Group Policy, either centrally from your domain for session hosts that are joined to
an Active Directory (AD) domain, or locally for session hosts that are joined to Azure
Active Directory (Azure AD).
1. Download the Azure Virtual Desktop administrative template and extract the
contents of the .cab file and .zip archive.
2. Depending on whether you want to configure Group Policy centrally from your
domain, or locally for each session host:
AD Domain:
a. Copy and paste the terminalserver-avd.admx file to the Central Store for your
domain, for example
\\contoso.com\SYSVOL\contoso.com\policies\PolicyDefinitions , where
contoso.com is your domain name. Then copy the en-us\terminalserver-

b. Open the Group Policy Management Console (GPMC) and create or edit a
Locally:
a. Copy and paste the terminalserver-avd.admx file to

%windir%\PolicyDefinitions . Then copy the en-us\terminalserver-avd.adml file
to the en-us subfolder.
b. Open the Local Group Policy Editor on the session host.

Azure Virtual Desktop. You should see policy settings for Azure Virtual Desktop, as
shown in the following screenshot:
4. Open the policy setting Use port range for RDP Shortpath for unmanaged
networks and set it to Enabled. For UDP base port, specify the port number to
begin the range. For Port pool size, specify the number of sequential ports that
will be in the range. For example, if you specify 38300 as the UDP base port and
1000 as the Port pool size, the upper port number will be 39299.

Set up Private Link for Azure Virtual
Desktop (preview)
） Important
Private Link for Azure Virtual Desktop is currently in PREVIEW.

See the
Supplemental Terms of Use for Microsoft Azure Previews for legal terms that
apply to Azure features that are in beta, preview, or otherwise not yet released into
general availability.
This article will show you how to set up Private Link for Azure Virtual Desktop (preview)
in your Azure Virtual Desktop deployment. For more information about what Private
Link can do for your deployment and the limitations of the public preview version, see
Private Link for Azure Virtual Desktop (preview).
Prerequisites
In order to use Private Link in your Azure Virtual Desktop deployment, you'll need the
following things:

An Azure Virtual Desktop deployment with service objects, such as host pools, app
groups, and workspaces.
The required permissions to use Private Link.
） Important
There's currently a bug in version 1.2.3918 of the Remote Desktop client for
Windows that causes a client regression when you use Private Link. In order to use
Private Link in your deployment, you must use a version later than 1.2.3918. Using
an earlier version of the Remote Desktop client can potentially cause security
issues. We don't recommend using version 1.2.3918 for environments or VMs that
you aren't using to preview Private Link.
Re-register your resource provider

In the public preview version of Private Link, after you create your resources, you'll need
to re-register them to your resource provider before you can start using Private Link. Re-
registering allows the service to download and assign the new roles that will let you use
this feature.
To re-register your resource provider:
2. Select Subscriptions.
3. Select the name of your subscription.
4. Select Resource providers.
5. Search for Microsoft.DesktopVirtualization.
6. Select Microsoft.DesktopVirtualization, then select Re-register.
7. Verify that the status of Microsoft.DesktopVirtualization is Registered.
Enable preview content on your Azure

subscription
In order to use Private Link, you'll need to enable preview features on your Azure
subscription first. To enable preview features:
1. Go to Preview features - Microsoft Azure .
2. In the search box under Preview features, search for Private.
3. Select the Azure Virtual Desktop Private Link Public Preview check box.
4. In the bottom-right corner of the screen, select Register.
Once you select Register, you'll be able to use Private Link.
Create a placeholder workspace

A private endpoint to the global sub-resource of any workspace controls the shared fully
qualified domain name (FQDN) for initial feed discovery. This control enables feed
discovery for all workspaces. Because the workspace connected to the private endpoint
is so important, deleting it will cause all feed discovery processes to stop working.
Instead of deleting the workspace, you should create an unused placeholder workspace
to terminate the global endpoint before you start using Private Link. To create a
workspace, follow the instructions in Workspace information.
Set up Private Link in the Azure portal

Now, let's set up Private Link for your host pool. During the setup process, you'll create
private endpoints to the following resources:
Resource type Target sub- Quantity

resource
Microsoft.DesktopVirtualization/workspaces global One for all Azure Virtual Desktop

deployments
Microsoft.DesktopVirtualization/workspaces feed One per workspace
Microsoft.DesktopVirtualization/hostpools connection One per host pool
To configure Private Link in the Azure portal:
1. Open the Azure portal and sign in.
3. Go to Host pools, then select the name of the host pool you want to use.
 Tip
You can also start setting up by going to Private Link Center > Private
Endpoints > Add a private endpoint.
4. After you've opened the host pool, go to Networking > Private Endpoint
connections.
5. Select New private endpoint.
6. In the Basics tab, either use the drop-down menus to select the Subscription and
Resource group you want to use or create a new resource group.
7. Next, enter a name for your new private endpoint. The network interface name will
fill automatically.
8. Select the region your private endpoint will be located in. You must choose the
same location as your session host and the virtual network (VNet) you plan to use.
9. When you're done, select Next: Resource >.
10. In the Resource tab, use the following resource:
Resource type: Microsoft.DesktopVirtualization/hostpools

Resource: your host pool
Target sub-resource: connection
11. Select Next: Virtual Network >.
12. In the Virtual Network tab, make sure the values in the Virtual Network and
subnet fields are correct.
13. In the Private IP configuration field, choose whether you want to dynamically or
statically allocate IP addresses from the subnet you selected in the previous step.
If you choose to statically allocate IP addresses, you'll need to fill in the Name
and Private IP for each listed member.
14. Next, select an existing application security group or create a new one.
If you're creating a new application security group, select Create new, then
enter a name for the new security group.
15. When you're finished, select Next: DNS >.
16. In the DNS tab, in the Integrate with private DNS zone field, select Yes if you want
to integrate with an Azure private DNS zone. The private DNS zone name is
privatelink.wvd.microsoft.com . Learn more about integration at Azure Private
endpoint DNS configuration.
17. When you're done, select Next: Tags >.
18. In the Tags tab, you can optionally add tags to help the Azure service categorize
your resources. If you don't want to add tags, select Next: Review + create.
19. Review the details of your private endpoint. If everything looks good, select Create
and wait for the deployment to finish.
20. Now, repeat the process to create private endpoints for your resources. Return to
step 3, but select Workspaces instead of host pools and use the following
resources, then follow the rest of the steps until the end.
Resource type: Microsoft.DesktopVirtualization/workspaces
Resource: your placeholder workspace

Target sub-resource: global
Resource type: Microsoft.DesktopVirtualization/workspaces
Resource: your workspace
Target sub-resource: feed
７ Note
You'll need to repeat this process to create a private endpoint for every resource
you want to put into Private Link.
Closing public routes

In addition to creating private routes, you can also control if the Azure Virtual Desktop
resource allows traffic to come from public routes.
To control public traffic:
1. Open the Azure portal and sign in.
3. Go to Host pools > Networking > Firewall and virtual networks.
4. First, configure the Allow end users access from public network setting.
If you select the check box, users can connect to the host pool using public
internet or private endpoints.
If you don't select the check box, users can only connect to host pool using
private endpoints.
5. Next, configure the Allow session hosts access from public network setting.
If you select the check box, Azure Virtual Desktop session hosts will talk to
the Azure Virtual Desktop service over public internet or private endpoints.
If you don't select the check box, Azure Virtual Desktop session hosts can
only talk to the Azure Virtual Desktop service over private endpoint
connections.
Network security groups

Follow the directions in Tutorial: Filter network traffic with a network security group
using the Azure portal to set up a network security group (NSG). You can use this NSG
to block the WindowsVirtualDesktop service tag. If you block this service tag, all service
traffic will use private routes only.
When you set up your NSG, you must configure it to allow both the URLs in the required
URL list and your private endpoints. Make sure to include the URLs for Azure Monitor.
７ Note
If you intend to restrict network ports from either the user client devices or your
session host VMs to the private endpoints, you will need to allow traffic across the
entire TCP dynamic port range of 1 - 65535 to the private endpoint for the host
pool resource using the connection sub-resource. The entire TCP dynamic port
range is needed because port mapping is used to all global gateways through the
single private endpoint IP address corresponding to the connection sub-resource.
If you restrict ports to the private endpoint, your users may not be able to connect
successfully to Azure Virtual Desktop.
Validate your Private Link deployment

To validate your Private Link for Azure Virtual Desktop and make sure it's working:
1. Check to see if your session hosts are registered and functional on the VNet. You
can check their health status with Azure Monitor.
2. Next, test your feed connections to make sure they perform as expected. Use the
client and make sure you can add and refresh workspaces.
3. Finally, run the following end-to-end tests:
Make sure your clients can't connect to Azure Virtual Desktop and your
session hosts from public routes.
Make sure the session hosts can't connect to Azure Virtual Desktop from
public routes.
Next steps
Learn more about how Private Link for Azure Virtual Desktop at Use Private Link
with Azure Virtual Desktop.
Learn how to configure Azure Private Endpoint DNS at Private Link DNS
integration.
For general troubleshooting guides for Private Link, see Troubleshoot Azure Private
Endpoint connectivity problems
Understand how connectivity for the Azure Virtual Desktop service works atAzure
Virtual Desktop network connectivity
See the Required URL list for the list of URLs you'll need to unblock to ensure
network access to the Azure Virtual Desktop service.
Use Azure Firewall to protect Azure Virtual
Desktop deployments
Azure Virtual Desktop is a desktop and app virtualization service that runs on Azure. When an end
user connects to an Azure Virtual Desktop environment, their session is run by a host pool. A host
pool is a collection of Azure virtual machines that register to Azure Virtual Desktop as session hosts.
These virtual machines run in your virtual network and are subject to the virtual network security
controls. They need outbound Internet access to the Azure Virtual Desktop service to operate
properly and might also need outbound Internet access for end users. Azure Firewall can help you
lock down your environment and filter outbound traffic.
Follow the guidelines in this article to provide extra protection for your Azure Virtual Desktop host
pool using Azure Firewall.
Prerequisites
A deployed Azure Virtual Desktop environment and host pool.
An Azure Firewall deployed with at least one Firewall Manager Policy.
DNS and DNS Proxy enabled in the Firewall Policy to use FQDN in Network Rules.
For more information, see Tutorial: Create a host pool by using the Azure portal
To learn more about Azure Virtual Desktop environments see Azure Virtual Desktop environment.
Host pool outbound access to Azure Virtual Desktop

The Azure virtual machines you create for Azure Virtual Desktop must have access to several Fully
Qualified Domain Names (FQDNs) to function properly. Azure Firewall provides an Azure Virtual
Desktop FQDN Tag to simplify this configuration. Use the following steps to allow outbound Azure
Virtual Desktop platform traffic:
You'll need to create an Azure Firewall Policy and create Rule Collections for Network Rules and
Applications Rules. Give the Rule Collection a priority and an allow or deny action.
In order to
identify a specific AVD Host Pool as "Source" in the tables below, IP Group can be created to
represent it.
Create network rules

Based on the Azure Virtual Desktop (AVD) reference article, these are the mandatory rules to allow
outbound access to the control plane and core dependent services:
Azure cloud
Name Source Source Protocol Destination Destination Destination

type ports type
Rule IP IP TCP 443 FQDN login.microsoftonline.com

Name Address Group
or or VNet
Group or
Subnet
IP
Address
Rule IP IP TCP 443 Service Tag WindowsVirtualDesktop ,

Name Address Group AzureFrontDoor.Frontend , AzureMonitor
or or VNet
Group or
Subnet
IP
Address
Rule IP IP TCP, 53 IP Address *

Name Address Group UDP
or or VNet
Group or
Subnet
IP
Address
Rule IP IP TCP 1688 IP address 20.118.99.224 , 40.83.235.53

name Address Group ( azkms.core.windows.net )
or or VNet
Group or
Subnet
IP
Address
type ports type
Rule IP IP TCP 1688 IP address 23.102.135.246 ( kms.core.windows.net )

name Address Group
or or VNet
Group or
Subnet
IP
Address
Rule IP IP TCP 443 FQDN mrsglobalsteus2prod.blob.core.windows.net

name Address Group
or or VNet
Group or
Subnet
IP
Address
Rule IP IP TCP 443 FQDN wvdportalstorageblob.blob.core.windows.net

name Address Group
or or VNet
Group or
Subnet
IP
Address
Rule IP IP TCP 80 FQDN oneocsp.microsoft.com

name Address Group
or or VNet
Group or
Subnet
IP
Address
Rule IP IP TCP 80 FQDN www.microsoft.com

name Address Group
or or VNet
Group or
Subnet
IP
Address
７ Note
Some deployments might not need DNS rules. For example, Azure Active Directory Domain
controllers forward DNS queries to Azure DNS at 168.63.129.16.
Azure Virtual Desktop (AVD) official documentation reports the following Network rules as optional
depending on the usage and scenario:
type ports type
Rule IP Address IP Group or VNet UDP 123 FQDN time.windows.com

Name or Group or Subnet IP
Address
Rule IP Address IP Group or VNet TCP 443 FQDN login.windows.net

Address
Rule IP Address IP Group or VNet TCP 443 FQDN www.msftconnecttest.com

Address
Create application rules

Azure Virtual Desktop (AVD) official documentation reports the following Application rules as
optional depending on the usage and scenario:
Name Source Source Protocol Destination Destination

type type
Rule IP Address VNet or Subnet Https:443 FQDN Tag WindowsUpdate , Windows Diagnostics ,
Name or Group IP Address MicrosoftActiveProtectionService
Rule IP Address VNet or Subnet Https:443 FQDN *.events.data.microsoft.com

Name or Group IP Address
Rule IP Address VNet or Subnet Https:443 FQDN *.sfx.ms

Rule IP Address VNet or Subnet Https:443 FQDN *.digicert.com

Rule IP Address VNet or Subnet Https:443 FQDN *.azure-dns.com , *.azure-dns.net

） Important
We recommend that you don't use TLS inspection with Azure Virtual Desktop. For more
information, see the proxy server guidelines.
Azure Firewall Policy Sample

All the mandatory and optional rules mentioned above can be easily deployed a single Azure
Firewall Policy using the template published at this link .
Before deploying into production, it's
highly recommended to review all the Network and Application rules defined, ensure alignment with
Azure Virtual Desktop official documentation and security requirements.
Host pool outbound access to the Internet
Depending on your organization needs, you might want to enable secure outbound internet access
for your end users. If the list of allowed destinations is well-defined (for example, for Microsoft 365
access), you can use Azure Firewall application and network rules to configure the required access.
This routes end-user traffic directly to the internet for best performance. If you need to allow
network connectivity for Windows 365 or Intune, see Network requirements for Windows 365 and
Network endpoints for Intune.
If you want to filter outbound user internet traffic by using an existing on-premises secure web
gateway, you can configure web browsers or other applications running on the Azure Virtual
Desktop host pool with an explicit proxy configuration. For example, see How to use Microsoft Edge
command-line options to configure proxy settings. These proxy settings only influence your end-
user internet access, allowing the Azure Virtual Desktop platform outbound traffic directly via Azure
Firewall.
Control user access to the web

Admins can allow or deny user access to different website categories. Add a rule to your Application
Collection from your specific IP address to web categories you want to allow or deny. Review all the
web categories.
Next steps
Learn more about Azure Virtual Desktop: What is Azure Virtual Desktop?
 Documentation
Networking for Azure Virtual Desktop - Cloud Adoption Framework

Use the Cloud Adoption Framework for Azure to identify networking capabilities that your landing zone needs to
support Azure Virtual Desktop workloads.
Use Azure Private Link with Azure Virtual Desktop preview - Azure
Learn how Azure Private Link (preview) can help you keep network traffic private.



Learn about RDP Shortpath for Azure Virtual Desktop, which establishes a UDP-based transport between a Remote
Desktop client and session host.
Proxy server guidelines Azure Virtual Desktop - Azure
Some guidelines and recommendations for using proxy servers in Azure Virtual Desktop deployments.
Set up Private Link for Azure Virtual Desktop preview - Azure

How to set up Private Link for Azure Virtual Desktop (preview).
Show 4 more
 Training

Azure Virtual Desktop on Microsoft Azure is a desktop and app virtualization service that runs on the cloud. Azure
Virtual Desktop works across devices – including Windows, Mac, iOS, and Android – with full-featured apps that
you can use to access remote desktops and apps.
Candidates for this certification are server or desktop administrators with subject matter expertise in designing,
implementing, managing, and maintaining Microsoft Azure Virtual Desktop experiences and remote apps for any
device.
Create a profile container for a host
pool using a file share
The Azure Virtual Desktop service offers FSLogix profile containers as the recommended
user profile solution. We don't recommend using the User Profile Disk (UPD) solution,
which will be deprecated in future versions of Azure Virtual Desktop.
This article will tell you how to set up a FSLogix profile container share for a host pool
using a virtual machine-based file share. We strongly recommend using Azure Files
instead of file shares. For more FSLogix documentation, see the FSLogix site .
７ Note
If you're looking for comparison material about the different FSLogix Profile
Container storage options on Azure, see Storage options for FSLogix profile
containers.
Create a new virtual machine that will act as a

file share
When creating the virtual machine, be sure to place it on either the same virtual network
as the host pool virtual machines or on a virtual network that has connectivity to the
host pool virtual machines. It must also be joined to your Active Directory domain. You
can create a virtual machine in multiple ways. Here are a few options:
Create a virtual machine from an Azure Gallery image

Create a virtual machine from a managed image
Create a virtual machine from an unmanaged image
Prepare the virtual machine to act as a file

share for user profiles
The following are general instructions about how to prepare a virtual machine to act as
a file share for user profiles:
1. Add the Azure Virtual Desktop Active Directory users to an Active Directory
security group. This security group will be used to authenticate the Azure Virtual
Desktop users to the file share virtual machine you just created.
2. Connect to the file share virtual machine.
3. On the file share virtual machine, create a folder on the C drive that will be used as
the profile share.
4. Right-click the new folder, select Properties, select Sharing, then select Advanced
sharing....
5. Select Share this folder, select Permissions..., then select Add....
6. Search for the security group to which you added the Azure Virtual Desktop users,
then make sure that group has Full Control.
7. After adding the security group, right-click the folder, select Properties, select
Sharing, then copy down the Network Path to use for later.
For more information about permissions, see the FSLogix documentation.
Configure the FSLogix profile container

To configure FSLogix profile container, do the following on each session host registered
to the host pool:
1. Connect to the virtual machine with the credentials you provided when creating
the virtual machine.
2. Launch an internet browser and download the FSLogix agent .
3. Open the downloaded .zip file, navigate to either Win32\Release or x64\Release

(depending on your operating system) and run FSLogixAppsSetup to install the
FSLogix agent. To learn more about how to install FSLogix, see Download and
install FSLogix.
4. Navigate to Program Files > FSLogix > Apps to confirm the agent installed
successfully.
5. From the start menu, run regedit as an administrator. Navigate to

Computer\HKEY_LOCAL_MACHINE\Software\FSLogix.
6. Create a key named Profiles.
7. Create the following values for the Profiles key (replacing \\hostname\share with
your real path):
Enabled DWORD 1
VHDLocations Multi-String Value \\hostname\share

Create a profile container with Azure
NetApp Files and AD DS
We recommend using FSLogix profile containers as a user profile solution for the Azure
Virtual Desktop service. FSLogix profile containers store a complete user profile in a
single container and are designed to roam profiles in non-persistent remote computing
environments like Azure Virtual Desktop. When you sign in, the container dynamically
attaches to the computing environment using a locally supported virtual hard disk
(VHD) and Hyper-V virtual hard disk (VHDX). These advanced filter-driver technologies
allow the user profile to be immediately available and appear in the system exactly like a
local user profile. To learn more about FSLogix profile containers, see FSLogix profile
containers and Azure Files.
You can create FSLogix profile containers using Azure NetApp Files , an easy-to-use
Azure native platform service that helps customers quickly and reliably provision
enterprise-grade SMB volumes for their Azure Virtual Desktop environments. To learn
more about Azure NetApp Files, see What is Azure NetApp Files?
This guide will show you how to set up an Azure NetApp Files account and create
FSLogix profile containers in Azure Virtual Desktop. It assumes you have already created
a host pool and an application group.
The instructions in this guide are specifically for Azure Virtual Desktop users. If you're
looking for more general guidance for how to set up Azure NetApp Files and create
FSLogix profile containers outside of Azure Virtual Desktop, see the Set up Azure
NetApp Files and create an NFS volume quickstart.
７ Note
This article doesn't cover best practices for securing access to the Azure NetApp
Files share.
７ Note
If you're looking for comparison material about the different FSLogix Profile
Container storage options on Azure, see Storage options for FSLogix profile
containers.
Prerequisites
Before you can create an FSLogix profile container for a host pool, you must:
Set up and configure Azure Virtual Desktop

Provision an Azure Virtual Desktop host pool
Set up your Azure NetApp Files account

To get started, you need to set up an Azure NetApp Files account.
1. Sign in to the Azure portal . Make sure your account has contributor or
administrator permissions.
2. Select the Azure Cloud Shell icon to the right of the search bar to open Azure
Cloud Shell.
3. Once Azure Cloud Shell is open, select PowerShell.
4. If this is your first time using Azure Cloud Shell, create a storage account in the
same subscription you keep your Azure NetApp Files and Azure Virtual Desktop.
5. Once Azure Cloud Shell loads, run the following two cmdlets.
Azure CLI
az account set --subscription <subscriptionID>
Azure CLI
az provider register --namespace Microsoft.NetApp --wait
6. In the left side of the window, select All services. Enter Azure NetApp Files into the
search box that appears at the top of the menu.
7. Select Azure NetApp Files in the search results, then select Create.
8. Select the Add button.
9. When the New NetApp account tab opens, enter the following values:
For Name, enter your NetApp account name.

For Subscription, select the subscription for the storage account you set up
in step 4 from the drop-down menu.
For Resource group, either select an existing resource group from the drop-
down menu or create a new one by selecting Create new.
For Location, select the region for your NetApp account from the drop-down
menu. This region must be the same region as your session host VMs.
７ Note
Azure NetApp Files currently doesn't support mounting of a volume across

regions.
10. When you're finished, select Create to create your NetApp account.
Create a capacity pool

Next, create a new capacity pool:
1. Go to the Azure NetApp Files menu and select your new account.
2. In your account menu, select Capacity pools under Storage service.
3. Select Add pool.
4. When the New capacity pool tab opens, enter the following values:
For Name, enter a name for the new capacity pool.

For Service level, select your desired value from the drop-down menu. We
recommend Premium for most environments.
７ Note
The Premium setting provides the minimum throughput available for a

Premium Service level, which is 256 MBps. You may need to adjust this
throughput for a production environment. Final throughput is based on
the relationship described in Throughput limits.
For Size (TiB), enter the capacity pool size that best fits your needs. The
minimum size is 4 TiB.
5. When you're finished, select OK.
Join an Active Directory connection

After that, you need to join an Active Directory connection.
1. Select Active Directory connections in the menu on the left side of the page, then
select the Join button to open the Join Active Directory page.
2. Enter the following values in the Join Active Directory page to join a connection:
For Primary DNS, enter the IP address of the DNS server in your environment
that can resolve the domain name.
For Secondary DNS, enter the IP address of the secondary DNS Server for the
domain.
For AD DNS Domain Name, enter your fully qualified domain name (FQDN).
For AD Site Name, enter the Active Directory Site name that the domain
controller discovery will be limited to. This should match the Site name in
Active Directory Sites and Services for the Site created to represent the Azure
virtual network environment. This Site must be reachable by Azure NetApp
Files in Azure.
For SMB Server (Computer Account) Prefix, enter the string you want to
append to the computer account name.
For Organizational unit path, this is the LDAP path for the organizational unit
(OU) where SMB server machine accounts will be created. That is, OU=second
level, OU=first level. If you are using Azure NetApp Files with Azure Active
Directory Domain Services, the organizational unit path is OU=AADDC
Computers when you configure Active Directory for your NetApp account.
For Credentials, insert username and password:
For additional parameters descriptions, please refer to this article.
Click Join, the Active Directory connection you created appears.

Create a new volume
Next, you'll need to create a new volume.
1. Select Volumes, then select Add volume.
2. When the Create a volume tab opens, enter the following values:
For Volume name, enter a name for the new volume.

For Capacity pool, select the capacity pool you just created from the drop-
down menu.
For Quota (GiB), enter the volume size appropriate for your environment.
For Virtual network, select an existing virtual network that has connectivity to
the domain controller from the drop-down menu.
Under Subnet, select Create new. Keep in mind that this subnet will be
delegated to Azure NetApp Files.
3. Select Next: Protocol >> to open the Protocol tab and configure your volume
access parameters.
Configure volume access parameters

After you create the volume, configure the volume access parameters.
1. Select SMB as the protocol type.
2. Under Configuration in the Active Directory drop-down menu, select the same
directory that you originally connected in Join an Active Directory connection.
Keep in mind that there's a limit of one Active Directory per subscription.
3. In the Share name text box, enter the name of the share used by the session host
pool and its users.
It is recommended that you enable Continuous Availability on the SMB volume for
use with FsLogix profile containers, so select Enable Continuous Availability. For
more information see Enable Continuous Availability on existing SMB volumes.
4. Select Review + create at the bottom of the page. This opens the validation page.
After your volume is validated successfully, select Create.
5. At this point, the new volume will start to deploy. Once deployment is complete,
you can use the Azure NetApp Files share.
6. To see the mount path, select Go to resource and look for it in the Overview tab.
Configure FSLogix on session host virtual
machines (VMs)
This section is based on Create a profile container for a host pool using a file share.
1. Download the FSLogix agent .zip file while you're still remoted in the session
host VM.
2. Unzip the downloaded file.
3. In the file, go to x64 > Releases and run FSLogixAppsSetup.exe. The installation
menu will open.
4. If you have a product key, enter it in the Product Key text box.
5. Select the check box next to I agree to the license terms and conditions.
6. Select Install.
7. Navigate to C:\Program Files\FSLogix\Apps to confirm the agent installed.
8. From the Start menu, run RegEdit as administrator.
9. Navigate to Computer\HKEY_LOCAL_MACHINE\software\FSLogix.
10. Create a key named Profiles.
11. Create a value named Enabled with a REG_DWORD type set to a data value of 1.
12. Create a value named VHDLocations with a Multi-String type and set its data
value to the URI for the Azure NetApp Files share.
13. Create a value named DeleteLocalProfileWhenVHDShouldApply with a DWORD

value of 1 to avoid problems with existing local profiles before you sign in.
２ Warning
Be careful when creating the DeleteLocalProfileWhenVHDShouldApply value.

When the FSLogix Profiles system determines a user should have an FSLogix
profile, but a local profile already exists, Profile Container will permanently
delete the local profile. The user will then be signed in with the new FSLogix
profile.
Make sure users can access the Azure NetApp

File share
1. Browse to https://rdweb.wvd.microsoft.com/arm/webclient .
2. Sign in with the credentials of a user assigned to the Remote Desktop group.
3. Once you've established the user session, sign in to the Azure portal with an
administrative account.
4. Open Azure NetApp Files, select your Azure NetApp Files account, and then select
Volumes. Once the Volumes menu opens, select the corresponding volume.
5. Go to the Overview tab and confirm that the FSLogix profile container is using
space.
6. Connect directly to any VM part of the host pool using Remote Desktop and open
the File Explorer. Then navigate to the Mount path
(in the following example, the
mount path is \\anf-SMB-3863.gt1107.onmicrosoft.com\anf-VOL).
Within this folder, there should be a profile VHD (or VHDX) like the one in the
following example.
 Documentation
Create Azure NetApp files Azure Virtual Desktop - Azure

This article describes how to create Azure NetApp Files in Azure Virtual Desktop.
Storage FSLogix profile container Azure Virtual Desktop - Azure

Options for storing your Azure Virtual Desktop FSLogix profile on Azure Storage.



Azure Virtual Desktop disaster recovery concepts

Understand what a disaster recovery plan for Azure Virtual Desktop is and how each plan works.

Show 5 more
 Training
Module
Implement and manage FSLogix - Training
Implement and manage FSLogix
Upload MSIX images to Azure NetApp
Files in Azure Virtual Desktop
This article describes how to upload MSIX images to Azure NetApp Files in Azure Virtual
Desktop.
Requirements
Before you can start uploading the images, you'll need to set up Azure NetApp Files if
you haven't already.
To set up Azure NetApp Files, you'll need the following things:
An Azure account with contributor or administrator access
A virtual machine (VM) or physical machine joined to Active Directory Domain

Services (AD DS), and permissions to access it
An Azure Virtual Desktop host pool made of domain-joined session hosts. Each
session host must be in the same region as the region you create your Azure
NetApp files in. For more information, see regional availability . If your existing
session hosts aren't in one of the available regions, you'll need to create new ones.
Start using Azure NetApp Files

To start using Azure NetApp Files:
1. Set up your Azure NetApp Files account by following the instructions in Set up
your Azure NetApp Files account.
2. Create a capacity pool by following the instructions in Set up a capacity pool.
3. Join an Azure Active Directory (Azure AD) connection by following the instructions
in Join an Active Directory connection.
4. Create a new volume by following the instructions in Create a new volume and
Configure volume access parameters.
5. Make sure your connection to the Azure NetApp Files share works by following the
instructions in Make sure users can access the Azure NetApp Files share.
Upload an MSIX image to the Azure NetApp
file share
Now that you've set up your Azure NetApp Files share, you can start uploading images
to it.
To upload an MSIX image to your Azure NetApp Files share:
1. In each session host, install the certificate that you signed the MSIX package with.
Make sure to store the certificates in the folder named Trusted People.
2. Copy the MSIX image you want to add to the Azure NetApps Files share.
3. Go to File Explorer and enter the mount path, then paste the MSIX image into the
mount path folder.
Your MSIX image should now be accessible to your session hosts when they add an
MSIX package using the Azure portal or PowerShell.
Next steps
Now that you've created an Azure NetApp Files share, here are some resources about
what you can use it for in Azure Virtual Desktop:
Create a profile container with Azure NetApp Files and AD DS

Storage options for FSLogix profile containers in Azure Virtual Desktop
Create replication peering for Azure NetApp Files
Set up FSLogix Profile Container with
Azure Files and Active Directory Domain
Services or Azure Active Directory
Domain Services
This article will show you how to set up FSLogix Profile Container with Azure Files when
your session host virtual machines (VMs) are joined to an Active Directory Domain
Services (AD DS) domain or Azure Active Directory Domain Services (Azure AD DS)
managed domain.
Prerequisites
You'll need the following:
A host pool where the session hosts are joined to an AD DS domain or Azure AD
DS managed domain and users are assigned.
A security group in your domain that contains the users who will use Profile
Container. If you're using AD DS, this must be synchronized to Azure AD.
Permission on your Azure subscription to create a storage account and add role
assignments.
A domain account to join computers to the domain and open an elevated
PowerShell prompt.
The subscription ID of your Azure subscription where your storage account will be.
A computer joined to your domain for installing and running PowerShell modules
that will join a storage account to your domain. This device will need to be running
a Supported version of Windows. Alternatively, you can use a session host.
） Important
If users have previously signed in to the session hosts you want to use, local
profiles will have been created for them and must be deleted first by an
administrator for their profile to be stored in a Profile Container.
Set up a storage account for Profile Container

To set up a storage account:
2. Search for Storage accounts in the search bar.
3. Select + Create.
4. Enter the following information into the Basics tab on the Create storage account
page:
Create a new resource group or select an existing one to store the storage
account in.
Enter a unique name for your storage account. This storage account name
needs to be between 3 and 24 characters.
For Region, we recommend you choose the same location as the Azure
Virtual Desktop host pool.
For Performance, select Standard as a minimum.
If you select Premium performance, set the Premium account type to File
shares.
For Redundancy, select Locally-redundant storage (LRS) as a minimum.
The defaults on the remaining tabs don't need to be changed.
 Tip
Your organization may have requirements to change these defaults:
Whether you should select Premium depends on your IOPS and latency
requirements. For more information, see Storage options for FSLogix
Profile Containers in Azure Virtual Desktop.
On the Advanced tab, Enable storage account key access must be left
enabled.
For more information on the remaining configuration options, see
Planning for an Azure Files deployment.
5. Select Review + create. Review the parameters and the values that will be used,
then select Create.
6. Once the storage account has been created, select Go to resource.
7. In the Data storage section, select File shares.
8. Select + File share.

9. Enter a Name, such as Profiles, then for the tier select Transaction optimized.
Join your storage account to Active Directory

To use Active Directory accounts for the share permissions of your file share, you need
to enable AD DS or Azure AD DS as a source. This process joins your storage account to
a domain, representing it as a computer account. Select the relevant tab below for your
scenario and follow the steps.
AD DS
1. Sign in to a computer that is joined to your AD DS domain. Alternatively, sign

in to one of your session hosts.
2. Download and extract the latest version of AzFilesHybrid from the Azure
Files samples GitHub repo. Make a note of the folder you extract the files to.
3. Open an elevated PowerShell prompt and change to the directory where you
extracted the files.
4. Run the following command to add the AzFilesHybrid module to your user's
PowerShell modules directory:
PowerShell
.\CopyToPSPath.ps1
5. Import the AzFilesHybrid module by running the following command:
PowerShell
Import-Module -Name AzFilesHybrid
） Important
This module requires requires the PowerShell Gallery and Azure

PowerShell. You may be prompted to install these if they are not already
installed or they need updating. If you are prompted for these, install
them, then close all instances of PowerShell. Re-open an elevated
PowerShell prompt and import the AzFilesHybrid module again before
continuing.
6. Sign in to Azure by running the command below. You will need to use an
account that has one of the following role-based access control (RBAC) roles:
Storage account owner

Owner
Contributor
PowerShell
Connect-AzAccount
 Tip
If your Azure account has access to multiple tenants and/or subscriptions,

you will need to select the correct subscription by setting your context.
For more information, see Azure PowerShell context objects
7. Join the storage account to your domain by running the commands below,
replacing the values for $subscriptionId , $resourceGroupName , and
$storageAccountName with your values. You can also add the parameter -
OrganizationalUnitDistinguishedName to specify an Organizational Unit (OU) in

which to place the computer account.
PowerShell
$subscriptionId = "subscription-id"
$resourceGroupName = "resource-group-name"
$storageAccountName = "storage-account-name"
Join-AzStorageAccount `
-ResourceGroupName $ResourceGroupName `
-StorageAccountName $StorageAccountName `
-DomainAccountType "ComputerAccount" `
-EncryptionType "'RC4','AES256'"
8. To verify the storage account has joined your domain, run the commands
below and review the output, replacing the values for $resourceGroupName and
$storageAccountName with your values:
PowerShell
$resourceGroupName = "resource-group-name"
$storageAccountName = "storage-account-name"
(Get-AzStorageAccount -ResourceGroupName $resourceGroupName -Name

$storageAccountName).AzureFilesIdentityBasedAuth.DirectoryServiceOp
tions; (Get-AzStorageAccount -ResourceGroupName $resourceGroupName
-Name
$storageAccountName).AzureFilesIdentityBasedAuth.ActiveDirectoryPro
perties
） Important
If your domain enforces password expiration, you must update the password
before it expires to prevent authentication failures when accessing Azure file
shares. For more information, see Update the password of your storage
account identity in AD DS for details.
Assign RBAC role to users

Users needing to store profiles in your file share will need permission to access it. To do
this, you'll need to assign each user the Storage File Data SMB Share Contributor role.
To assign users the role:
1. From the Azure portal, browse to the storage account, then to the file share you
created previously.
2. Select Access control (IAM).
3. Select + Add, then select Add role assignment from the drop-down menu.
4. Select the role Storage File Data SMB Share Contributor and select Next.
5. On the Members tab, select User, group, or service principal, then select +Select
members. In the search bar, search for and select the security group that contains
the users who will use Profile Container.
6. Select Review + assign to complete the assignment.
Set NTFS permissions

Next, you'll need to set NTFS permissions on the folder, which requires you to get the
access key for your Storage account.
To get the Storage account access key:

1. From the Azure portal, search for and select storage account in the search bar.
2. From the list of storage accounts, select the account that you enabled Azure AD DS
and assigned the RBAC role for in the previous sections.
3. Under Security + networking, select Access keys, then show and copy the key
from key1.
To set the correct NTFS permissions on the folder:
1. Sign in to a session host that is part of your host pool.
2. Open an elevated PowerShell prompt and run the command below to map the
storage account as a drive on your session host. The mapped drive will not show in
File Explorer, but can be viewed with the net use command. This is so you can set
permissions on the share.
net use <desired-drive-letter>: \\<storage-account-

name>.file.core.windows.net\<share-name> <storage-account-key>
/user:Azure\<storage-account-name>
Replace <desired-drive-letter> with a drive letter of your choice (for

example, y: ).
Replace all instances of <storage-account-name> with the name of the storage
account you specified earlier.
Replace <share-name> with the name of the share you created earlier.
Replace <storage-account-key> with the storage account key from Azure.
For example:
net use y: \\fsprofile.file.core.windows.net\share

HDZQRoFP2BBmoYQ(truncated)== /user:Azure\fsprofile
3. Run the following commands to set permissions on the share that allow your Azure
Virtual Desktop users to create their own profile while blocking access to the
profiles of other users. You should use an Active Directory security group that
contains the users you want to use Profile Container. In the commands below,
replace <mounted-drive-letter> with the letter of the drive you used to map the
drive and <DOMAIN\GroupName> with the domain and sAMAccountName of the
Active Directory group that will require access to the share. You can also specify
the user principal name (UPN) of a user.
icacls <mounted-drive-letter>: /grant "<DOMAIN\GroupName>:(M)"
icacls <mounted-drive-letter>: /grant "Creator Owner:(OI)(CI)(IO)(M)"
icacls <mounted-drive-letter>: /remove "Authenticated Users"
icacls <mounted-drive-letter>: /remove "Builtin\Users"
For example:
icacls y: /grant "CONTOSO\AVDUsers:(M)"
icacls y: /grant "Creator Owner:(OI)(CI)(IO)(M)"
icacls y: /remove "Authenticated Users"
icacls y: /remove "Builtin\Users"
Configure session hosts to use Profile

Container
In order to use Profile Container, you'll need to make sure FSLogix Apps is installed on
your session host VMs. FSLogix Apps is preinstalled in Windows 10 Enterprise multi-
session and Windows 11 Enterprise multi-session operating systems, but you should still
follow the steps below as it might not have the latest version installed. If you're using a
custom image, you can install FSLogix Apps in your image.
To configure Profile Container, we recommend you use Group Policy Preferences to set
registry keys and values at scale across all your session hosts. You can also set these in
your custom image.
To configure Profile Container on your session host VMs:
1. Sign in to the VM used to create your custom image or a session host VM from
your host pool.
2. If you need to install or update FSLogix Apps, download the latest version of
FSLogix and install it by running FSLogixAppsSetup.exe , then following the
instructions in the setup wizard. For more details about the installation process,
including customizations and unattended installation, see Download and Install
FSLogix.
3. Open an elevated PowerShell prompt and run the following commands, replacing
\\<storage-account-name>.file.core.windows.net\<share-name> with the UNC path
to your storage account you created earlier. These commands enable Profile
Container and configure the location of the share.
PowerShell
$regPath = "HKLM:\SOFTWARE\FSLogix\Profiles"
New-ItemProperty -Path $regPath -Name Enabled -PropertyType DWORD -

Value 1 -Force
New-ItemProperty -Path $regPath -Name VHDLocations -PropertyType

MultiString -Value \\<storage-account-name>.file.core.windows.net\
<share-name> -Force
4. Restart the VM used to create your custom image or a session host VM. You will
need to repeat these steps for any remaining session host VMs.
You have now finished the setting up Profile Container. If you are installing Profile
Container in your custom image, you will need to finish creating the custom image. For
more information, follow the steps in Create a custom image in Azure from the section
Take the final snapshot onwards.
Validate profile creation

Once you've installed and configured Profile Container, you can test your deployment
by signing in with a user account that's been assigned an app group or desktop on the
host pool.
If the user has signed in before, they'll have an existing local profile that they'll use
during this session. Either delete the local profile first, or create a new user account to
use for tests.
Users can check that Profile Container is set up by following the steps below:
1. Sign in to Azure Virtual Desktop as the test user.
2. When the user signs in, the message "Please wait for the FSLogix Apps Services"
should appear as part of the sign-in process, before reaching the desktop.
Administrators can check the profile folder has been created by following the steps
below:
1. Open the Azure portal.
2. Open the storage account you created in previously.

3. Go to Data storage in your storage account, then select File shares.
4. Open your file share and make sure the user profile folder you've created is in
there.
Next steps
You can find more detailed information about concepts related to FSlogix Profile
Container for Azure Files in FSLogix Profile Container for Azure Files.
 Documentation




Create a profile container with Azure Files and Azure Active Directory
Set up an FSLogix profile container on an Azure file share in an existing Azure Virtual Desktop host
pool with your Azure Active Directory domain.


Prepare and customize a VHD image of Azure Virtual Desktop - Azure

How to prepare, customize and upload a Azure Virtual Desktop image to Azure.
Show 5 more
 Training
Module
Implement and manage storage for Azure Virtual Desktop - Training
Implement and manage storage for Azure Virtual Desktop
Create a profile container with Azure
Files and Azure Active Directory
In this article, you'll learn how to create and configure an Azure Files share for Azure
Active Directory (Azure AD) Kerberos authentication. This configuration allows you to
store FSLogix profiles that can be accessed by hybrid user identities from Azure AD-
joined or Hybrid Azure AD-joined session hosts without requiring network line-of-sight
to domain controllers. Azure AD Kerberos enables Azure AD to issue the necessary
Kerberos tickets to access the file share with the industry-standard SMB protocol.
This feature is currently supported in the Azure Public cloud.
Prerequisites
Before deploying this solution, verify that your environment meets the requirements to
configure Azure Files with Azure AD Kerberos authentication.
When used for FSLogix profiles in Azure Virtual Desktop, the session hosts don't need to
have network line-of-sight to the domain controller (DC). However, a system with
network line-of-sight to the DC is required to configure the permissions on the Azure
Files share.
Configure your Azure storage account and file

share
To store your FSLogix profiles on an Azure file share:
1. Create an Azure Storage account if you don't already have one.
７ Note
Your Azure Storage account can't authenticate with both Azure AD and a
second method like Active Directory Domain Services (AD DS) or Azure AD
DS. You can only use one authentication method.
2. Create an Azure Files share under your storage account to store your FSLogix
profiles if you haven't already.
3. Enable Azure Active Directory Kerberos authentication on Azure Files to enable
access from Azure AD-joined VMs.
When configuring the directory and file-level permissions, review the

recommended list of permissions for FSLogix profiles at Configure the
storage permissions for profile containers.
Without proper directory-level permissions in place, a user can delete the
user profile or access the personal information of a different user. It's
important to make sure users have proper permissions to prevent accidental
deletion from happening.
Configure the session hosts

To access Azure file shares from an Azure AD-joined VM for FSLogix profiles, you must
configure the session hosts. To configure session hosts:
1. Enable the Azure AD Kerberos functionality using one of the following methods.
Configure this Intune Policy CSP and apply it to the session host:
Kerberos/CloudKerberosTicketRetrievalEnabled
Configure this Group policy on the session host: Administrative
Templates\System\Kerberos\Allow retrieving the Azure AD Kerberos Ticket
Granting Ticket during logon
Create the following registry value on the session host: reg add
HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters /v
CloudKerberosTicketRetrievalEnabled /t REG_DWORD /d 1
2. When you use Azure AD with a roaming profile solution like FSLogix, the credential
keys in Credential Manager must belong to the profile that's currently loading. This
will let you load your profile on many different VMs instead of being limited to just
one. To enable this setting, create a new registry value by running the following
command:
reg add HKLM\Software\Policies\Microsoft\AzureADAccount /v

LoadCredKeyFromProfile /t REG_DWORD /d 1
７ Note
The session hosts don't need network line-of-sight to the domain controller.
Configure FSLogix on the session host
This section will show you how to configure a VM with FSLogix. You'll need to follow
these instructions every time you configure a session host. There are several options
available that ensure the registry keys are set on all session hosts. You can set these
options in an image or configure a group policy.
To configure FSLogix:
1. Update or install FSLogix on your session host, if needed.
７ Note
If the session host is created using the Azure Virtual Desktop service, FSLogix
should already be pre-installed.
2. Follow the instructions in Configure profile container registry settings to create the
Enabled and VHDLocations registry values. Set the value of VHDLocations to \\
<Storage-account-name>.file.core.windows.net\<file-share-name> .
Test your deployment

Once you've installed and configured FSLogix, you can test your deployment by signing
in with a user account that's been assigned to an application group on the host pool.
The user account you sign in with must have permission to use the file share.
If the user has signed in before, they'll have an existing local profile that the service will
use during this session. To avoid creating a local profile, either create a new user
account to use for tests or use the configuration methods described in Tutorial:
Configure profile container to redirect user profiles to enable the
DeleteLocalProfileWhenVHDShouldApply setting.
Finally, verify the profile created in Azure Files after the user has successfully signed in:
1. Open the Azure portal and sign in with an administrative account.
2. From the sidebar, select Storage accounts.
3. Select the storage account you configured for your session host pool.
4. From the sidebar, select File shares.
5. Select the file share you configured to store the profiles.

6. If everything's set up correctly, you should see a directory with a name that's
formatted like this: <user SID>_<username> .
Next steps
To troubleshoot FSLogix, see this troubleshooting guide.
Install Microsoft Office using FSLogix
application containers
You can install Microsoft Office quickly and efficiently by using an FSLogix application
container as a template for the other virtual machines (VMs) in your host pool.
Here's why using an FSLogix app container can help make installation faster:
Offloading your Office apps to an app container reduces the requirements for your
C drive size.
Snapshots or backups of your VM takes less resources.
Having an automated pipeline through updating a single image makes updating
your VMs easier.
You only need one image to install Office (and other apps) onto all the VMs in your
Azure Virtual Desktop deployment.
This article will show you how to set up an FSLogix application container with Office.
Requirements
You'll need the following things to set up the rule editor:
a VM running Windows without Office installed

a copy of Office
a copy of FSLogix installed on your deployment
a network share that all VMs in your host pool have read-only access to
Install Office
To install Office on your VHD or VHDX, enable the Remote Desktop Protocol in your VM,
then follow the instructions in Install Office on a VHD master image. When installing,
make sure you're using the correct licenses.
７ Note
Azure Virtual Desktop requires Share Computer Activation (SCA).

Install FSLogix
To install FSLogix and the Rule Editor, follow the instructions in Download and install
FSLogix.
Create and prepare a VHD to store Office

Next, you'll need to create and prepare a VHD image to use the Rule Editor on:
1. Open a command prompt as an administrator. and run the following command:
taskkill /F /IM MSEdge.exe /T
７ Note
Make sure to keep the blank spaces you see in this command.
2. Next, run the following command:
sc queryex type=service state=all | find /i "ClickToRunSvc"
If you find the service, restart the VM before continuing with step 3.
net stop ClickToRunSvc
3. After that, go to Program Files > FSLogix > Apps and run the following command
to create the target VHD:
frx moveto-vhd -filename <path to network share>\office.vhdx -src

"C:\Program Files\Microsoft Office" -size-mbs 5000
The VHD you create with this command should contain the C:\Program
Files\Microsoft Office folder.
７ Note
If you see any errors, uninstall Office and start over from step 1.
Configure the Rule Editor

Now that you've prepared your image, you'll need to configure the Rule Editor and
create a file to store your rules in.
1. Go to Program Files > FSLogix > Apps and run RuleEditor.exe.
2. Select File > New > Create to make a new rule set, then save that rule set to a
local folder.
3. Select Blank Rule Set, then select OK.
4. Select the + button. This will open the Add Rule window. This will change the
options in the Add Rule dialog.
5. From the drop-down menu, select App Container (VHD) Rule.
6. Enter C:\Program Files\Microsoft Office into the Folder field.
7. For the Disk file field, select <path>\office.vhd from the Create target VHD
section.
8. Select OK.
9. Go to the working folder at C:\Users\<username>\Documents\FSLogix Rule Sets

and look for the .frx and .fxa files. You need to move these files to the Rules folder
located at C:\Program Files\FSLogix\Apps\Rules in order for the rules to start
working.
10. Select Apply Rules to System for the rules to take effect.
７ Note
You'll need to apply the app rule files will need to all session hosts.
Next steps
If you want to learn more about FSLogix, check out our FSLogix documentation.
Add language packs to a Windows 10
multi-session image
Azure Virtual Desktop is a service that your users can deploy anytime, anywhere. That's
why it's important that your users be able to customize which language their Windows
10 Enterprise multi-session image displays.
There are two ways you can accommodate the language needs of your users:
Build dedicated host pools with a customized image for each language.
Have users with different language and localization requirements in the same host
pool, but customize their images to ensure they can select whichever language
they need.
The latter method is a lot more efficient and cost-effective. However, it's up to you to
decide which method best suits your needs. This article will show you how to customize
languages for your images.
Prerequisites
You need the following things to customize your Windows 10 Enterprise multi-session
images to add multiple languages:
An Azure virtual machine (VM) with Windows 10 Enterprise multi-session, version

1903 or later
The Language ISO, Feature on Demand (FOD) Disk 1, and Inbox Apps ISO of the
OS version the image uses. You can download them here:
Language ISO:
Windows 10, version 1903 or 1909 Language Pack ISO
Windows 10, version 2004 or later Language Pack ISO
FOD Disk 1 ISO:

Windows 10, version 1903 or 1909 FOD Disk 1 ISO
Windows 10, version 2004 or later FOD Disk 1 ISO
Inbox Apps ISO:

Windows 10, version 1903 or 1909 Inbox Apps ISO
Windows 10, version 2004 Inbox Apps ISO
Windows 10, version 20H2 Inbox Apps ISO
Windows 10, version 21H1 or 21H2 Inbox Apps ISO
If you use Local Experience Pack (LXP) ISO files to localize your images, you'll
also need to download the appropriate LXP ISO for the best language
experience
If you're using Windows 10, version 1903 or 1909:
Windows 10, version 1903 or 1909 LXP ISO
If you're using Windows 10, version 2004, 20H2, or 21H1, use the information
in Adding languages in Windows 10: Known issues to figure out which of the
following LXP ISOs is right for you:
Windows 10, version 2004 or later 01C 2021 LXP ISO
Windows 10, version 2004 or later 04B 2021 LXP ISO
An Azure Files Share or a file share on a Windows File Server Virtual Machine
７ Note
The file share (repository) must be accessible from the Azure VM you plan to use to
create the custom image.
Create a content repository for language

packages and features on demand
To create the content repository for language packages and FODs and a repository for
the Inbox Apps packages:
1. On an Azure VM, download the Windows 10 Multi-Language ISO, FODs, and Inbox
Apps for Windows 10 Enterprise multi-session, version 1903/1909, and 2004
images from the links in Prerequisites.
2. Open and mount the ISO files on the VM.
3. Go to the language pack ISO and copy the content from the LocalExperiencePacks
and x64\langpacks folders, then paste the content into the file share.
4. Go to the FOD ISO file, copy all of its content, then paste it into the file share.
5. Go to the amd64fre folder on the Inbox Apps ISO and copy the content in the
repository for the inbox apps that you've prepared.
７ Note
If you're working with limited storage, only copy the files for the languages
you know your users need. You can tell the files apart by looking at the
language codes in their file names. For example, the French file has the code
"fr-FR" in its name. For a complete list of language codes for all available
languages, see Available language packs for Windows.
） Important
Some languages require additional fonts included in satellite packages that

follow different naming conventions. For example, Japanese font file names
include “Jpan."
6. Set the permissions on the language content repository share so that you have
read access from the VM you'll use to build the custom image.
Create a custom Windows 10 Enterprise multi-

session image manually
To create a custom Windows 10 Enterprise multi-session image manually:
1. Deploy an Azure VM, then go to the Azure Gallery and select the current version of
Windows 10 Enterprise multi-session you're using.
2. After you've deployed the VM, connect to it using RDP as a local admin.
3. Make sure your VM has all the latest Windows Updates. Download the updates
and restart the VM, if necessary.
） Important
After you install a language pack, you have to reinstall the latest cumulative
update that is installed on your image. If you do not reinstall the latest
cumulative update, you may encounter errors. If the latest cumulative update
is already installed, Windows Update does not offer it again; you have to
manually reinstall it. For more information, see Languages overview.
4. Connect to the language package, FOD, and Inbox Apps file share repository and
mount it to a letter drive (for example, drive E).
Create a custom Windows 10 Enterprise multi-

session image automatically
If you'd rather install languages through an automated process, you can set up a script
in PowerShell. You can use the following script sample to install the Spanish (Spain),
French (France), and Chinese (PRC) language packs and satellite packages for Windows
10 Enterprise multi-session, version 2004. The script integrates the language interface
pack and all necessary satellite packages into the image. However, you can also modify
this script to install other languages. Just make sure to run the script from an elevated
PowerShell session, or else it won't work.
PowerShell
########################################################
## Add Languages to running Windows Image for Capture ##
########################################################
##Disable Language Pack Cleanup##

Disable-ScheduledTask -TaskPath "\Microsoft\Windows\AppxDeploymentClient\" -
TaskName "Pre-staged app cleanup"
##Set Language Pack Content Stores##
[string]$LIPContent = "E:"
##Spanish##
Add-AppProvisionedPackage -Online -PackagePath $LIPContent\es-

es\LanguageExperiencePack.es-es.Neutral.appx -LicensePath $LIPContent\es-
es\License.xml
Add-WindowsPackage -Online -PackagePath $LIPContent\Microsoft-Windows-

Client-Language-Pack_x64_es-es.cab

LanguageFeatures-Basic-es-es-Package~31bf3856ad364e35~amd64~~.cab

LanguageFeatures-Handwriting-es-es-Package~31bf3856ad364e35~amd64~~.cab

LanguageFeatures-OCR-es-es-Package~31bf3856ad364e35~amd64~~.cab

LanguageFeatures-Speech-es-es-Package~31bf3856ad364e35~amd64~~.cab

LanguageFeatures-TextToSpeech-es-es-Package~31bf3856ad364e35~amd64~~.cab

NetFx3-OnDemand-Package~31bf3856ad364e35~amd64~es-es~.cab

InternetExplorer-Optional-Package~31bf3856ad364e35~amd64~es-es~.cab

MSPaint-FoD-Package~31bf3856ad364e35~amd64~es-es~.cab

Notepad-FoD-Package~31bf3856ad364e35~amd64~es-es~.cab

PowerShell-ISE-FOD-Package~31bf3856ad364e35~amd64~es-es~.cab

Printing-WFS-FoD-Package~31bf3856ad364e35~amd64~es-es~.cab

StepsRecorder-Package~31bf3856ad364e35~amd64~es-es~.cab

WordPad-FoD-Package~31bf3856ad364e35~amd64~es-es~.cab
$LanguageList = Get-WinUserLanguageList
$LanguageList.Add("es-es")
Set-WinUserLanguageList $LanguageList -force
##French##
Add-AppProvisionedPackage -Online -PackagePath $LIPContent\fr-

fr\LanguageExperiencePack.fr-fr.Neutral.appx -LicensePath $LIPContent\fr-
fr\License.xml

Client-Language-Pack_x64_fr-fr.cab

LanguageFeatures-Basic-fr-fr-Package~31bf3856ad364e35~amd64~~.cab

LanguageFeatures-Handwriting-fr-fr-Package~31bf3856ad364e35~amd64~~.cab

LanguageFeatures-OCR-fr-fr-Package~31bf3856ad364e35~amd64~~.cab

LanguageFeatures-Speech-fr-fr-Package~31bf3856ad364e35~amd64~~.cab

LanguageFeatures-TextToSpeech-fr-fr-Package~31bf3856ad364e35~amd64~~.cab

NetFx3-OnDemand-Package~31bf3856ad364e35~amd64~fr-fr~.cab

InternetExplorer-Optional-Package~31bf3856ad364e35~amd64~fr-FR~.cab

MSPaint-FoD-Package~31bf3856ad364e35~amd64~fr-FR~.cab

Notepad-FoD-Package~31bf3856ad364e35~amd64~fr-FR~.cab

PowerShell-ISE-FOD-Package~31bf3856ad364e35~amd64~fr-FR~.cab

Printing-WFS-FoD-Package~31bf3856ad364e35~amd64~fr-FR~.cab

StepsRecorder-Package~31bf3856ad364e35~amd64~fr-FR~.cab

WordPad-FoD-Package~31bf3856ad364e35~amd64~fr-FR~.cab
$LanguageList.Add("fr-fr")
##Chinese(PRC)##
Add-AppProvisionedPackage -Online -PackagePath $LIPContent\zh-

cn\LanguageExperiencePack.zh-cn.Neutral.appx -LicensePath $LIPContent\zh-
cn\License.xml

Client-Language-Pack_x64_zh-cn.cab

LanguageFeatures-Basic-zh-cn-Package~31bf3856ad364e35~amd64~~.cab

LanguageFeatures-Fonts-Hans-Package~31bf3856ad364e35~amd64~~.cab

LanguageFeatures-Handwriting-zh-cn-Package~31bf3856ad364e35~amd64~~.cab

LanguageFeatures-OCR-zh-cn-Package~31bf3856ad364e35~amd64~~.cab

LanguageFeatures-Speech-zh-cn-Package~31bf3856ad364e35~amd64~~.cab

LanguageFeatures-TextToSpeech-zh-cn-Package~31bf3856ad364e35~amd64~~.cab

NetFx3-OnDemand-Package~31bf3856ad364e35~amd64~zh-cn~.cab

InternetExplorer-Optional-Package~31bf3856ad364e35~amd64~zh-cn~.cab

MSPaint-FoD-Package~31bf3856ad364e35~amd64~zh-cn~.cab

Notepad-FoD-Package~31bf3856ad364e35~amd64~zh-cn~.cab

PowerShell-ISE-FOD-Package~31bf3856ad364e35~amd64~zh-cn~.cab

Printing-WFS-FoD-Package~31bf3856ad364e35~amd64~zh-cn~.cab

StepsRecorder-Package~31bf3856ad364e35~amd64~zh-cn~.cab

WordPad-FoD-Package~31bf3856ad364e35~amd64~zh-cn~.cab
$LanguageList.Add("zh-cn")
The script might take a while depending on the number of languages you need to
install.
Once the script is finished running, check to make sure the language packs installed
correctly by going to Start > Settings > Time & Language > Language. If the language
files are there, you're all set.
After you've added additional languages to the Windows image, the inbox apps are also
required to be updated to support the added languages. This can be done by refreshing
the pre-installed apps with the content from the inbox apps ISO.
To perform this refresh
in an environment where the VM doesn't have internet access, you can use the following
PowerShell script template to automate the process and update only installed versions
of inbox apps.
PowerShell
#########################################
## Update Inbox Apps for Multi Language##
#########################################
##Set Inbox App Package Content Stores##
[string] $AppsContent = "F:\"
##Update installed Inbox Store Apps##
foreach ($App in (Get-AppxProvisionedPackage -Online)) {

$AppPath = $AppsContent + $App.DisplayName + '_' + $App.PublisherId
Write-Host "Handling $AppPath"
$licFile = Get-Item $AppPath*.xml
if ($licFile.Count) {
$lic = $true
$licFilePath = $licFile.FullName
} else {
$lic = $false
$appxFile = Get-Item $AppPath*.appx*
if ($appxFile.Count) {
$appxFilePath = $appxFile.FullName
if ($lic) {
Add-AppxProvisionedPackage -Online -PackagePath $appxFilePath -

LicensePath $licFilePath
} else {
Add-AppxProvisionedPackage -Online -PackagePath $appxFilePath -

skiplicense
） Important
The inbox apps included in the ISO aren't the latest versions of the pre-installed
Windows apps. To get the latest version of all apps, you need to update the apps
using the Windows Store App and perform an manual search for updates after
you've installed the additional languages.
When you're done, make sure to disconnect the share.

Finish customizing your image
After you've installed the language packs, you can install any other software you want to
add to your customized image.
Once you're finished customizing your image, you'll need to run the system preparation
tool (sysprep).
To run sysprep:
1. Open an elevated command prompt and run the following command to generalize
the image:
C:\Windows\System32\Sysprep\sysprep.exe /oobe /generalize /shutdown
2. Stop the VM, then capture it in a managed image by following the instructions in
Create a managed image of a generalized VM in Azure.
3. You can now use the customized image to deploy an Azure Virtual Desktop host
pool. To learn how to deploy a host pool, see Tutorial: Create a host pool with the
Azure portal.
Enable languages in Windows settings app

Finally, after you deploy the host pool, you'll need to add the language to each user's
language list so they can select their preferred language in the Settings menu.
To ensure your users can select the languages you installed, sign in as the user, then run
the following PowerShell cmdlet to add the installed language packs to the Languages
menu. You can also set up this script as an automated task or logon script that activates
when the user signs in to their session.
PowerShell
$LanguageList.Add("es-es")
$LanguageList.Add("fr-fr")
$LanguageList.Add("zh-cn")
After a user changes their language settings, they'll need to sign out of their Azure
Virtual Desktop session and sign in again for the changes to take effect.
Next steps
If you're curious about known issues for language packs, see Adding language packs in
Windows 10, version 1803 and later versions: Known issues.
If you have any other questions about Windows 10 Enterprise multi-session, check out
our FAQ.
Add languages to a Windows 11
Enterprise image
It's important to make sure users within your organization from all over the world can
use your Azure Virtual Desktop deployment. That's why you can customize the Windows
11 Enterprise image you use for your virtual machines (VMs) to have different language
packs. Starting with Windows 11, non-administrator user accounts can now add both
the display language and its corresponding language features. This feature means you
won't need to pre-install language packs for users in a personal host pool. For pooled
host pools, we still recommend you add the languages you plan to add to a custom
image. You can use the instructions in this article for both single-session and multi-
session versions of Windows 11 Enterprise.
When your organization includes users with multiple different languages, you have two
options:
Create one dedicated host pool with a customized image per language.
Have multiple users with different languages in the same host pool.
The second option is more efficient in terms of resources and cost, but requires a few
extra steps. Fortunately, this article will help walk you through how to build an image
that can accommodate users of all languages and localization needs.
Requirements
Before you can add languages to a Windows 11 Enterprise VM, you'll need to have the
following things ready:
An Azure VM with Windows 11 Enterprise installed

A Language and Optional Features ISO and Inbox Apps ISO of the OS version the
image uses. You can download them here:
Language and Optional Features ISO:
Windows 11, version 21H2 Language and Optional Features ISO
Windows 11, version 22H2 Language and Optional Features ISO
Inbox Apps ISO:
An Azure Files share or a file share on a Windows File Server VM
７ Note
The file share repository must be accessible from the Azure VM that you're going
to use to create the custom image.
Create a content repository for language

packages and features on demand
To create the content repository you'll use to add languages and features to your VM:
1. Open the VM you want to add languages to in Azure.
2. Open and mount the ISO file you downloaded in the Requirements section above
on the VM.
3. Create a folder on the file share.
4. Copy all content from the LanguagesAndOptionalFeatures folder in the ISO to the
folder you created.
７ Note
If you're working with limited storage, you can use the mounted "Languages
and Optional Features" ISO as a repository. To learn how to create a
repository, see Build a custom FOD and language pack repository.
） Important
Some languages require additional fonts included in satellite packages that

follow different naming conventions. For example, Japanese font file names
include “Jpan."
5. Set the permissions on the language content repository share so that you have
read access from the VM you'll use to build the custom image.
Create a custom Windows 11 Enterprise image

manually
You can create a custom image by following these steps:
1. Deploy an Azure VM, then go to the Azure Gallery and select the current version of
Windows 11 Enterprise you're using.
2. After you've deployed the VM, connect to it using RDP as a local admin.
3. Connect to the file share repository you created in Create a content repository for
language packages and features on demand and mount it to a letter drive (for
example, drive E).
4. Run the following PowerShell script from an elevated PowerShell session to install
language packs and satellite packages on Windows 11 Enterprise:
PowerShell
########################################################
## Add Languages to running Windows Image for Capture##
########################################################
##Disable Language Pack Cleanup##

Disable-ScheduledTask -TaskPath
"\Microsoft\Windows\AppxDeploymentClient\" -TaskName "Pre-staged app
cleanup"
Disable-ScheduledTask -TaskPath "\Microsoft\Windows\MUI\" -TaskName

"LPRemove"
Disable-ScheduledTask -TaskPath
"\Microsoft\Windows\LanguageComponentsInstaller" -TaskName
"Uninstallation"
reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Control

Panel\International" /v "BlockCleanupOfUnusedPreinstalledLangPacks" /t
REG_DWORD /d 1 /f
##Set Language Pack Content Stores##
$LIPContent = "E:"
##Set Path of CSV File##
$CSVFile = "Windows-10-1809-FOD-to-LP-Mapping-Table.csv"
$filePath = (Get-Location).Path + "\$CSVFile"
##Import Necesarry CSV File##
$FODList = Import-Csv -Path $filePath -Delimiter ";"
##Set Language (Target)##
$targetLanguage = "es-es"
$sourceLanguage = (($FODList | Where-Object {$_.'Target Lang' -eq

$targetLanguage}) | Where-Object {$_.'Source Lang' -ne $targetLanguage}
| Select-Object -Property 'Source Lang' -Unique).'Source Lang'
if(!($sourceLanguage)){
$sourceLanguage = $targetLanguage
$langGroup = (($FODList | Where-Object {$_.'Target Lang' -eq

$targetLanguage}) | Where-Object {$_.'Lang Group:' -ne ""} | Select-
Object -Property 'Lang Group:' -Unique).'Lang Group:'
##List of additional features to be installed##
$additionalFODList = @(
"$LIPContent\Microsoft-Windows-NetFx3-OnDemand-
Package~31bf3856ad364e35~amd64~~.cab",
"$LIPContent\Microsoft-Windows-MSPaint-FoD-
Package~31bf3856ad364e35~amd64~$sourceLanguage~.cab",
"$LIPContent\Microsoft-Windows-SnippingTool-FoD-
Package~31bf3856ad364e35~amd64~$sourceLanguage~.cab",
"$LIPContent\Microsoft-Windows-Lip-
Language_x64_$sourceLanguage.cab" ##only if applicable##
$additionalCapabilityList = @(
"Language.Basic~~~$sourceLanguage~0.0.1.0",
"Language.Handwriting~~~$sourceLanguage~0.0.1.0",
"Language.OCR~~~$sourceLanguage~0.0.1.0",
"Language.Speech~~~$sourceLanguage~0.0.1.0",
"Language.TextToSpeech~~~$sourceLanguage~0.0.1.0"
##Install all FODs or fonts from the CSV file###
Dism /Online /Add-Package /PackagePath:$LIPContent\Microsoft-Windows-

Client-Language-Pack_x64_$sourceLanguage.cab
Dism /Online /Add-Package /PackagePath:$LIPContent\Microsoft-Windows-

Lip-Language-Pack_x64_$sourceLanguage.cab
foreach($capability in $additionalCapabilityList){
Dism /Online /Add-Capability /CapabilityName:$capability

/Source:$LIPContent
foreach($feature in $additionalFODList){
Dism /Online /Add-Package /PackagePath:$feature
if($langGroup){
Dism /Online /Add-Capability

/CapabilityName:Language.Fonts.$langGroup~~~und-$langGroup~0.0.1.0
##Add installed language to language list##
$LanguageList.Add("$targetlanguage")
７ Note
This example script uses the Spanish (es-es) language code. To automatically
install the appropriate files for a different language change the
$targetLanguage parameter to the correct language code. For a list of
language codes, see Available language packs for Windows.
The script might take a while to finish depending on the number of languages you
need to install. You can also install additional languages after initial setup by
running the script again with a different $targetLanguage parameter.
5. To automatically select the appropriate installation files, download and save the
Available Windows 10 1809 Languages and Features on Demand table as a CSV
file, then save it in the same folder as your PowerShell script.
6. Once the script is finished running, check to make sure the language packs
installed correctly by going to Start > Settings > Time & Language > Language. If
the language files are there, you're all set.
7. Finally, if the VM is connected to the Internet while installing languages, you'll

need to run a cleanup process to remove any unnecessary language experience
packs. To clean up the files, run these commands:
PowerShell
##Cleanup to prepare sysprep##
Remove-AppxPackage -Package Microsoft.LanguageExperiencePackes-

ES_22000.8.13.0_neutral__8wekyb3d8bbwe
Remove-AppxPackage -Package
Microsoft.OneDriveSync_22000.8.13.0_neutral__8wekyb3d8bbwe
To clean up different language packs, replace "es-ES" with a different language

code.
8. Once you're done with cleanup, disconnect the share.
Finish customizing your image

After you've installed the language packs, you can install any other software you want to
add to your customized image.
Once you're finished customizing your image, you'll need to run the system preparation
tool (sysprep).
To run sysprep:
1. Open an elevated command prompt and run the following command to generalize
the image:
C:\Windows\System32\Sysprep\sysprep.exe /oobe /generalize /shutdown
2. If you run into any issues, check the SetupErr.log file in your C drive at Windows >
System32 > Sysprep > Panther. After that, follow the instructions in Sysprep fails
with Microsoft Store apps to troubleshoot your setup.
3. If setup is successful, stop the VM, then capture it in a managed image by
following the instructions in Create a managed image of a generalized VM in
Azure.
4. You can now use the customized image to deploy an Azure Virtual Desktop host
pool. To learn how to deploy a host pool, see Tutorial: Create a host pool with the
Azure portal.
７ Note
When a user changes their display language, they'll need to sign out of their Azure
Virtual Desktop session, then sign back in. They must sign out from the Start menu.
Next steps
Learn how to install language packages for Windows 10 multi-session VMs at Add
language packs to a Windows 10 multi-session image.
For a list of known issues, see Adding languages in Windows 10: Known issues.
 Documentation
Language packs known issue

Describes how to resolve a known issue that occurs when you install language packs in Windows 10,
version 1803 and later
Languages overview
Languages overview

Available Language Packs for Windows

Available Language Packs for Windows
Sysprep fails with Microsoft Store apps - Windows Client

Describes an issue that occurs when you remove a provisioned Windows Store app or update a
Windows Store app by using the Windows Store and then running sysprep on the machine.
DISM Languages and International Servicing Command-Line Options

DISM Languages and International Servicing Command-Line Options
Show 3 more
Migrate automatically from Azure
Virtual Desktop (classic)
The migration module tool lets you migrate your organization from Azure Virtual
Desktop (classic) to Azure Virtual Desktop automatically. This article will show you how
to use the tool.
Requirements
Before you use the migration module, make sure you have the following things ready:
An Azure subscription where you'll create new Azure service objects.
You must be assigned the Contributor role to create Azure objects on your
subscription, and the User Access Administrator role to assign users to application
groups.
At least Remote Desktop Services (RDS) Contributor permissions on an RDS tenant

or the specific host pools you're migrating.
The latest version of the Microsoft.RdInfra.RDPowershell PowerShell module.
The latest version of the Az.DesktopVirtualization PowerShell module.
The latest version of the Az.Resources PowerShell module.
Install the migration module on your computer.
PowerShell or PowerShell ISE to run the scripts you'll see in this article. The
Microsoft.RdInfra.RDPowershell module doesn't work in PowerShell Core.
） Important
Migration only creates service objects in the US geography. If you try to migrate
your service objects to another geography, it won't work. Also, if you have more
than 500 app groups in your Azure Virtual Desktop (classic) deployment, you won't
be able to migrate. You'll only be able to migrate if you rebuild your environment
to reduce the number of app groups within your Azure Active Directory (Azure AD)
tenant.
Prepare your PowerShell environment
First, you'll need to prepare your PowerShell environment for the migration process.
To prepare your PowerShell environment:
1. Before you start, make sure you have the latest version of the Az.Desktop
Virtualization and Az.Resources modules by running the following cmdlets:
PowerShell
Get-Module Az.Resources
Get-Module Az.DesktopVirtualization
https://www.powershellgallery.com/packages/Az.DesktopVirtualization/
https://www.powershellgallery.com/packages/Az.Resources/
If you don't, then you'll have to install and import the modules by running these
cmdlets:
PowerShell
Install-module Az.Resources
Import-module Az.Resources
Install-module Az.DesktopVirtualization
Import-module Az.DesktopVirtualization
2. Next, uninstall the current RDInfra PowerShell module by running this cmdlet:
PowerShell
Uninstall-Module -Name Microsoft.RDInfra.RDPowershell -AllVersions
3. After that, install the RDPowershell module with this cmdlet:
PowerShell
Install-Module -Name Microsoft.RDInfra.RDPowershell -RequiredVersion

1.0.3414.0 -force
Import-module Microsoft.RDInfra.RDPowershell
4. Once you're done installing everything, run this cmdlet to make sure you have the
right versions of the modules:
PowerShell
Get-Module Microsoft.RDInfra.RDPowershell
5. Now, let's install and import the migration module by running these cmdlets:
PowerShell
Install-Module -Name PackageManagement -Repository PSGallery -Force
Install-Module -Name PowerShellGet -Repository PSGallery -Force
# Then restart shell
Install-Module -Name Microsoft.RdInfra.RDPowershell.Migration -

AllowClobber
Import-Module <Full path to the location of the migration

module>\Microsoft.RdInfra.RDPowershell.Migration.psd1
6. Once you're done, sign into Azure Virtual Desktop (classic) in your PowerShell
window:
PowerShell
Add-RdsAccount -DeploymentUrl https://rdbroker.wvd.microsoft.com
7. Sign in to Azure Resource Manager:
PowerShell
Login-AzAccount
8. If you have multiple subscriptions, select the one you want to migrate your
resources to with this cmdlet:
PowerShell
Select-AzSubscription -Subscriptionid <subID>
9. Register the Resource Provider in Azure portal for the selected subscription.
10. Finally you'll need to register the provider. There are two ways you can do this:
If you want to use PowerShell, then run this cmdlet:
PowerShell
Register-AzResourceProvider -ProviderNamespace
Microsoft.DesktopVirtualization
If you'd rather use the Azure portal, open and sign in to the Azure portal,
then go to Subscriptions and select the name of the subscription you want to
use. After that, go to Resource Provider > Microsoft.DesktopVirtualization
and select Re-register. You won't see anything change in the UI just yet, but
your PowerShell environment should now be ready to run the module.
Migrate Azure Virtual Desktop (classic)

resources to Azure Resource Manager
Now that your PowerShell environment is ready, you can begin the migration process.
To migrate your Azure virtual Desktop (classic) resources to Azure Resource Manager:
1. Before you migrate, if you want to understand how the existing Classic resources
will get mapped to new Azure Resource Manager resources, run this cmdlet:
PowerShell
Get-RdsHostPoolMigrationMapping
With Get-RdsHostPoolMigrationMapping, you can create a CSV file that maps

where your resources will go. For example, if your tenant's name is "Contoso," and
you want to store your mapping file in the "contosouser" file, you'd run a cmdlet
that looks like this:
PowerShell
Get-RdsHostPoolMigrationMapping -Tenant Contoso -HostPool Office -

Location EastUS -OutputFile 'C:\\Users\contosouser\OneDrive -
Microsoft\Desktop\mapping.csv'
2. Next, run the Start-RdsHostPoolMigration cmdlet to choose whether to migrate a

single host pool or all host pools within a tenant.
For example:
PowerShell
Start-RdsHostPoolMigration -Tenant Contoso -Location WestUS
If you want to migrate your resources a specific host pool, then include the host
pool name. For example, if you want to move the host pool named "Office," run a
command like this:
PowerShell
Start-RdsHostPoolMigration -Tenant Contoso -HostPool Office -

CopyUserAssignments $false -Location EastUS
If you don't give a workspace name, the module will automatically create one for
you based on the tenant name. However, if you'd prefer to use a specific
workspace, you can enter its resource ID like this:
PowerShell
Start-RdsHostPoolMigration -Tenant Contoso -HostPool Office -

CopyUserAssignments -Location EastUS -Workspace <Resource ID of
workspacename>
If you'd like to use a specific workspace but don't know its resource ID, run this
cmdlet:
PowerShell
Get-AzWvdWorkspace -WorkspaceName <workspace> -ResourceGroupName

<resource group> |fl
You'll also need to specify a user assignment mode for the existing user
assignments:
Use Copy to copy all user assignments from your old app groups to Azure
Resource Manager application groups. Users will be able to see feeds for
both versions of their clients.
Use None if you don't want to change the user assignments. Later, you can
assign users or user groups to app groups with the Azure portal, PowerShell,
or API. Users will only be able to see feeds using the Azure Virtual Desktop
(classic) clients.
You can only copy 2,000 user assignments per subscription, so your limit will
depend on how many assignments are already in your subscription. The module
calculates the limit based on how many assignments you already have. If you don't
have enough assignments to copy, you'll get an error message that says
"Insufficient role assignment quota to copy user assignments. Rerun command
without the -CopyUserAssignments switch to migrate."
3. After you run the commands, it will take up to 15 minutes for the module to create
the service objects. If you copied or moved any user assignments, that will add to
the time it takes for the module to finish setting everything up.
After the Start-RdsHostPoolMigration cmdlet is done, you should see the

following things:
Azure service objects for the tenant or host pool you specified.
Two new resource groups:
A resource group called "Tenantname," which contains your workspace.
A resource group called "Tenantname_originalHostPoolName," which

contains the host pool and desktop app groups.
Any users you published to the newly created app groups.
Virtual machines will be available in both existing and new host pools to
avoid user downtime during the migration process. This lets users connect to
the same user session.
Since these new Azure service objects are Azure Resource Manager objects, the
module can't set Role-based Access Control (RBAC) permissions or diagnostic
settings on them. Therefore, you'll need to update the RBAC permissions and
settings for these objects manually.
Once the module validates the initial user connections, you can also publish the
app group to more users or user groups, if you'd like.
７ Note
After migration, if you move app groups to a different resource group after
assigning permissions to users, it will remove all RBAC roles. You'll need to
reassign users RBAC permissions all over again.
4. If you want to delete all Azure Virtual Desktop (classic) service objects, run
Complete-RdsHostPoolMigration to finish the migration process. This cmdlet will
delete all Azure Virtual Desktop (classic) objects, leaving only the new Azure
objects. Users will only be able to see the feed for the newly created app groups
on their clients. Once this command is done, you can safely delete the Azure
Virtual Desktop (classic) tenant to finish the process.
For example:
PowerShell
Complete-RdsHostPoolMigration -Tenant Contoso -Location EastUS
If you want to complete a specific host pool, you can include the host pool name
in the cmdlet. For example, if you want to complete a host pool named "Office,"
you'd use a command like this:
PowerShell
Complete-RdsHostPoolMigration -Tenant Contoso -HostPool Office -

Location EastUS
This will delete all service objects created by Azure Virtual Desktop (classic). You
will be left with just the new Azure objects and users will only be able to see the
feed for the newly created app groups on their clients. Once you are done
finalizing your migration, you need to explicitly delete the tenant in Azure Virtual
Desktop (classic).
5. If you've changed your mind about migrating and want to revert the process, run
the Revert-RdsHostPoolMigration cmdlet.
For example:
PowerShell
Revert-RdsHostPoolMigration -Tenant Contoso -Location EastUS
If you'd like to revert a specific host pool, you can include the host pool name in
the command. For example, if you want to revert a host pool named "Office," then
you'd enter something like this:
PowerShell
Revert-RdsHostPoolMigration -Tenant Contoso -HostPool Office -Location

EastUS
This cmdlet will delete all newly created Azure service objects. Your users will only
see the feed for Azure Virtual Desktop (classic) objects in their clients.
However, the cmdlet won't delete the workspace the module created or its
associated resource group. You'll need to manually delete those items to get rid of
them.
6. If you don't want to delete your Azure Virtual Desktop (classic) service objects yet
but do want to test migration, you can run Set-RdsHostPoolHidden.
For example:
PowerShell
Set-RdsHostPoolHidden -Tenant Contoso -Hostpool Office -Hidden $true -

Location WestUS
Setting the status to "true" will hide the Azure Virtual Desktop (classic) resources.
Setting it to "false" will reveal the resources to your users.
The -Hostpool parameter is optional. You can use this parameter if there's a specific
Azure Virtual Desktop (classic) host pool you want to hide.
This cmdlet will hide the Azure Virtual Desktop (classic) user feed and service
objects instead of deleting them. However, this is usually only used for testing and
doesn't count as a completed migration. To complete your migration, you'll need
to run the Complete-RdsHostPoolMigration command. Otherwise, revert your
deployment by running Revert-RdsHostPoolMigration.
Troubleshoot automatic migration

This section explains how to solve commonly encountered issues in the migration
module.
I can't access the tenant

First, try these two things:
Make sure your admin account has the required permissions to access the tenant.
Try running Get-RdsTenant on the tenant.
If those two things work, try running the Set-RdsMigrationContext cmdlet to set the
RDS Context and ADAL Context for your migration:
1. Create the RDS Context by running the Add-RdsAccount cmdlet.
2. Find the RDS Context in the global variable $rdMgmtContext.
3. Find the ADAL Context in the global variable $AdalContext.
4. Run Set-RdsMigrationContext with the variables you found in this format:

PowerShell
Set-RdsMigrationContext -RdsContext <rdscontext> -AdalContext

<adalcontext>
Next steps
If you'd like to learn how to migrate your deployment manually instead, see Migrate
manually from Azure Virtual Desktop (classic).
Once you've migrated, get to know how Azure Virtual Desktop works by checking out
our tutorials. Learn about advanced management capabilities at Expand an existing host
pool and Customize RDP properties.
To learn more about service objects, check out Azure Virtual Desktop environment.
Migrate manually from Azure Virtual
Desktop (classic)
Azure Virtual Desktop (classic) creates its service environment with PowerShell cmdlets,
REST APIs, and service objects. An object in an Azure Virtual Desktop service
environment is a thing that Azure Virtual Desktop creates. Service objects include
tenants, host pools, application groups, and session hosts.
However, Azure Virtual Desktop (classic) isn't integrated with Azure. Without Azure
integration, any objects you create aren't automatically managed by the Azure portal
because they're not connected to your Azure subscription.
The recent major update of Azure Virtual Desktop marks a shift in the service towards
full Azure integration. Objects you create in Azure Virtual Desktop are automatically
managed by the Azure portal.
In this article, we'll explain why you should consider migrating to the latest version of
Azure Virtual Desktop. After that, we'll tell you how to manually migrate from Azure
Virtual Desktop (classic) to the latest update of Azure Virtual Desktop.
Why migrate?
Major updates can be inconvenient, especially ones you have to do manually. However,
there are some reasons why you can't automatically migrate:
Existing service objects made with the classic release don't have any representation
in Azure. Their scope doesn't extend beyond the Azure Virtual Desktop service.
With the latest update, the service's application ID was changed to remove consent
for apps the way it did for Azure Virtual Desktop (classic). You won't be able to
create new Azure objects with Azure Virtual Desktop unless they're authenticated
with the new application ID.
Despite the hassle, migrating away from the classic version is still important. Here's what
you can do after you migrate:
Manage Azure Virtual Desktop through the Azure portal.

Assign Azure Active Directory (Azure AD) user groups to application groups.
Use the improved Log Analytics feature to troubleshoot your deployment.
Use Azure-native role-based access control (Azure RBAC) to manage administrative
access.
When should I migrate?
When asking yourself if you should migrate, you should also take into account your
deployment's current and future situation.
There are a few scenarios in particular where we recommend you manually migrate:
You have a test host pool setup with a small number of users.
You have a production host pool setup with a small number of users, but plan to
eventually ramp up to hundreds of users.
You have a simple setup that can be easily replicated. For example, if your VMs use
a gallery image.
） Important
If you're using an advanced configuration that took a long time to stabilize or has a
lot of users, we don't recommend manually migrating.
Prepare for migration

Before you get started, you'll need to make sure your environment is ready to migrate.
Here's what you need to start the migration process:
An Azure subscription where you’ll create new Azure service objects.
Make sure you're assigned to the following roles:

Contributor
User Access Administrator
The Contributor role lets you create Azure objects on your subscription, and the
User Access Administrator role lets you assign users to application groups.
How to migrate manually

Now that you've prepared for the migration process, it's time to actually migrate.
To migrate manually from Azure Virtual Desktop (classic) to Azure Virtual Desktop:
1. Follow the instructions in Create a host pool with the Azure portal to create all
high-level objects with the Azure portal.
2. If you want to bring over the virtual machines you're already using, follow the
instructions in Register the virtual machines to the Azure Virtual Desktop host pool
to manually register them to the new host pool you created in step 1.
3. Create new RemoteApp app groups.
4. Publish users or user groups to the new desktop and RemoteApp app groups.
5. Update your Conditional Access policy to allow the new objects by following the
instructions in Set up multi-factor authentication.
To prevent downtime, you should first register your existing session hosts to the Azure
Resource Manager-integrated host pools in small groups at a time. After that, slowly
bring your users over to the new Azure Resource Manager-integrated app groups.
Next steps
If you'd like to learn how to migrate your deployment automatically instead, go to
Migrate automatically from Azure Virtual Desktop (classic).
Once you've migrated, get to know how Azure Virtual Desktop works by checking out
our tutorials. Learn about advanced management capabilities at Expand an existing host
pool and Customize RDP properties.
To learn more about service objects, check out Azure Virtual Desktop environment.
Set up Azure Virtual Desktop for Azure
Stack HCI (preview)
This article describes how to set up Azure Virtual Desktop for Azure Stack HCI (preview)
manually or through an automated process.
With Azure Virtual Desktop for Azure Stack HCI (preview), you can use Azure Virtual
Desktop session hosts in your on-premises Azure Stack HCI infrastructure. For more
information, see Azure Virtual Desktop for Azure Stack HCI (preview).
） Important
This feature is currently in PREVIEW. See the Supplemental Terms of Use for
Microsoft Azure Previews for legal terms that apply to Azure features that are in
beta, preview, or otherwise not yet released into general availability.
Configure Azure Virtual Desktop for Azure

Stack HCI
You can set up Azure Virtual Desktop for Azure Stack HCI either manually or
automatically using the Azure Resource Manager template (ARM template) in the Azure
portal. Both these methods deploy a pooled host pool.
Manual deployment
Prerequisites
To use Azure Virtual Desktop for Azure Stack HCI, you need the following things:
An Azure Stack HCI cluster registered with Azure.
An Azure subscription for Azure Virtual Desktop session host pool creation
with all required admin permissions.
An on-premises Active Directory (AD) synced with Azure Active Directory.
A stable connection to Azure from your on-premises network.

Access from your on-premises network to all the required URLs listed in Azure
Virtual Desktop's required URL list for virtual machines.
Configure Azure Virtual Desktop for Azure

Stack HCI manually
To manually configure Azure Virtual Desktop for Azure Stack HCI, follow these high-
level steps:
Step 1: Create a new virtual machines on Azure Stack HCI

Step 2: Install Connected Machine agent on the virtual machine
Step 3: Deploy a custom template
Step 4: Manage application groups
Step 1: Create a new virtual machine on Azure Stack

HCI
Create a new virtual machine with a supported operating system on your Azure
Stack HCI infrastructure. For step-by-step instructions about how to create a VM,
see Create a new VM. For information about supported operating system and
licenses, see Operating systems and licenses.
７ Note
Install the Remote Desktop Session Host (RDSH) role if the VM is running a
Windows Server operating system.
Step 2: Install Connected Machine agent on the virtual

machine
To manage the new VM from Azure via Azure Arc, install the Connected Machine
agent on the VM. For step-by-step instructions on how to install the Windows
agent on the VM, see Connect hybrid machines with Azure Arc-enabled servers.
Step 3: Deploy a custom template

After you satisfy the prerequisites and complete Step 1 and Step 2, perform these
steps to deploy Azure Virtual Desktop on Azure Stack HCI from a custom template:
1. Select the button.
 Tip
Hold down CTRL while selecting the button to open the Azure portal in a
new browser tab.
The Azure Resource Manager template opens in the Azure portal and sets up
Azure Virtual Desktop on Azure Stack HCI by:
Creating host pool, workspace, and application group

Adding the VMs you created in Step 1 as session hosts to the host pool
Joining the VMs to the domain and downloading and installing the
Azure Virtual Desktop agents and registering them to the host pool
To find all the relevant custom templates, see Quick Deploy templates on
GitHub.
2. Select or enter the following values under Project details:
a. From Subscription, select the correct subscription.
b. In Region, select the Azure region for the host pool that’s right for you and
your customers.
c. In Host Pool Name, enter a unique name for your host pool.
d. In Location, enter a region where you create the Host Pool, Workspace, and
VMs. The metadata for these objects is stored in the geography associated
with the region, such as East US. This location must match the Azure region
you selected previously, in step b.
e. In Workspace Name, enter a unique name.


f. In Domain, enter the domain name to join your session hosts to the
required domain.
g. In O U Path, enter the OU Path value for domain join. For example:
OU=unit1,DC=contoso,DC=com .
h. In Domain Administrator Username and Domain Administrator Password,

enter the domain administrator credentials to join your session hosts to the
domain.
i. In Vm Resource Ids, enter full ARM resource IDs of the VMs to add to the
host pool as session hosts. You can add multiple VMs. For example:
“/subscriptions/<subscriptionID>/resourceGroups/Contoso-
rg/providers/Microsoft.HybridCompute/machines/Contoso-
VM1”,”/subscriptions/<subscriptionID>/resourceGroups/Contoso-
rg/providers/Microsoft.HybridCompute/machines/Contoso-VM2”
j. In Token Expiration Time, enter the host pool token expiration. If left blank,
the template automatically takes the current UTC time as the default value.
k. In Tags, enter values for tags in the following format:
{"CreatedBy": "name", "Test": "Test2”}

l. In Deployment Id, enter the Deployment ID. A new GUID is created by
default.
m. In Validation Environment, select the validation environment. The default is

false.
3. Select the Review+Create button.
4. After validation passes, select Create.
After the deployment is complete, you can see all the required objects
created.
Step 4: Manage application groups

You can add more application groups to a host pool and assign users to the
application group. For step-by-step instructions, see Tutorial: Manage app groups
with the Azure portal.
Activate Windows operating system

You must license and activate the Windows VMs before you use them on Azure
Stack HCI.
For activating your multi-session OS VMs (Windows 10, Windows 11, or later),
enable Azure Benefits on the VM once it is created. Make sure to enable Azure
Benefits on the host computer also. For more information, see Azure Benefits on
Azure Stack HCI.
７ Note
You must manually enable access for each VM that requires Azure Benefits.
For all other OS images (such as Windows Server or single-session OS), Azure
Benefits is not required. Continue to use the existing activation methods. For more
information, see Activate Windows Server VMs on Azure Stack HCI.
Optional configurations
Now that you've set up Azure Virtual Desktop for Azure Stack HCI, here are a few
extra things you can do depending on your deployment needs:
Create a profile container

To create a profile container using a file share on Azure Stack HCI, do the following:
1. Deploy a file share on a single or clustered Windows Server VM deployment.

The Windows Server VMs with file server role can also be co-located on the
same cluster where the session host VMs are deployed.
2. Connect to the VM with the credentials you provided when creating the VM.
3. Join the VM to an Active Directory domain.
4. Follow the instructions in Create a profile container for a host pool using a file
share to prepare your VM and configure your profile container.
Add session hosts

You can add new session hosts to an existing host pool that was created either
manually or using the custom template.
To get started, select the button.
The custom template opens in the Azure portal. This Azure Resource Manager
template sets up your VMs for Azure Virtual Desktop and adds them to your
existing host pool. To find all the relevant custom templates, see Quick Deploy
templates on GitHub.
Download supported OS images from Azure

Marketplace
You can run any OS images that both Azure Virtual Desktop and Azure Stack HCI
support on your deployment. To learn which operating systems Azure Virtual
Desktop supports, see Supported VM OS images.
You have two options to download an image:

Deploy a VM with your preferred OS image, then follow the instructions in
Download a Windows VHD from Azure.
Download a Windows Virtual Hard Disk (VHD) from Azure without deploying a
VM.
Downloading a Windows VHD without deploying a VM has several extra steps. To

download a VHD from Azure without deploying a VM, you'll need to complete the
instructions in the following sections in order.
Requirements to download a VHD without a VM

Before you begin, make sure you're connected to Azure and are running Azure
Cloud Shell in either a command prompt or in the bash environment. You can also
run CLI reference commands via the Azure CLI.
If you're using a local installation, run the az login command to sign into Azure.
After that, follow any other prompts you see to finish signing in. For more sign-in
options, see Sign in with the Azure CLI.
If this is your first time using Azure CLI, install any required extensions by following
the instructions in Use extensions with the Azure CLI.
Finally, run the az version command to make sure your client is up to date. If it's out
of date, run the az upgrade command to upgrade to the latest version.
Search Azure Marketplace for Azure Virtual Desktop

images
You can find the image you're looking for by using the Search function in Azure
Marketplace in the Azure portal. To find images specifically for Azure Virtual
Desktop, you can run one of the following example queries.
If you're looking for Windows 10 multi-session, you can run a search with this
criteria:
Azure CLI
az vm image list --all --publisher "microsoftwindowsdesktop" --offer

"windows-10" --sku "21h1-evd-g2"
This command should return the following URN:

Output
MicrosoftWindowsDesktop:Windows-10:21h1-evd-g2:latest
If you're looking for Windows Server 2019 Datacenter, you can run the following
criteria in your Azure CLI:
Azure CLI
az vm image list --all --publisher "microsoftwindowsserver" --offer

"WindowsServer" --sku "2019-Datacenter-gen2"
This command should return the following URN:
Output
MicrosoftWindowsServer:windowsserver-gen2preview:2019-datacenter-
gen2:latest
） Important
Make sure to only use generation 2 ("gen2") images. Azure Virtual Desktop for
Azure Stack HCI doesn't support creating a VM with a first-generation ("gen1")
image. Avoid SKUs with a "-g1" suffix.
Create a new Azure managed disk from the image

Next, you need to create an Azure managed disk from the image you downloaded
from the Azure Marketplace.
To create an Azure managed disk:
1. Run the following commands in an Azure command-line prompt to set the

parameters of your managed disk. Make sure to replace the items in brackets
with the values relevant to your scenario.
Console
$urn = <URN of the Marketplace image> #Example:

“MicrosoftWindowsServer:WindowsServer:2019-Datacenter:Latest”
$diskName = <disk name> #Name for new disk to be created
$diskRG = <resource group> #Resource group that contains the new

disk
2. Run these commands to create the disk and generate a Serial Attached SCSI
(SAS) access URL.
Azure CLI
az disk create -g $diskRG -n $diskName --image-reference $urn
$sas = az disk grant-access --duration-in-seconds 36000 --access-

level Read --name $diskName --resource-group $diskRG
$diskAccessSAS = ($sas | ConvertFrom-Json)[0].accessSas
Export a VHD from the managed disk to Azure Stack

HCI cluster
After that, you'll need to export the VHD you created from the managed disk to
your Azure Stack HCI cluster, which will let you create new VMs. You can use the
following method in a regular web browser or Storage Explorer.
To export the VHD:
1. Open a browser and go to the SAS URL of the managed disk you generated in
Create a new Azure managed disk from the image. You can download the
VHD image for the image you downloaded at the Azure Marketplace at this
URL.
2. Download the VHD image. The downloading process may take several
minutes, so be patient. Make sure the image has fully downloaded before
going to the next section.
７ Note
If you're running azcopy, you may need to skip the md5check by running this
command:
Azure CLI
azcopy copy “$sas" "destination_path_on_cluster" --check-md5

NoCheck
Clean up the managed disk

When you're done with your VHD, you'll need to free up space by deleting the
managed disk.
To delete the managed disk you created, run these commands:
Azure CLI
az disk revoke-access --name $diskName --resource-group $diskRG
az disk delete --name $diskName --resource-group $diskRG --yes
This command may take a few minutes to finish.
７ Note
Optionally, you can also convert the download VHD to a dynamic VHDx by
running this command:
PowerShell
Convert-VHD -Path " destination_path_on_cluster\file_name.vhd" -

DestinationPath " destination_path_on_cluster\file_name.vhdx" -
VHDType Dynamic
Next steps
For an overview and pricing information, see Azure Virtual Desktop for Azure Stack
HCI.
To find answers to frequently asked questions, see FAQ.

Use Azure CLI and Azure PowerShell
with Azure Virtual Desktop
There's an Azure CLI extension and an Azure PowerShell module for Azure Virtual
Desktop that you can use to create, update, delete, and interact with Azure Virtual
Desktop service objects as alternatives to using the Azure portal. They're part of Azure
CLI and Azure PowerShell, which cover a wide range of Azure services.
This article explains how you can use the Azure CLI extension and an Azure PowerShell
module, and provides some useful example commands.
Azure CLI extension and Azure PowerShell

module
Here are the names of the Azure CLI extension and Azure PowerShell module, and links
to our reference documentation:
Azure CLI: az desktopvirtualization
Azure PowerShell: Az.DesktopVirtualization
Both Azure CLI and Azure PowerShell are available to use in the Azure Cloud Shell
natively in the Azure portal with no installation, or you can install them locally on your
device for Windows, macOS, and Linux.
To learn how to install Azure CLI and Azure PowerShell across all supported platforms,
see the following links:
Azure CLI: How to install the Azure CLI
Azure PowerShell: Install the Azure Az PowerShell module
Example commands
Here are some example commands you can use to get information and values about
your Azure Virtual Desktop resources you might find useful. Select the relevant tab for
your scenario.
Azure CLI
） Important
In the following examples, you'll need to change the <placeholder> values for
your own.
Available Azure regions

When creating Azure Virtual Desktop service objects using any of the CLI
commands that contain create , you need to specify the Azure region you want to
create them in. To find the name of the Azure region to use with the --location
parameter, run the following command and use a value from the Location column:
Azure PowerShell
az account list-locations --query "sort_by([].{DisplayName:displayName,

Location:name}, &Location)" -o table
Retrieve the object ID of a host pool, workspace,

application group, or application
To retrieve the object ID of a host pool, run the following command:
Azure CLI
az desktopvirtualization hostpool show \
--name <Name> \
--resource-group <ResourceGroupName> \
--query objectId
--output tsv
To retrieve the object ID of a workspace, run the following command:
Azure CLI
az desktopvirtualization workspace show \
--name <Name> \
--query objectId
--output tsv
To retrieve the object ID of an application group, run the following command:

Azure CLI
az desktopvirtualization applicationgroup show \
--name <Name> \
--query objectId
--output tsv
 Tip
The Azure CLI extension for Azure Virtual Desktop doesn't have commands for
applications. Use Azure PowerShell instead.
Next steps
Now that you know how to use Azure CLI and Azure PowerShell with Azure Virtual
Desktop, here are some articles that use them:
Create an Azure Virtual Desktop host pool with PowerShell or the Azure CLI
Manage app groups using PowerShell or the Azure CLI
 Documentation
Manage app groups for Azure Virtual Desktop - Azure

How to manage Azure Virtual Desktop app groups with PowerShell or the Azure CLI.
Az.DesktopVirtualization Module
Azure Virtual Desktop PowerShell - Azure

How to troubleshoot issues with PowerShell when you set up a Azure Virtual Desktop environment.

Azure Virtual Desktop environment host pool creation - Azure

How to troubleshoot and resolve tenant and host pool issues during setup of a Azure Virtual


Show 4 more
 Training
Learning path
Maintain system administration tasks in Windows PowerShell - Training
This learning path covers cmdlets that are commonly used for system administration tasks related to
Active Directory, network configuration, server administration, and Windows 10 device
administration.
Certification
Move Azure Virtual Desktop resource
between regions
In this article, we'll tell you how to move Azure Virtual Desktop resources between Azure
regions.
７ Note
This process doesn't perform an actual resource move. Instead, you delete the old
resources and recreate them in the region you want to move the resources to. We
recommend you test this process before using it on production workloads to
understand how it will impact your deployment.
The information in this article applies to all Azure Virtual Desktop resources,
including host pools, application groups, scaling plans, and workspaces.
Important information
When you move Azure Virtual Desktop resources between regions, these are some
things you should keep in mind:
When exporting resources, you must move them as a set. All resources associated
with a specific host pool have to stay together. A host pool and its associated app
groups need to be in the same region.
Workspaces and their associated app groups also need to be in the same region.
Scaling plans and the host pools they are assigned to also need to be in the same
region.
All resources to be moved have to be in the same resource group. Template

exports require having resources in the same group, so if you want them to be in a
different location, you'll need to modify the exported template to change the
location of its resources.
Once you're done moving your resources to a new region, you must delete the
original resources. The resource ID of your resources won't change during the
moving process, so there will be a name conflict with your old resources if you
don't delete them.
Existing session hosts attached to a host pool that you move will stop working.
You'll need to recreate the session hosts in the new region.
Export a template
The first step to move your resources is to create a template that contains everything
you want to move to the new region.
To export a template:
1. In the Azure portal, go to Resource Groups, then select the resource group that
contains the resources you want to move.
2. Once you've selected the resource group, go to Overview > Resources and select
all the resources you want to move.
3. Select the ... button in the upper right-hand corner of the Resources tab. Once the
drop-down menu opens, select Export template.
4. Select Download to download a local copy of the generated template.
5. Right-click the zip file and select Extract All.
Modify the exported template

Next, you'll need to modify the template to include the region you're moving your
resources to.
To modify the template you exported:
1. Open the template.json file you extracted from the zip folder and a text editor of
your choice, such as Notepad.
2. In each resource inside the template file, find the "location" property and modify it
to the location you want to move them to. For example, if your deployment's
currently in the East US region but you want to move it to the West US region,
you'd change the "eastus" location to "westus." Learn more about which Azure
regions you can use at Azure geographies .
3. If you are moving a host pool, remove the "publicNetworkAccess" parameter, if

present.
Delete original resources

Once you have the template ready, you'll need to delete the original resources to
prevent name conflicts.
To delete the original resources:
1. Go back to the Resources tab mentioned in Export a template and select all the
resources you exported to the template.
2. Next, select the ... button again, then select Delete from the drop-down menu.
3. If you see a message asking you to confirm the deletion, select Confirm.
4. Wait a few minutes for the resources to finish deleting. Once you're done, they
should disappear from the resource list.
Deploy the modified template

Finally, you'll need to deploy your modified template in the new region.
To deploy the template:
1. In the Azure portal, search for and select Deploy a custom template.
2. In the custom deployment menu, select Build your own template in the editor.
3. Next, select Load file and upload your modified template file.
７ Note
Make sure to upload the template.json file, not the parameters.json file.
4. When you're done uploading the template, select Save.
5. In the next menu, select Review + create.
6. Under Instance details, make sure the Region shows the region you changed the
location to in Modify the exported template. If not, select the correct region from
the drop-down menu.
7. If everything looks correct, select Create.
8. Wait a few minutes for the template to deploy. Once it's finished, the resources
should appear in your resource list.
Next steps
Find out which Azure regions are currently available at Azure Geographies .
See our Azure Resource Manager templates for Azure Virtual Desktop for more
templates you can use in your deployments after you move your resources.
 Documentation
Create an application group, a workspace, and assign users - Azure Virtual Desktop
Learn how to create an application group and a workspace, and assign users in Azure Virtual Desktop
by using the Azure portal, Azure CLI, or Azure PowerShell.



to production.




Show 5 more
 Training
Module
Move Azure resources to another resource group - Training
Learn how to identify Azure resources you can move, and how to move them to a new resource
group.
Customize Remote Desktop Protocol
(RDP) properties for a host pool
） Important
You can customize a host pool's Remote Desktop Protocol (RDP) properties, such as
multi-monitor experience and audio redirection, to deliver an optimal experience for
your users based on their needs. If you'd like to change the default RDP file properties,
you can customize RDP properties in Azure Virtual Desktop by either using the Azure
portal or by using the -CustomRdpProperty parameter in the Update-AzWvdHostPool
cmdlet.
See Supported RDP properties with Azure Virtual Desktop for a full list of supported
properties and their default values.
Default RDP file properties

RDP files have the following properties by default:
RDP property For both Desktop and RemoteApp
Multi-monitor Enabled
mode
Redirections Drives, clipboard, printers, COM ports, smart cards, devices, usbdevicestore,
enabled and WebAuthn
Remote audio Play locally

mode
VideoPlayback Enabled
EnableCredssp Enabled
７ Note
Multi-monitor mode is only enabled for Desktop app groups and will be
ignored for RemoteApp app groups.
All default RDP file properties are exposed in the Azure Portal.
A null CustomRdpProperty field will apply all default RDP properties to your
host pool. An empty CustomRdpProperty field won't apply any default RDP
properties to your host pool.
Prerequisites
Before you begin, follow the instructions in Set up the Azure Virtual Desktop PowerShell
module to set up your PowerShell module and sign in to Azure.
Configure RDP properties in the Azure portal

To configure RDP properties in the Azure portal:

2. Enter Azure Virtual Desktop into the search bar.
3. Under Services, select Azure Virtual Desktop.
4. At the Azure Virtual Desktop page, select host pools in the menu on the left side
of the screen.
5. Select the name of the host pool you want to update.
6. Select RDP Properties in the menu on the left side of the screen.
7. Set the property you want.
Alternatively, you can open the Advanced tab and add your RDP properties
in a semicolon-separated format like the PowerShell examples in the
following sections.
8. When you're done, select Save to save your changes.
The next sections will tell you how to edit custom RDP properties manually in
PowerShell.
Add or edit a single custom RDP property

To add or edit a single custom RDP property, run the following PowerShell cmdlet:
PowerShell
Update-AzWvdHostPool -ResourceGroupName <resourcegroupname> -Name
<hostpoolname> -CustomRdpProperty <property>
７ Note
The Azure Virtual Desktop service doesn't accept escape characters, such as
semicolons or colons, as valid custom RDP property names.
To check if the cmdlet you just ran updated the property, run this cmdlet:
PowerShell
Get-AzWvdHostPool -ResourceGroupName <resourcegroupname> -Name

<hostpoolname> | format-list Name, CustomRdpProperty
Name : <hostpoolname>
CustomRdpProperty : <customRDPpropertystring>
For example, if you were checking for the "audiocapturemode" property on a host pool
named 0301HP, you'd enter this cmdlet:
PowerShell
Get-AzWvdHostPool -ResourceGroupName 0301rg -Name 0301hp | format-list Name,

CustomRdpProperty
Name : 0301HP
CustomRdpProperty : audiocapturemode:i:1;
Add or edit multiple custom RDP properties

To add or edit multiple custom RDP properties, run the following PowerShell cmdlets by
providing the custom RDP properties as a semicolon-separated string:
PowerShell
$properties="<property1>;<property2>;<property3>"

<hostpoolname> -CustomRdpProperty $properties
７ Note
The Azure Virtual Desktop service doesn't accept escape characters, such as
semicolons or colons, as valid custom RDP property names.
You can check to make sure the RDP property was added by running the following
cmdlet:
PowerShell

CustomRdpProperty : <customRDPpropertystring>
Based on our earlier cmdlet example, if you set up multiple RDP properties on the
0301HP host pool, your cmdlet would look like this:
PowerShell
Get-AzWvdHostPool -ResourceGroupName 0301rg -Name 0301hp | format-list Name,

CustomRdpProperty
Name : 0301HP
CustomRdpProperty : audiocapturemode:i:1;audiomode:i:0;
Reset all custom RDP properties

You can reset individual custom RDP properties to their default values by following the
instructions in Add or edit a single custom RDP property. You can also reset all custom
RDP properties for a host pool by running the following PowerShell cmdlet:
PowerShell

<hostpoolname> -CustomRdpProperty ""
To make sure you've successfully removed the setting, enter this cmdlet:
PowerShell

CustomRdpProperty : <CustomRDPpropertystring>
Next steps
Now that you've customized the RDP properties for a given host pool, you can sign in to
an Azure Virtual Desktop client to test them as part of a user session. These next how-to
guides will tell you how to connect to a session using the client of your choice:

Configure the Azure Virtual Desktop
load-balancing method
Configuring the load-balancing method for a host pool allows you to adjust the Azure
Virtual Desktop environment to better suit your needs.
７ Note
This does not apply to a persistent desktop host pool because users always have a
1:1 mapping to a session host within the host pool.
Prerequisites
This article assumes you've followed the instructions in Set up the Azure Virtual Desktop
PowerShell module to download and install the PowerShell module and sign in to your
Azure account.
Configure breadth-first load balancing

Breadth-first load balancing is the default configuration for new non-persistent host
pools. Breadth-first load balancing distributes new user sessions across all available
session hosts in the host pool. When configuring breadth-first load balancing, you may
set a maximum session limit per session host in the host pool.
To configure a host pool to perform breadth-first load balancing without adjusting the
maximum session limit, run the following PowerShell cmdlet:
PowerShell

<hostpoolname> -LoadBalancerType 'BreadthFirst'
After that, to make sure you've set the breadth-first load balancing method, run the
following cmdlet:
PowerShell

<hostpoolname> | format-list Name, LoadBalancerType
Name : hostpoolname
LoadBalancerType : BreadthFirst
To configure a host pool to perform breadth-first load balancing and to use a new
maximum session limit, run the following PowerShell cmdlet:
PowerShell

<hostpoolname> -LoadBalancerType 'BreadthFirst' -MaxSessionLimit ###
Configure depth-first load balancing

Depth-first load balancing distributes new user sessions to an available session host with
the highest number of connections but has not reached its maximum session limit
threshold.
） Important
When configuring depth-first load balancing, you must set a maximum session limit
per session host in the host pool.
To configure a host pool to perform depth-first load balancing, run the following
PowerShell cmdlet:
PowerShell

<hostpoolname> -LoadBalancerType 'DepthFirst' -MaxSessionLimit ###
７ Note
The depth-first load balancing algorithm distributes sessions to session hosts based
on the maximum session host limit ( -MaxSessionLimit ). This parameter's default
value is 999999 , which is also the highest possible number you can set this variable
to. This parameter is required when you use the depth-first load balancing
algorithm. For the best possible user experience, make sure to change the
maximum session host limit parameter to a number that best suits your
environment.
To make sure the setting has updated, run this cmdlet:
PowerShell

<hostpoolname> | format-list Name, LoadBalancerType, MaxSessionLimit
Name : hostpoolname
LoadBalancerType : DepthFirst
MaxSessionLimit : 6
Configure load balancing with the Azure portal

You can also configure load balancing with the Azure portal.
To configure load balancing:
1. Sign into the Azure portal at https://portal.azure.com .

2. Search for and select Azure Virtual Desktop under Services.
3. In the Azure Virtual Desktop page, select Host pools.
4. Select the name of the host pool you want to edit.
5. Select Properties.
6. Enter the Max session limit into the field and select the load balancing algorithm
you want for this host pool in the drop-down menu.
7. Select Save. This applies the new load balancing settings.
Configure personal desktop host pool
assignment
） Important
You can configure the assignment type of your personal desktop host pool to adjust
your Azure Virtual Desktop environment to better suit your needs. In this topic, we'll
show you how to configure automatic or direct assignment for your users.
７ Note
The instructions in this article only apply to personal desktop host pools, not
pooled host pools, since users in pooled host pools aren't assigned to specific
session hosts.
Prerequisites
This article assumes you've already downloaded and installed the Azure Virtual Desktop
PowerShell module. If you haven't, follow the instructions in Set up the PowerShell
module.
Define variables
The PowerShell commands listed in this article require defining the following variables
with the placeholder values replaced with the values relevant to your account and
deployment:
PowerShell
#Define variables
$subscriptionId = <00000000-0000-0000-0000-000000000000>
$resourceGroupName = <MyResourceGroupName>
$hostPoolName = <MyHostPoolName>
$sessionHostName = <SessionHostName>
Personal host pools overview

A personal host pool is a type of host pool that has personal desktops. Personal
desktops have one-to-one mapping, which means a single user can only be assigned to
a single personal desktop. Every time the user signs in, their user session is directed to
their assigned personal desktop session host. This host pool type is ideal for customers
with resource-intensive workloads because user experience and session performance
will improve if there's only one session on the session host. Another benefit of this host
pool type is that user activities, files, and settings persist on the virtual machine
operating system (VM OS) disk after the user signs out.
Users must be assigned to a personal desktop to start their session. There are two types
of assignments in a personal host pool: automatic assignment and direct assignment.
Configure automatic assignment

Automatic assignment is the default assignment type for new personal desktop host
pools created in your Azure Virtual Desktop environment. Automatically assigning users
doesn't require a specific session host.
To automatically assign users, first assign them to the personal desktop host pool so
that they can see the desktop in their feed. When an assigned user launches the desktop
in their feed, their user session will be load-balanced to an available session host if they
haven't already connected to the host pool.
To configure a host pool to automatically assign users to VMs, run the following
PowerShell cmdlet:
PowerShell
Update-AzWvdHostPool -ResourceGroupName $resourceGroupName -Name

$hostPoolName -PersonalDesktopAssignmentType Automatic
To assign a user to the personal desktop host pool, run the following PowerShell cmdlet:
PowerShell

$resourceGroupName -ResourceType
Configure direct assignment

Unlike automatic assignment, when you use direct assignment, you must assign the user
to both the personal desktop host pool and a specific session host before they can
connect to their personal desktop. If the user is only assigned to a host pool without a
session host assignment, they won't be able to access resources and will see an error
message that says, "No resources available."
To configure a host pool to require direct assignment of users to session hosts, run the
following PowerShell cmdlet:
PowerShell
Update-AzWvdHostPool -ResourceGroupName $resourceGroupName -Name

$hostPoolName -PersonalDesktopAssignmentType Direct
To assign a user to the personal desktop host pool, run the following PowerShell cmdlet:
PowerShell

$resourceGroupName -ResourceType
To assign a user to a specific session host, run the following PowerShell cmdlet:
PowerShell
Update-AzWvdSessionHost -HostPoolName $hostPoolName -Name $sessionHostName -

ResourceGroupName $resourceGroupName -AssignedUser <userupn>
To directly assign a user to a session host in the Azure portal:

4. At the Azure Virtual Desktop page, go the menu on the left side of the window and
select Host pools.
5. Select the host pool you want to assign users to.
6. Next, go to the menu on the left side of the window and select Application
groups.
7. Select the name of the app group you want to assign users to, then select
Assignments in the menu on the left side of the window.
8. Select + Add, then select the users or user groups you want to assign to this app
group.
9. Select Assign VM in the Information bar to assign a session host to a user.
10. Select the session host you want to assign to the user, then select Assign. You can
also select Assignment > Assign user.
11. Select the user you want to assign the session host to from the list of available
users.
12. When you're done, select Select.
Unassign a personal desktop using the Azure

portal
To unassign a personal desktop in the Azure portal:
select Host pools.
5. Select the host pool you want to modify user assignment for.
6. Next, go to the menu on the left side of the window and select Session hosts.
7. Select the checkbox next to the session host you want to unassign a user from,
select the ellipses at the end of the row, and then select Unassign user. You can
also select Assignment > Unassign user.
8. Select Unassign when prompted with the warning.
Unassign a personal desktop using PowerShell

To unassign a personal desktop in PowerShell, run the following command:
PowerShell
$unassignDesktopParams = @{
Path =
"/subscriptions/$subscriptionId/resourceGroups/$resourceGroupName/providers/
Microsoft.DesktopVirtualization/hostPools/$hostPoolName/sessionHosts/$($sess
ionHostName)?api-version=2022-02-10-preview&force=true"
Payload = @{
properties = @{
assignedUser = ''
}} | ConvertTo-Json
Method = 'PATCH'
Invoke-AzRestMethod @unassignDesktopParams
Reassign a personal desktop using the Azure

portal
To reassign a personal desktop in the Azure portal:
select Host pools.
5. Select the host pool you want to modify user assignment for.
6. Next, go to the menu on the left side of the window and select Session hosts.
7. Select the checkbox next to the session host you want to reassign to a different
user, select the ellipses at the end of the row, and then select Assign to a different
user. You can also select Assignment > Assign to a different user.
8. Select the user you want to assign the session host to from the list of available
users.
9. When you're done, select Select.
Reassign a personal desktop using PowerShell

Before you start, first define the $reassignUserUpn variable by running the following
command:
PowerShell
$reassignUserUpn = <UPN of user you are reassigning the desktop to>
To reassign a personal desktop, run this command:
PowerShell
$reassignDesktopParams = @{
Path =
ionHostName)?api-version=2022-02-10-preview&force=true"
Payload = @{
properties = @{
assigneduser = $reassignUserUpn
}} | ConvertTo-Json
Method = 'PATCH'
Invoke-AzRestMethod @reassignDesktopParams
Give session hosts in a personal host pool a

friendly name
You can give personal desktops you create friendly names to help users distinguish them
in their feeds.
To give a session host a friendly name, run the following command in PowerShell:
PowerShell
$body = '{ "properties": {
"friendlyName": "friendlyName"
} }'
$parameters = @{
Method = 'Patch'
Path =
ionHostName)?api-version=2022-02-10-preview"
Payload = $body
Invoke-AzRestMethod @parameters
７ Note
You can also set the friendly name by using a REST API.
Get the session host friendly name

To get the session host friendly name, run this command in PowerShell:
PowerShell
$getParams = @{
Path =
'/subscriptions/$subscriptionId/resourceGroups/$resourceGroupName/providers/
ionHostName)?api-version=2022-02-10-preview'
Method = 'GET'
Invoke-AzRestMethod @getParams
Next steps
Now that you've configured the personal desktop assignment type and given your
session host a friendly name, you can sign in to an Azure Virtual Desktop client to test it
as part of a user session. These articles will show you how to connect to a session using
the client of your choice:

Configure a host pool as a validation
environment
） Important
Host pools are a collection of one or more identical virtual machines within Azure Virtual
Desktop environment. We highly recommend you create a validation host pool where
service updates are applied first. Validation host pools let you monitor service updates
before the service applies them to your standard or non-validation environment.
Without a validation host pool, you may not discover changes that introduce errors,
which could result in downtime for users in your standard environment.
To ensure your apps work with the latest updates, the validation host pool should be as
similar to host pools in your non-validation environment as possible. Users should
connect as frequently to the validation host pool as they do to the standard host pool. If
you have automated testing on your host pool, you should include automated testing
on the validation host pool.
You can debug issues in the validation host pool with either the diagnostics feature or
the Azure Virtual Desktop troubleshooting articles.
７ Note
We recommend that you leave the validation host pool in place to test all future
updates. Validation host pools should only be used for testing, and not in
production environments.
Create your host pool

You can configure any existing pooled or personal host pool to be a validation host
pool. You can also create a new host pool to use for validation by following the
instructions in any of these articles:
Tutorial: Create a host pool with Azure Marketplace or the Azure CLI
Create a host pool with PowerShell or the Azure CLI
Define your host pool as a validation

environment
Portal
To use the Azure portal to configure your validation host pool:

3. In the Azure Virtual Desktop page, select Host pools.
4. Select the name of the host pool you want to edit.
6. In the validation environment field, select Yes to enable the validation
environment.
7. Select Save to apply the new settings.
Update schedule
Service updates happen monthly. If there are major issues, critical updates will be
provided at a more frequent pace.
If there are any service updates, make sure you have at least a couple of users sign in
each day to validate the environment. We recommend you regularly visit our
TechCommunity site and follow any posts with WVDUPdate or AVDUpdate to stay
informed about service updates.
Next steps
Now that you've created a validation host pool, you can learn how to use Azure Service
Health to monitor your Azure Virtual Desktop deployment.
Set up service alerts
 Documentation





examples.


Show 5 more
 Training
Module
Training
Scheduled Agent Updates for Azure
Virtual Desktop host pools
The Scheduled Agent Updates feature lets you create up to two maintenance windows
for the Azure Virtual Desktop agent, side-by-side stack, and Geneva Monitoring agent to
get updated so that updates don't happen during peak business hours. To monitor
agent updates, you can use Log Analytics to see when agent component updates are
available and when updates are unsuccessful.
This article describes how the Scheduled Agent Updates feature works and how to set it
up.
７ Note
Azure Virtual Desktop (classic) doesn't support the Scheduled Agent Updates
feature.
Configure the Scheduled Agent Updates

feature using the Azure portal
To use the Azure portal to configure Scheduled Agent Updates:
1. Open your browser and go to the Azure portal .
2. In the Azure portal, go to Azure Virtual Desktop.
3. Select Host pools, then go to the host pool where you want to enable the feature.
You can only configure this feature for existing host pools. You can't enable this
feature when you create a new host pool.
4. In the host pool, select Scheduled Agent Updates. Scheduled Agent Updates is
disabled by default. This means that, unless you enable this setting, the agent can
get updated at any time by the agent update flighting service. Select the
Scheduled agent updates checkbox to enable the feature.
5. Enter your preferred time zone setting. If you select Use local session host time
zone, Scheduled Agent Updates will automatically use the VM's local time zone. If
you don't select Use local session host time zone, you'll need to specify a time
zone.
6. Select a day and time for the Maintenance window. If you'd like to make an
optional second maintenance window, you can also select a date and time for it
here. Since Scheduled Agent Updates is a host pool setting, the time zone setting
and maintenance windows you configure will be applied to all session hosts in the
host pool.
7. Select Apply to apply your settings.

Additional information
How the feature works

The Scheduled Agent Updates feature updates the Azure Virtual Desktop agent, side-
by-side stack, and Geneva Monitoring agent if any one or more of these components
needs to be updated. Any reference to the agent components is referring to these three
components. Scheduled Agent Updates doesn't apply to the initial installation of the
agent components. When you install the agent on a virtual machine (VM), the agent will
automatically install the side-by-side stack and the Geneva Monitoring agent regardless
of which maintenance windows you set. Any non-critical updates after installation will
only happen within your maintenance windows. Host pools with the Scheduled Agent
Updates feature enabled will receive the agent update after the agent has been fully
flighted to production. For more information about how agent flighting works, see
Agent update process.
The agent component update won't succeed if the session host
VM is shut down or deallocated during the scheduled update time. If you enable
Scheduled Agent Updates, make sure all session hosts in your host pool are on during
your configured maintenance window time. The broker will attempt to update the agent
components during each specified maintenance window up to four times. After the
fourth try, the broker will install the update by force. This process gives time for
installation retries if an update is unsuccessful, and also prevents session hosts from
having outdated versions of agent components. If a critical agent component update is
available, the broker will install the agent component by force for security purposes.
Maintenance window and time zone information

You must specify at least one maintenance window. Configuring the second
maintenance window is optional. Creating two maintenance windows gives the
agent components additional opportunities to update if the first update during
one of the windows is unsuccessful.
All maintenance windows are two hours long to account for situations where all
three agent components must be updated at the same time. For example, if your
maintenance window is Saturday at 9:00 AM PST, the updates will happen between
9:00 AM PST and 11:00 AM PST.
The Use session host local time parameter isn't selected by default. If you want
the agent component update to be in the same time zone for all session hosts in
your host pool, you'll need to specify a single time zone for your maintenance
windows. Having a single time zone helps when all your session hosts or users are
located in the same time zone.
If you select Use session host local time, the agent component update will be in
the local time zone of each session host in the host pool. Use this setting when all
session hosts in your host pool or their assigned users are in different time zones.
For example, let's say you have one host pool with session hosts in West US in the
Pacific Standard Time zone and session hosts in East US in the Eastern Standard
Time zone, and you've set the maintenance window to be Saturday at 9:00 PM.
Enabling Use session host local time ensures that updates to all session hosts in
the host pool will happen at 9:00 PM in their respective time zones. Disabling Use
session host local time and setting the time zone to be Central Standard Time
ensures that updates to the session hosts in the host pool will happen at 9:00 PM
Central Standard Time, regardless of the session hosts' local time zones.
The local time zone for VMs you create using the Azure portal is set to
Coordinated Universal Time (UTC) by default. If you want to change the VM time
zone, run the Set-TimeZone PowerShell cmdlet on the VM.
To get a list of available time zones for a VM, run the Get-TimeZone PowerShell
cmdlet on the VM.
Next steps
For more information related to Scheduled Agent Updates and agent components,
check out the following resources:
Learn how to set up diagnostics for this feature at the Scheduled Agent Updates
Diagnostics guide.
Learn more about the Azure Virtual Desktop agent, side-by-side stack, and Geneva
Monitoring agent at Getting Started with the Azure Virtual Desktop Agent.
For more information about the current and earlier versions of the Azure Virtual
Desktop agent, see Azure Virtual Desktop agent updates.
If you're experiencing agent or connectivity-related issues, see the Azure Virtual
Desktop Agent issues troubleshooting guide.
Delete a host pool
All host pools created in Azure Virtual Desktop are attached to session hosts and app
groups. To delete a host pool, you need to delete its associated app groups and session
hosts. Deleting an app group is fairly simple, but deleting a session host is more
complicated. When you delete a session host, you need to make sure it doesn't have
any active user sessions. All user sessions on the session host should be logged off to
prevent users from losing data.
Portal
To delete a host pool in the Azure portal:
3. Select Host pools in the menu on the left side of the page, then select the
name of the host pool you want to delete.
4. On the menu on the left side of the page, select Application groups.
5. Select all application groups in the host pool you're going to delete, then
select Remove.
6. Once you've removed the app groups, go to the menu on the left side of the
page and select Overview.
7. Select Remove.
8. If there are session hosts in the host pool you're deleting, you'll see a message
asking for your permission to continue. Select Yes.
9. The Azure portal will now remove all session hosts and delete the host pool.
The VMs related to the session host won't be deleted and will remain in your
subscription.
Next steps
To learn how to create a host pool, check out these articles:
Create a host pool with the Azure portal
Create a host pool with PowerShell
To learn how to configure host pool settings, check out these articles:
Customize Remote Desktop Protocol properties for a host pool

Configure the Azure Virtual Desktop load-balancing method
Configure the personal desktop host pool assignment type
 Documentation



pool.


environment.

Troubleshoot Azure Virtual Desktop session host - Azure

How to resolve issues when you're configuring Azure Virtual Desktop session host virtual machines.
Show 5 more
 Training
Module
Training
Administrative template for Azure
Virtual Desktop
We've created an administrative template for Azure Virtual Desktop to configure some
features of Azure Virtual Desktop. You can use the template with Group Policy, which
enables you to centrally configure session hosts that are joined to an Active Directory
(AD) domain. You can also use the template with Group Policy locally on each session
host, but this isn't recommended to manage session hosts at scale.
You can configure the following features with the administrative template:

RDP Shortpath for managed networks
Watermarking
７ Note
Importing the administrative template to Microsoft Intune is currently not

supported. You should eventually be able to configure these features using the
Intune settings catalog.
Prerequisites
You'll need the following permission:
For Group Policy in an Active Directory domain, you'll need to be a member of the
Domain Admins security group.
For local Group Policy on a session host, you'll need to be a member of the local
Administrators security group.
Add the administrative template

To add the administrative template, select a tab for your scenario and follow these steps.
Group Policy (AD)

７ Note
These steps assume you're using the Central Store for Group Policy.
1. Download the latest Azure Virtual Desktop administrative template files and
extract the contents of the .cab file and .zip archive.
2. Copy and paste the terminalserver-avd.admx file to the Group Policy Central
Store for your domain, for example
\\contoso.com\SYSVOL\contoso.com\Policies\PolicyDefinitions , where
contoso.com is your domain name. Then copy the terminalserver-avd.adml file
to the en-us subfolder.
3. Open the Group Policy Management Console (GPMC) and create or edit a
4. To verify that the Azure Virtual Desktop administrative template is available,

browse to Computer Configuration > Policies > Administrative Templates >
Windows Components > Remote Desktop Services > Remote Desktop
Session Host > Azure Virtual Desktop. You should see policy settings for
Azure Virtual Desktop, as shown in the following screenshot:
Next steps
Learn how to use the administrative template with the following features:
RDP Shortpath for managed networks
Watermarking
 Documentation

Watermarking in Azure Virtual Desktop (preview)

Learn how to enable watermarking in Azure Virtual Desktop (preview) to help prevent sensitive
information from being captured on client endpoints.
Manage session hosts with Microsoft Intune - Azure Virtual Desktop

Recommended ways for you to manage your Azure Virtual Desktop session hosts.
Azure Virtual Desktop security best practices - Azure

Best practices for keeping your Azure Virtual Desktop environment secure.



Publish built-in apps in Azure Virtual Desktop - Azure

How to publish built-in apps in Azure Virtual Desktop.
Show 5 more
Apply Windows license to session host
virtual machines
Customers who are properly licensed to run Azure Virtual Desktop workloads are
eligible to apply a Windows license to their session host virtual machines and run them
without paying for another license. For more information, see Azure Virtual Desktop
pricing .
Ways to apply an Azure Virtual Desktop license

Azure Virtual Desktop licensing allows you to apply a license to any Windows or
Windows Server virtual machine (VM) that's registered as a session host in a host pool
and receives user connections. This license doesn't apply to virtual machines running as
file share servers, domain controllers, and so on.
You can apply an Azure Virtual Desktop license to your VMs with the following methods:
You can create a host pool and its session host virtual machines in the Azure
portal. Creating VMs in the Azure portal automatically applies the license.
You can create a host pool and its session host virtual machines using the GitHub
Azure Resource Manager template . Creating VMs with this method automatically
applies the license.
You can manually apply a license to an existing session host virtual machine. To
apply the license this way, first follow the instructions in Create a host pool with
PowerShell or the Azure CLI to create a host pool and associated VMs, then return
to this article to learn how to apply the license.
Manually apply a Windows license to a

Windows client session host VM
７ Note
The directions in this section apply to Windows client VMs, not Windows Server
VMs.
Before you start, make sure you've installed and configured the latest version of Azure
PowerShell.
Next, run the following PowerShell cmdlet to apply the Windows license:
PowerShell
$vm = Get-AzVM -ResourceGroup <resourceGroupName> -Name <vmName>
$vm.LicenseType = "Windows_Client"
Update-AzVM -ResourceGroupName <resourceGroupName> -VM $vm
Verify your session host VM is utilizing the

licensing benefit
After deploying your VM, run this cmdlet to verify the license type:
PowerShell
Get-AzVM -ResourceGroupName <resourceGroupName> -Name <vmName>
A session host VM with the applied Windows license will show you something like this:
PowerShell
Type : Microsoft.Compute/virtualMachines
Location : westus
LicenseType : Windows_Client
VMs without the applied Windows license will show you something like this:
PowerShell
Type : Microsoft.Compute/virtualMachines
Location : westus
LicenseType :
Run the following cmdlet to see a list of all session host VMs that have the Windows
license applied in your Azure subscription:
PowerShell
$vms = Get-AzVM
$vms | Where-Object {$_.LicenseType -like "Windows_Client"} | Select-Object

ResourceGroupName, Name, LicenseType
Using Windows Server as session hosts

If you deploy Windows Server as session hosts in Azure Virtual Desktop, a Remote
Desktop Services license server must be accessible from those virtual machines. The
Remote Desktop Services license server can be located on-premises or in Azure, as long
as there is network connectivity between the session hosts and license server. For more
information, see Activate the Remote Desktop Services license server.
Known limitations
If you create a Windows Server session host using the Azure Virtual Desktop host pool
creation process, the process might automatically assign it an incorrect license type. To
change the license type using PowerShell, follow the instructions in Convert an existing
VM using Azure Hybrid Benefit for Windows Server.
 Documentation

to production.



Azure Virtual Desktop Start VM Connect FAQ - Azure

Frequently asked questions and best practices for using the Start VM on Connect feature.
Estimate per-user app streaming costs for Azure Virtual Desktop - Azure
How to estimate per-user billing costs for Azure Virtual Desktop.
Storage FSLogix profile container Azure Virtual Desktop - Azure

Options for storing your Azure Virtual Desktop FSLogix profile on Azure Storage.
Show 5 more
 Training
Module
Training
Certification
Create an autoscale scaling plan for
Autoscale lets you scale your session host virtual machines (VMs) in a host pool up or
down to optimize deployment costs. You can create a scaling plan based on:
Time of day
Specific days of the week
Session limits per session host
To learn more about autoscale, see Autoscale scaling plans and example scenarios in
７ Note
Azure Virtual Desktop (classic) doesn't support autoscale.

Autoscale doesn't support Azure Virtual Desktop for Azure Stack HCI.
Autoscale doesn't support scaling of ephemeral disks.
Autoscale doesn't support scaling of generalized or sysprepped VMs with
machine-specific information removed. For more information, see Remove
machine-specific information by generalizing a VM before creating an
image.
You can't use autoscale and scale session hosts using Azure Automation and
Azure Logic Apps on the same host pool. You must use one or the other.
Autoscale is available in Azure and Azure Government.
For best results, we recommend using autoscale with VMs you deployed with Azure
Virtual Desktop Azure Resource Manager templates or first-party tools from Microsoft.
） Important
Deploying scaling plans with autoscale in Azure is currently limited to the following
regions:
Australia East
Canada Central
Canada East
Central India
Central US
East US
East US 2
Japan East
North Central US
North Europe
South Central US
UK South
UK West
West Central US
West Europe
West US
West US 2
West US 3
Prerequisites
To use scaling plans, make sure you follow these guidelines:
You can currently only configure autoscale with existing pooled host pools.
You must create the scaling plan in the same Azure region as the host pool you
assign it to. You can't assign a scaling plan in one Azure region to a host pool in
another Azure region.
All host pools you use with autoscale must have a configured MaxSessionLimit
parameter. Don't use the default value. You can configure this value in the host
pool settings in the Azure portal or run the New-AzWvdHostPool or Update-
AzWvdHostPool PowerShell cmdlets.
You must grant Azure Virtual Desktop access to manage the power state of your
session host VMs. You must have the
Microsoft.Authorization/roleAssignments/write permission on your subscriptions
in order to assign the role-based access control (RBAC) role for the Azure Virtual
Desktop service principal on those subscriptions. This is part of User Access
Administrator and Owner built in roles.
Assign the Desktop Virtualization Power On Off

Contributor role with the Azure portal
Before creating your first scaling plan, you'll need to assign the Desktop Virtualization
Power On Off Contributor RBAC role with your Azure subscription as the assignable
scope. Assigning this role at any level lower than your subscription, such as the resource
group, host pool, or VM, will prevent autoscale from working properly. You'll need to
add each Azure subscription as an assignable scope that contains host pools and
session host VMs you want to use with autoscale. This role and assignment will allow
Azure Virtual Desktop to manage the power state of any VMs in those subscriptions. It
will also let the service apply actions on both host pools and VMs when there are no
active user sessions.
To assign the Desktop Virtualization Power On Off Contributor role with the Azure portal
to the Azure Virtual Desktop service principal on the subscription your host pool is
deployed to:
1. Sign in to the Azure portal and go to Subscriptions. Select a subscription that

contains a host pool and session host VMs you want to use with autoscale.
3. Select the + Add button, then select Add role assignment from the drop-down
menu.
4. Select the Desktop Virtualization Power On Off Contributor role and select Next.
members. In the search bar, enter and select either Azure Virtual Desktop or
Windows Virtual Desktop. Which value you have depends on when the
Microsoft.DesktopVirtualization resource provider was first registered in your Azure
tenant. If you see two entries titled Windows Virtual Desktop, please see the tip
below.
6. Select Review + assign to complete the assignment. Repeat this for any other
subscriptions that contain host pools and session host VMs you want to use with
autoscale.
 Tip
The application ID for the service principal is 9cdead84-a844-4324-93f2-

b2e6bb768d07.
If you have an Azure Virtual Desktop (classic) deployment and an Azure Virtual
Desktop (Azure Resource Manager) deployment where the
Microsoft.DesktopVirtualization resource provider was registered before the display
name changed, you will see two apps with the same name of Windows Virtual
Desktop. To add the role assignment to the correct service principal, you can use
PowerShell which enables you to specify the application ID:
To assign the Desktop Virtualization Power On Off Contributor role with PowerShell
to the Azure Virtual Desktop service principal on the subscription your host pool is
deployed to:
1. Open Azure Cloud Shell with PowerShell as the shell type.
2. Get the object ID for the service principal (which is unique in each Azure
tenant) and store it in a variable:
PowerShell
$objId = (Get-AzADServicePrincipal -AppId "9cdead84-a844-4324-93f2-

b2e6bb768d07").Id
3. Find the name of the subscription you want to add the role assignment to by
listing all that are available to you:
PowerShell
Get-AzSubscription
4. Get the subscription ID and store it in a variable, replacing the value for -
SubscriptionName with the name of the subscription from the previous step:
PowerShell
$subId = (Get-AzSubscription -SubscriptionName "Microsoft Azure

Enterprise").Id
5. Add the role assignment:
PowerShell
New-AzRoleAssignment -RoleDefinitionName "Desktop Virtualization

Power On Off Contributor" -ObjectId $objId -Scope
/subscriptions/$subId
Create a scaling plan

Now that you've assigned the Desktop Virtualization Power On Off Contributor role to
the service principal on your subscriptions, you can create a scaling plan. To create a
scaling plan:
1. Open the Azure portal .
3. Select Scaling Plans, then select Create.
4. In the Basics tab, look under Project details and select the name of the
subscription you'll assign the scaling plan to.
5. If you want to make a new resource group, select Create new. If you want to use
an existing resource group, select its name from the drop-down menu.
6. Enter a name for the scaling plan into the Name field.
7. Optionally, you can also add a "friendly" name that will be displayed to your users
and a description for your plan.
8. For Region, select a region for your scaling plan. The metadata for the object will
be stored in the geography associated with the region. To learn more about
regions, see Data locations.
9. For Time zone, select the time zone you'll use with your plan.
10. In Exclusion tags, enter a tag name for VMs you don't want to include in scaling
operations. For example, you might want to tag VMs that are set to drain mode so
that autoscale doesn't override drain mode during maintenance using the
exclusion tag "excludeFromScaling". If you've set "excludeFromScaling" as the tag
name field on any of the VMs in the host pool, autoscale won't start, stop, or
change the drain mode of those particular VMs.
７ Note
Though an exclusion tag will exclude the tagged VM from power

management scaling operations, tagged VMs will still be considered as
part of the calculation of the minimum percentage of hosts.
Make sure not to include any sensitive information in the exclusion tags
such as user principal names or other personally identifiable information.
11. Select Next, which should take you to the Schedules tab.
Configure a schedule
Schedules let you define when autoscale activates ramp-up and ramp-down modes
throughout the day. In each phase of the schedule, autoscale only turns off VMs when in
doing so the used host pool capacity won't exceed the capacity threshold. The default
values you'll see when you try to create a schedule are the suggested values for
weekdays, but you can change them as needed.
To create or change a schedule:
1. In the Schedules tab, select Add schedule.
2. Enter a name for your schedule into the Schedule name field.
3. In the Repeat on field, select which days your schedule will repeat on.
4. In the Ramp up tab, fill out the following fields:
For Start time, select a time from the drop-down menu to start preparing
VMs for peak business hours.
For Load balancing algorithm, we recommend selecting breadth-first

algorithm. Breadth-first load balancing will distribute users across existing
VMs to keep access times fast.
７ Note
The load balancing preference you select here will override the one you
selected for your original host pool settings.
For Minimum percentage of hosts, enter the percentage of session hosts you
want to always remain on in this phase. If the percentage you enter isn't a
whole number, it's rounded up to the nearest whole number. For example, in
a host pool of seven session hosts, if you set the minimum percentage of
hosts during ramp-up hours to 10%, one VM will always stay on during ramp-
up hours, and it won't be turned off by autoscale.
For Capacity threshold, enter the percentage of available host pool capacity
that will trigger a scaling action to take place. For example, if two session
hosts in the host pool with a max session limit of 20 are turned on, the
available host pool capacity is 40. If you set the capacity threshold to 75%
and the session hosts have more than 30 user sessions, autoscale will turn on
a third session host. This will then change the available host pool capacity
from 40 to 60.
5. In the Peak hours tab, fill out the following fields:
For Start time, enter a start time for when your usage rate is highest during
the day. Make sure the time is in the same time zone you specified for your
scaling plan. This time is also the end time for the ramp-up phase.
For Load balancing, you can select either breadth-first or depth-first load
balancing. Breadth-first load balancing distributes new user sessions across
all available session hosts in the host pool. Depth-first load balancing
distributes new sessions to any available session host with the highest
number of connections that hasn't reached its session limit yet. For more
information about load-balancing types, see Configure the Azure Virtual
Desktop load-balancing method.
７ Note
You can't change the capacity threshold here. Instead, the setting you entered
in Ramp-up will carry over to this setting.
For Ramp-down, you'll enter values into similar fields to Ramp-up, but this
time it will be for when your host pool usage drops off. This will include the
following fields:
Start time
Load-balancing algorithm
Minimum percentage of hosts (%)
Capacity threshold (%)
Force logoff users
） Important
If you've enabled autoscale to force users to sign out during ramp-down,

the feature will choose the session host with the lowest number of user
sessions to shut down. Autoscale will put the session host in drain mode,
send all active user sessions a notification telling them they'll be signed
out, and then sign out all users after the specified wait time is over. After
autoscale signs out all user sessions, it then deallocates the VM. If you
haven't enabled forced sign out during ramp-down, session hosts with
no active or disconnected sessions will be deallocated.
During ramp-down, autoscale will only shut down VMs if all existing user
sessions in the host pool can be consolidated to fewer VMs without
exceeding the capacity threshold.
Likewise, Off-peak hours works the same way as Peak hours:

Start time, which is also the end of the ramp-down period.
Load-balancing algorithm. We recommend choosing depth-first to
gradually reduce the number of session hosts based on sessions on each
VM.
Just like peak hours, you can't configure the capacity threshold here.
Instead, the value you entered in Ramp-down will carry over.
Assign host pools

Now that you've set up your scaling plan, it's time to assign the plan to your host pools.
Select the check box next to each host pool you want to include. If you don't want to
enable autoscale, unselect all check boxes. You can always return to this setting later and
change it.
７ Note
When you create or update a scaling plan that's already assigned to host pools, its
changes will be applied immediately.
Add tags
After that, you'll need to enter tags. Tags are name and value pairs that categorize
resources for consolidated billing. You can apply the same tag to multiple resources and
resource groups. To learn more about tagging resources, see Use tags to organize your
Azure resources.
７ Note
If you change resource settings on other tabs after creating tags, your tags will be
automatically updated.
Once you're done, go to the Review + create tab and select Create to deploy your host
pool.
Edit an existing scaling plan

To edit an existing scaling plan:
3. Select Scaling plans, then select the name of the scaling plan you want to edit. The
overview blade of the scaling plan should open.
4. To change the scaling plan host pool assignments, under the Manage heading
select Host pool assignments .
5. To edit schedules, under the Manage heading, select Schedules.
6. To edit the plan's friendly name, description, time zone, or exclusion tags, go to the
Properties tab.
Next steps
Now that you've created your scaling plan, here are some things you can do:
Assign your scaling plan to new and existing host pools

Enable diagnostics for your scaling plan
If you'd like to learn more about terms used in this article, check out our autoscale
glossary. For examples of how autoscale works, see Autoscale example scenarios. You
can also look at our Autoscale FAQ if you have other questions.
 Documentation



Expand existing host pool with new session hosts - Azure

How to expand an existing host pool with new session hosts in Azure Virtual Desktop.


Show 5 more
 Training

Training
Assign scaling plans to host pools in
You can assign a scaling plan for any existing host pools in your deployment. When you
apply a scaling plan to your host pool, the plan will apply to all session hosts within that
host pool. The scaling plan also automatically applies to any new session hosts you
create in your assigned host pool.
If you disable a scaling plan, all assigned resources will remain in the scaling state they
were in at the time you disabled it.
Assign a scaling plan to a single existing host

pool
To assign a scaling plan to an existing host pool:
3. Select Host pools, and select the host pool you want to assign the scaling plan to.
4. Under the Settings heading, select Scaling plan, and then select + Assign. Select
the scaling plan you want to assign and select Assign. The scaling plan must be in
the same Azure region as the host pool.
 Tip
If you've enabled the scaling plan during deployment, then you'll also have the
option to disable the plan for the selected host pool in the Scaling plan menu by
unselecting the Enable autoscale checkbox, as shown in the following screenshot.
Assign a scaling plan to multiple existing host
pools
To assign a scaling plan multiple existing host pool at the same time:
3. Select Scaling plans, and select the scaling plan you want to assign to host pools.
4. Under the Manage heading, select Host pool assignments, and then select +
Assign. Select the host pools you want to assign the scaling plan to and select
Assign. The host pools must be in the same Azure region as the scaling plan.
Next steps
Review how to create a scaling plan at Autoscale for Azure Virtual Desktop session
hosts.
Learn how to troubleshoot your scaling plan at Enable diagnostics for your scaling
plan.
Learn more about terms used in this article at our autoscale glossary.
View our autoscale FAQ to answer commonly asked questions.
 Documentation








examples.
Show 5 more
 Training

Training
Set up diagnostics for autoscale in
Diagnostics lets you monitor potential issues and fix them before they interfere with
your autoscale scaling plan.
Currently, you can either send diagnostic logs for autoscale to an Azure Storage account
or consume logs with the Events hub. If you're using an Azure Storage account, make
sure it's in the same region as your scaling plan. Learn more about diagnostic settings at
Create diagnostic settings. For more information about resource log data ingestion time,
see Log data ingestion time in Azure Monitor.
Enable diagnostics for scaling plans

To enable diagnostics for your scaling plan:
3. Select Scaling plans, then select the scaling plan you'd like the report to track.
4. Go to Diagnostic Settings and select Add diagnostic setting.
5. Enter a name for the diagnostic setting.
6. Next, select Autoscale and choose either storage account or event hub depending
on where you want to send the report.
7. Select Save.
Set log location in Azure Storage

After you've configured your diagnostic settings, you can find the logs by following
these instructions:
1. In the Azure portal, go to the storage group you sent the diagnostic logs to.
2. Select Containers. A folder called insight-logs-autoscaling should open.

3. Select the insight-logs-autoscaling folder and open the log you want to review.
Open folders within that folder until you see the JSON file, then select all items in
that folder, right-click, and download them to your local computer.
4. Finally, open the JSON file in the text editor of your choice.
View diagnostic logs

Now that you've opened the JSON file, let's do a quick overview of what each piece of
the report means:
The CorrelationID is the ID that you need to show when you create a support case.
OperationName is the type of operation running while the issue happened.
ResultType is the result of the operation. This item can show you where issues are
if you notice any incomplete results.
Message is the error message that provides information on the incomplete

operation. This message can include links to important troubleshooting
documentation, so review it carefully.
The following JSON file is an example of what you'll see when you open a report:
JSON
"host_Ring": "R0",
"Level": 4,
"ActivityId": "c1111111-1111-1111-b111-11111cd1ba1b1",
"time": "2021-08-31T16:00:46.5246835Z",
"resourceId": "/SUBSCRIPTIONS/AD11111A-1C21-1CF1-A7DE-
CB1111E1D111/RESOURCEGROUPS/TEST/PROVIDERS/MICROSOFT.DESKTOPVIRTUALIZATION/S
CALINGPLANS/TESTPLAN",
"operationName": "HostPoolLoadBalancerTypeUpdated",
"category": "Autoscale",
"resultType": "Succeeded",
"level": "Informational",
"correlationId": "35ec619b-b5d8-5b5f-9242-824aa4d2b878",
"properties": {
"Message": "Host pool's load balancing algorithm updated",
"HostPoolArmPath": "/subscriptions/AD11111A-1C21-1CF1-A7DE-
CB1111E1D111/resourcegroups/test/providers/microsoft.desktopvirtualization/h
ostpools/testHostPool ",
"PreviousLoadBalancerType": "BreadthFirst",
"NewLoadBalancerType": "DepthFirst"
Next steps
Review how to create a scaling plan at Autoscale for Azure Virtual Desktop session
hosts.
Assign your scaling plan to new or existing host pools.
Learn more about terms used in this article at our autoscale glossary.
View our autoscale FAQ to answer commonly asked questions.
Set up scaling tool using Azure
Automation and Azure Logic Apps for
In this article, you'll learn about the scaling tool that uses an Azure Automation runbook
and Azure Logic App to automatically scale session host VMs in your Azure Virtual
Desktop environment. To learn more about the scaling tool, see Scale session hosts
using Azure Automation and Azure Logic Apps.
７ Note
Autoscale is an alternative way to scale session host VMs and is a native

feature of Azure Virtual Desktop. We recommend you use Autoscale instead.
For more information, see Autoscale scaling plans.
You can't scale session hosts using Azure Automation and Azure Logic Apps
together with autoscale on the same host pool. You must use one or the
other.
Prerequisites
Before you start setting up the scaling tool, make sure you have the following things
ready:
An Azure Virtual Desktop host pool.

Session host pool VMs configured and registered with the Azure Virtual Desktop
service.
A user with the Contributor role-based access control (RBAC) role assigned on the
Azure subscription to create the resources. You'll also need the Application
administrator and/or Owner RBAC role to create a Run As account.
A Log Analytics workspace (optional).
The machine you use to deploy the tool must have:
PowerShell 5.1 or later

The Azure Az PowerShell module
If you have everything ready, let's get started.
Create or update an Azure Automation account
７ Note
If you already have an Azure Automation account with a runbook running an older
version of the scaling script, all you need to do is follow the instructions below to
make sure it's updated.
First, you'll need an Azure Automation account to run the PowerShell runbook. The
process this section describes is valid even if you have an existing Azure Automation
account that you want to use to set up the PowerShell runbook. Here's how to set it up:
1. Open PowerShell.
2. Run the following cmdlet to sign in to your Azure account.
PowerShell
Login-AzAccount
７ Note
Your account must have contributor rights on the Azure subscription where
you want to deploy the scaling tool.
3. Run the following cmdlet to download the script for creating the Azure
Automation account:
PowerShell
New-Item -ItemType Directory -Path "C:\Temp" -Force
Set-Location -Path "C:\Temp"
$Uri = "https://raw.githubusercontent.com/Azure/RDS-
Templates/master/wvd-templates/wvd-scaling-
script/CreateOrUpdateAzAutoAccount.ps1"
# Download the script
Invoke-WebRequest -Uri $Uri -OutFile

".\CreateOrUpdateAzAutoAccount.ps1"
4. Run the following cmdlet to execute the script and create the Azure Automation
account. You can either fill in values for the parameters or comment them to use
their defaults.
PowerShell
$Params = @{
"AADTenantId" = "<Azure_Active_Directory_tenant_ID>" #
Optional. If not specified, it will use the current Azure context
"SubscriptionId" = "<Azure_subscription_ID>" #
Optional. If not specified, it will use the current Azure context
"UseARMAPI" = $true
"ResourceGroupName" = "<Resource_group_name>" #
Optional. Default: "WVDAutoScaleResourceGroup"
"AutomationAccountName" = "<Automation_account_name>" #
Optional. Default: "WVDAutoScaleAutomationAccount"
"Location" = "<Azure_region_for_deployment>"
"WorkspaceName" = "<Log_analytics_workspace_name>" #
Optional. If specified, Log Analytics will be used to configure the
custom log table that the runbook PowerShell script can send logs to
.\CreateOrUpdateAzAutoAccount.ps1 @Params
７ Note
If your policy doesn't let you create scaling script resources in a specific
region, update the policy assignment and add the region you want to the list
of allowed regions.
5. If you haven't created an automation account before, the cmdlet's output will
include an encrypted webhook URI in the automation account variable. Make sure
to keep a record of the URI because you'll use it as a parameter when you set up
the execution schedule for the Azure Logic App. If you're updating an existing
automation account, you can retrieve the webhook URI using PowerShell to access
variables.
6. If you specified the parameter WorkspaceName for Log Analytics, the cmdlet's
output will also include the Log Analytics Workspace ID and its Primary Key. Make
a note of the Workspace ID and Primary Key because you'll need to use them
again later with parameters when you set up the execution schedule for the Azure
Logic App.
7. After you've set up your Azure Automation account, sign in to your Azure
subscription and check to make sure your Azure Automation account and the
relevant runbook have appeared in your specified resource group, as shown in the
following image:
To check if your webhook is where it should be, select the name of your runbook.
Next, go to your runbook's Resources section and select Webhooks.
Create an Azure Automation Run As account

Now that you have an Azure Automation account, you'll also need to create an Azure
Automation Run As account if you don't have one already. This account will let the tool
access your Azure resources.
） Important
This scaling tool uses a Run As account with Azure Automation. Azure Automation
Run As accounts will retire on September 30, 2023. Microsoft won't provide support
beyond that date. From now through September 30, 2023, you can continue to use
Azure Automation Run As accounts. This scaling tool won't be updated to create
the resources using managed identities, however, you can transition to use
managed identities and will need to before then. For more information, see
Migrate from an existing Run As account to a managed identity.
Autoscale is an alternative way to scale session host VMs and is a native feature of
Azure Virtual Desktop. We recommend you use Autoscale instead. For more
information, see Autoscale scaling plans.
An Azure Automation Run As account provides authentication for managing resources

in Azure with Azure cmdlets. When you create a Run As account, it creates a new service
principal user in Azure Active Directory and assigns the Contributor role to the service
principal user at the subscription level. An Azure Run As account is a great way to
authenticate securely with certificates and a service principal name without needing to
store a username and password in a credential object. To learn more about Run As
account authentication, see Limit Run As account permissions.
Any user who's assigned the Application administrator and/or Owner RBAC role on the
subscription can create a Run As account.
To create a Run As account in your Azure Automation account:
1. In the Azure portal, select All services. In the list of resources, enter and select
Automation accounts.
2. On the Automation accounts page, select the name of your Azure Automation
account.
3. In the pane on the left side of the window, select Run As accounts under the
Account Settings section.
4. Select Azure Run As account. When the Add Azure Run As account pane appears,
review the overview information, and then select Create to start the account
creation process.
5. Wait a few minutes for Azure to create the Run As account. You can track the
creation progress in the menu under Notifications.
6. When the process finishes, it will create an asset named AzureRunAsConnection in

the specified Azure Automation account. Select Azure Run As account. The
connection asset holds the application ID, tenant ID, subscription ID, and certificate
thumbprint. You can also find the same information on the Connections page. To
go to this page, in the pane on the left side of the window, select Connections
under the Shared Resources section and select the connection asset named
AzureRunAsConnection.
Create the Azure Logic App and execution

schedule
Finally, you'll need to create the Azure Logic App and set up an execution schedule for
your new scaling tool. First, download and import the Desktop Virtualization PowerShell
module to use in your PowerShell session if you haven't already.
1. Open PowerShell.
2. Run the following cmdlet to sign in to your Azure account.
PowerShell
Login-AzAccount
3. Run the following cmdlet to download the script for creating the Azure Logic App.
PowerShell
New-Item -ItemType Directory -Path "C:\Temp" -Force
Set-Location -Path "C:\Temp"
$Uri = "https://raw.githubusercontent.com/Azure/RDS-
Templates/master/wvd-templates/wvd-scaling-
script/CreateOrUpdateAzLogicApp.ps1"
# Download the script
Invoke-WebRequest -Uri $Uri -OutFile ".\CreateOrUpdateAzLogicApp.ps1"
4. Run the following PowerShell script to create the Azure Logic App and execution
schedule for your host pool
７ Note
You'll need to run this script for each host pool you want to autoscale, but you
need only one Azure Automation account.
PowerShell
$AADTenantId = (Get-AzContext).Tenant.Id
$AzSubscription = Get-AzSubscription | Out-GridView -OutputMode:Single

-Title "Select your Azure Subscription"
Select-AzSubscription -Subscription $AzSubscription.Id
$ResourceGroup = Get-AzResourceGroup | Out-GridView -OutputMode:Single

-Title "Select the resource group for the new Azure Logic App"
$WVDHostPool = Get-AzResource -ResourceType

"Microsoft.DesktopVirtualization/hostpools" | Out-GridView -
OutputMode:Single -Title "Select the host pool you'd like to scale"
$LogAnalyticsWorkspaceId = Read-Host -Prompt "If you want to use Log

Analytics, enter the Log Analytics Workspace ID returned by when you
created the Azure Automation account, otherwise leave it blank"
$LogAnalyticsPrimaryKey = Read-Host -Prompt "If you want to use Log

Analytics, enter the Log Analytics Primary Key returned by when you
created the Azure Automation account, otherwise leave it blank"
$RecurrenceInterval = Read-Host -Prompt "Enter how often you'd like the

job to run in minutes, e.g. '15'"
$BeginPeakTime = Read-Host -Prompt "Enter the start time for peak hours
in local time, e.g. 9:00"
$EndPeakTime = Read-Host -Prompt "Enter the end time for peak hours in
local time, e.g. 18:00"
$TimeDifference = Read-Host -Prompt "Enter the time difference between

local time and UTC in hours, e.g. +5:30"
$SessionThresholdPerCPU = Read-Host -Prompt "Enter the maximum number

of sessions per CPU that will be used as a threshold to determine when
new session host VMs need to be started during peak hours"
$MinimumNumberOfRDSH = Read-Host -Prompt "Enter the minimum number of

session host VMs to keep running during off-peak hours"
$MaintenanceTagName = Read-Host -Prompt "Enter the name of the Tag

associated with VMs you don't want to be managed by this scaling tool"
$LimitSecondsToForceLogOffUser = Read-Host -Prompt "Enter the number of

seconds to wait before automatically signing out users. If set to 0,
any session host VM that has user sessions, will be left untouched"
$LogOffMessageTitle = Read-Host -Prompt "Enter the title of the message

sent to the user before they are forced to sign out"
$LogOffMessageBody = Read-Host -Prompt "Enter the body of the message

sent to the user before they are forced to sign out"
$AutoAccount = Get-AzAutomationAccount | Out-GridView -

OutputMode:Single -Title "Select the Azure Automation account"
$AutoAccountConnection = Get-AzAutomationConnection -ResourceGroupName

$AutoAccount.ResourceGroupName -AutomationAccountName
$AutoAccount.AutomationAccountName | Out-GridView -OutputMode:Single -
Title "Select the Azure RunAs connection asset"
$WebhookURI = Read-Host -Prompt "Enter the webhook URI that has already
been generated for this Azure Automation account. The URI is stored as
encrypted in the above Automation Account variable. To retrieve the
value, see https://learn.microsoft.com/azure/automation/shared-
resources/variables?tabs=azure-powershell#powershell-cmdlets-to-access-
variables"
$Params = @{
"AADTenantId" = $AADTenantId
# Optional. If not specified, it will use the current Azure context
"SubscriptionID" = $AzSubscription.Id
# Optional. If not specified, it will use the current Azure context
"ResourceGroupName" = $ResourceGroup.ResourceGroupName
# Optional. Default: "WVDAutoScaleResourceGroup"
"Location" = $ResourceGroup.Location
# Optional. Default: "West US2"
"UseARMAPI" = $true
"HostPoolName" = $WVDHostPool.Name
"HostPoolResourceGroupName" = $WVDHostPool.ResourceGroupName
# Optional. Default: same as ResourceGroupName param value
"LogAnalyticsWorkspaceId" = $LogAnalyticsWorkspaceId
# Optional. If not specified, script will not log to the Log Analytics
"LogAnalyticsPrimaryKey" = $LogAnalyticsPrimaryKey
# Optional. If not specified, script will not log to the Log Analytics
"ConnectionAssetName" = $AutoAccountConnection.Name
# Optional. Default: "AzureRunAsConnection"
"RecurrenceInterval" = $RecurrenceInterval
# Optional. Default: 15
"BeginPeakTime" = $BeginPeakTime
# Optional. Default: "09:00"
"EndPeakTime" = $EndPeakTime
# Optional. Default: "17:00"
"TimeDifference" = $TimeDifference
# Optional. Default: "-7:00"
"SessionThresholdPerCPU" = $SessionThresholdPerCPU
"MinimumNumberOfRDSH" = $MinimumNumberOfRDSH
"MaintenanceTagName" = $MaintenanceTagName
# Optional.
"LimitSecondsToForceLogOffUser" = $LimitSecondsToForceLogOffUser
"LogOffMessageTitle" = $LogOffMessageTitle
# Optional. Default: "Machine is about to shutdown."
"LogOffMessageBody" = $LogOffMessageBody
# Optional. Default: "Your session will be logged off. Please save and
close everything."
"WebhookURI" = $WebhookURI
.\CreateOrUpdateAzLogicApp.ps1 @Params
After you run the script, the Azure Logic App should appear in a resource group, as
shown in the following image.
To make changes to the execution schedule, such as changing the recurrence

interval or time zone, go to the Azure Logic App autoscale scheduler and select
Edit to go to the Azure Logic App Designer.
Manage your scaling tool
Now that you've created your scaling tool, you can access its output. This section
describes a few features you might find helpful.
View job status

You can view a summarized status of all runbook jobs or view a more in-depth status of
a specific runbook job in the Azure portal.
On the right of your selected Azure Automation account, under "Job Statistics," you can
view a list of summaries of all runbook jobs. Opening the Jobs page on the left side of
the window shows current job statuses, start times, and completion times.
View logs and scaling tool output
You can view the logs of scale-out and scale-in operations by opening your runbook
and selecting the job.
Navigate to the runbook in your resource group hosting the Azure Automation account
and select Overview. On the overview page, select a job under Recent Jobs to view its
scaling tool output, as shown in the following image.
Check the runbook script version number

You can check which version of the runbook script you're using by opening the runbook
file in your Azure Automation account and selecting View. A script for the runbook will
appear on the right side of the screen. In the script, you'll see the version number in the
format v#.#.# under the SYNOPSIS section. You can find the latest version number
here . If you don't see a version number in your runbook script, that means you're
running an earlier version of the script and you should update it right away. If you need
to update your runbook script, follow the instructions in Create or update an Azure
Automation account.
Reporting issues
When you report an issue, you'll need to provide the following information to help us
troubleshoot:
A complete log from the All Logs tab in the job that caused the issue. To learn how
to get the log, follow the instructions in View logs and scaling tool output. If
there's any sensitive or private information in the log, you can remove it before
submitting the issue to us.
The version of the runbook script you're using. To find out how to get the version
number, see Check the runbook script version number
The version number of each of the following PowerShell modules installed in your
Azure Automation account. To find these modules, open Azure Automation
account, select Modules under the Shared Resources section in the pane on the
left side of the window, and then search for the module's name.
Az.Accounts
Az.Compute
Az.Resources
Az.Automation
OMSIngestionAPI
The expiration date for your Run As account. To find this, open your Azure
Automation account, then select Run As accounts under Account Settings in the
pane on the left side of the window. The expiration date should be under Azure
Run As account.
Log Analytics
If you decided to use Log Analytics, you can view all the log data in a custom log named
WVDTenantScale_CL under Custom Logs in the Logs view of your Log Analytics
Workspace. We've listed some sample queries you might find helpful.
To see all logs for a host pool, enter the following query:
Kusto
WVDTenantScale_CL
| where hostpoolName_s == "<host_pool_name>"
| project TimeStampUTC = TimeGenerated, TimeStampLocal = TimeStamp_s,

HostPool = hostpoolName_s, LineNumAndMessage = logmessage_s,
AADTenantId = TenantId
To view the total number of currently running session host VMs and active user
sessions in your host pool, enter the following query:
Kusto
WVDTenantScale_CL
| where logmessage_s contains "Number of running session hosts:"
or logmessage_s contains "Number of user sessions:"
or logmessage_s contains "Number of user sessions per Core:"

To view the status of all session host VMs in a host pool, enter the following query:
Kusto
WVDTenantScale_CL
| where logmessage_s contains "Session host:"

To view any errors and warnings, enter the following query:
Kusto
WVDTenantScale_CL
| where logmessage_s contains "ERROR:" or logmessage_s contains "WARN:"

Limitations
Here are some limitations with scaling session host VMs with this scaling script:
The scaling script doesn’t consider time changes between standard and daylight
savings.
 Documentation

Scale session hosts using Azure Automation and Azure Logic Apps for Azure Virtual
Desktop - Azure
Learn about scaling Azure Virtual Desktop session hosts with Azure Automation and Azure Logic
Apps.

Create an autoscale scaling plan for Azure Virtual Desktop

How to create an autoscale scaling plan to optimize deployment costs.


to production.
Show 5 more
 Training
Module
Automate Azure Virtual Desktop management tasks - Training
Automate Azure Virtual Desktop management tasks
Certification
Microsoft Certified: Azure Developer Associate - Certifications
Azure developers design, build, test, and maintain cloud applications and services.
Use drain mode to isolate session hosts
and apply patches
Drain mode isolates a session host when you want to apply patches and do
maintenance without disrupting user sessions. When isolated, the session host won't
accept new user sessions. Any new connections will be redirected to the next available
session host. Existing connections in the session host will keep working until the user
signs out or the administrator ends the session. When the session host is in drain mode,
admins can also remotely connect to the server without going through the Azure Virtual
Desktop service. You can apply this setting to both pooled and personal desktops.
Set drain mode using the Azure portal

To turn on drain mode in the Azure portal:
1. Open the Azure portal and go to the host pool you want to isolate.
2. In the navigation menu, select Session hosts.
3. Next, select the hosts you want to turn on drain mode for, then select Turn drain
mode on.
4. To turn off drain mode, select the host pools that have drain mode turned on, then
select Turn drain mode off.
Set drain mode using PowerShell

You can set drain mode in PowerShell with the AllowNewSessions parameter, which is
part of the Update-AzWvdSessionhost command.
Run this cmdlet to enable drain mode:
PowerShell
Update-AzWvdSessionHost -ResourceGroupName <resourceGroupName> -HostPoolName

<hostpoolname> -Name <hostname> -AllowNewSession:$False
Run this cmdlet to disable drain mode:
PowerShell
Update-AzWvdSessionHost -ResourceGroupName <resourceGroupName> -HostPoolName
<hostpoolname> -Name <hostname> -AllowNewSession:$True
） Important
You'll need to run this command for every session host you're applying the setting
to.
Next steps
If you want to learn more about the Azure portal for Azure Virtual Desktop, check out
our tutorials. If you're already familiar with the basics, check out some of the other
features you can use with the Azure portal, such as MSIX app attach and Azure Advisor.
If you're using the PowerShell method and want to see what else the module can do,
check out Set up the PowerShell module for Azure Virtual Desktop and our PowerShell
reference.
 Documentation
Troubleshoot Azure Virtual Desktop Agent Issues - Azure

How to resolve common Azure Virtual Desktop Agent and connectivity issues.




Set up Start VM on Connect for Azure Virtual Desktop

How to set up the Start VM on Connect feature for Azure Virtual Desktop to turn on session host
virtual machines only when they're needed.

Show 5 more
Use Microsoft Configuration Manager
to automatically deploy software
updates to Azure Virtual Desktop
session hosts
Azure Virtual Desktop session hosts running Windows 10 Enterprise multi-session and
Windows 11 Enterprise multi-session can be grouped together in Microsoft
Configuration Manager to automatically apply updates. A collection is created based on
a query which you can then use as the target collection for a servicing plan.
You can update Windows 10 Enterprise multi-session and Windows 11 Enterprise multi-
session with the corresponding Windows client updates. For example, you can update
Windows 10 Enterprise multi-session, version 21H2 by installing the client updates for
Windows 10, version 21H2.
Prerequisites
To create this query-based collection, you'll need to do the following:
Make sure you've installed the Microsoft Configuration Manager Agent on your
session host virtual machines (VMs) and they're assigned to a site in Configuration
Manager.
Make sure your version of Microsoft Configuration Manager is at least on branch
level 1910 for Windows 10, or 2107 for Windows 11.
Create a query-based collection

You can use a query statement based on the specific operating system SKU to identify
which of your devices managed by Configuration Manager are running Windows 10
Enterprise multi-session and Windows 11 Enterprise multi-session operating systems.
 Tip
The operating system SKU for Windows 10 Enterprise multi-session and Windows
11 Enterprise multi-session is 175. You can use PowerShell to find the operating
system SKU by running the following command:
PowerShell
Get-WmiObject -Class Win32_OperatingSystem | FT

Caption,OperatingSystemSKU
To create the collection:
1. In the Configuration Manager console, select Assets and Compliance.
2. Go to Overview > Device Collections and right-click Device collections and select
Create Device Collection from the drop-down menu.
3. In the General tab of the menu that opens, enter a name that describes your
collection in the Name field. In the Comment field, you can give additional
information describing what the collection is. In Limiting Collection, define which
machines you're including in the collection query.
4. In the Membership Rules tab, add a rule for your query by selecting Add Rule,
then selecting Query Rule.
5. In Query Rule Properties, enter a name for your rule, then define the parameters
of the rule by selecting Edit Query Statement.
6. Select Show Query Statement.
7. In the statement, enter the following string:
WQL
select
SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS
_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SM
S_R_SYSTEM.Client
from SMS_R_System inner join SMS_G_System_OPERATING_SYSTEM on
SMS_G_System_OPERATING_SYSTEM.ResourceId = SMS_R_System.ResourceId
where
SMS_G_System_OPERATING_SYSTEM.OperatingSystemSKU = 175
8. Select OK to create the collection.
9. To check if you successfully created the collection, go to Assets and Compliance >
Overview > Device Collections.
Deploy software updates

You can use an automatic deployment rule (ADR) in Microsoft Configuration Manager to
automatically approve and deploy software updates. You specify the collection you
created above as the target collection for deployment to deploy these updates to your
session host VMs.
For more information about deploying software updates with Microsoft Configuration
Manager, see Deploy software updates. For the steps to create an ADR, see
Automatically deploy software updates.
 Documentation






How to monitor with Azure Virtual Desktop Insights - Azure

How to use Azure Virtual Desktop Insights.
Show 5 more
Set up Start VM on Connect
Start VM On Connect lets you reduce costs by enabling end users to turn on their
session host virtual machines (VMs) only when they need them. You can them turn off
VMs when they're not needed.
You can configure Start VM on Connect for personal or pooled host pools using the
Azure portal or PowerShell. Start VM on Connect is a host pool setting.
For personal host pools, Start VM On Connect will only turn on an existing session host
VM that has already been assigned or will be assigned to a user. For pooled host pools,
Start VM On Connect will only turn on a session host VM when none are turned on and
additional VMs will only be turned on when the first VM reaches the session limit.
The time it takes for a user to connect to a session host VM that is powered off
(deallocated) increases because the VM needs time to turn on again, much like turning
on a physical computer. The Remote Desktop client has an indicator that lets the user
know the VM is being powered on while they're connecting.
７ Note
Azure Virtual Desktop (classic) doesn't support Start VM On Connect.
Prerequisites
To use Start VM on Connect, make sure you follow these guidelines:
You can only configure Start VM on Connect on existing host pools. You can't
enable it at the same time you create a new host pool.
The following Remote Desktop clients support Start VM on Connect:
The Windows client (version 1.2.2061 or later)
The Web client
The macOS client (version 10.6.4 or later)
The iOS and iPadOS client (version 10.2.5 or later)
The Android and Chrome OS client (version 10.0.10 or later)
The Microsoft Store client (version 10.2.2005.0 or later)
Thin clients listed in Thin client support
If you want to configure Start VM on Connect using PowerShell, you'll need to
have the Az.DesktopVirtualization PowerShell module (version 2.1.0 or later)
installed on the device you use to run the commands.
You must grant Azure Virtual Desktop access to power on session host VMs, check
their status, and report diagnostic information. You must have the
Microsoft.Authorization/roleAssignments/write permission on your subscriptions
in order to assign the role-based access control (RBAC) role for the Azure Virtual
Desktop service principal on those subscriptions. This is part of User Access
Administrator and Owner built in roles.
If you enable Start VM on Connect on a host pool, you must make sure that the
host pool name, the names of the session hosts in that host pool, and the resource
group name don't have non-ANSI characters. If their names contain non-ANSI
characters, then Start VM on Connect won't work as expected.
Assign the Desktop Virtualization Power On

Contributor role with the Azure portal
Before you can configure Start VM on Connect, you'll need to assign the Desktop
Virtualization Power On Contributor role-based access control (RBAC) role with your
Azure subscription as the assignable scope. Assigning this role at any level lower than
your subscription, such as the resource group, host pool, or VM, will prevent Start VM
on Connect from working properly. You'll need to add each Azure subscription as an
assignable scope that contains host pools and session host VMs you want to use with
Start VM on Connect. This role and assignment will allow Azure Virtual Desktop to
power on VMs, check their status, and report diagnostic information in those
subscriptions.
To assign the Desktop Virtualization Power On Contributor role with the Azure portal to
the Azure Virtual Desktop service principal on the subscription your host pool is
deployed to:
1. Open the Azure portal and go to Subscriptions. Select a subscription that contains
a host pool and session host VMs you want to use with Start VM on Connect.
3. Select the + Add button, then select Add role assignment from the drop-down
menu.
4. Select the Desktop Virtualization Power On Contributor role and select Next.
members. In the search bar, enter and select either Azure Virtual Desktop or
Windows Virtual Desktop. Which value you have depends on when the
Microsoft.DesktopVirtualization resource provider was first registered in your Azure
tenant. If you see two entries titled Windows Virtual Desktop, please see the tip
below.
6. Select Review + assign to complete the assignment. Repeat this for any other
subscriptions that contain host pools and session host VMs you want to use with
Start VM on Connect.
 Tip
The application ID for the service principal is 9cdead84-a844-4324-93f2-

b2e6bb768d07.
If you have an Azure Virtual Desktop (classic) deployment and an Azure Virtual
Desktop (Azure Resource Manager) deployment where the
Microsoft.DesktopVirtualization resource provider was registered before the display
name changed, you will see two apps with the same name of Windows Virtual
Desktop. To add the role assignment to the correct service principal, you can use
PowerShell which enables you to specify the application ID:
To assign the Desktop Virtualization Power On Contributor role with PowerShell to

the Azure Virtual Desktop service principal on the subscription your host pool is
deployed to:
1. Open Azure Cloud Shell with PowerShell as the shell type.
2. Get the object ID for the service principal (which is unique in each Azure
tenant) and store it in a variable:
PowerShell
$objId = (Get-AzADServicePrincipal -AppId "9cdead84-a844-4324-93f2-

b2e6bb768d07").Id
3. Find the name of the subscription you want to add the role assignment to by
listing all that are available to you:
PowerShell
Get-AzSubscription
4. Get the subscription ID and store it in a variable, replacing the value for -
SubscriptionName with the name of the subscription from the previous step:
PowerShell
$subId = (Get-AzSubscription -SubscriptionName "Microsoft Azure

Enterprise").Id
5. Add the role assignment:
PowerShell
New-AzRoleAssignment -RoleDefinitionName "Desktop Virtualization

Power On Contributor" -ObjectId $objId -Scope /subscriptions/$subId
Enable or disable Start VM on Connect

Now that you've assigned the Desktop Virtualization Power On Contributor role to the
service principal on your subscriptions, you can configure Start VM on Connect using
the Azure portal or PowerShell.
Portal
To configure Start VM on Connect using the Azure portal:
2. In the search bar, enter Azure Virtual Desktop and select the matching service
entry.
3. Select Host pools, then select the name of the host pool where you want to
enable the setting.
5. In the configuration section, you'll see Start VM on connect. Select Yes to

enable it, or No to disable it.
6. Select Save to apply the settings.
７ Note
In pooled host pools, Start VM on Connect will start a VM every five minutes at
most. If other users try to sign in during this five-minute period while there aren't
any available resources, Start VM on Connect won't start a new VM. Instead, the
users trying to sign in will receive an error message that says, "No resources
available."
Troubleshooting
If you run into any issues with Start VM On Connect, we recommend you use the Azure
Virtual Desktop diagnostics feature to check for problems. If you receive an error
message, make sure to pay close attention to the message content and make a note of
the error name for reference. You can also use Azure Virtual Desktop Insights to get
suggestions for how to resolve issues.
If the session host VM doesn't turn on, you'll need to check the health of the VM you
tried to turn on as a first step.
For other questions, check out the Start VM on Connect FAQ.
Next steps
For more information about Start VM on Connect, see our Start VM on Connect FAQ.
Start VM on Connect FAQ
This article covers frequently asked questions about the Start Virtual Machine (VM) on
Connect feature for Azure Virtual Desktop host pools.
Are VMs automatically deallocated when a user

stops using them?
No. You'll need to configure additional policies to sign users out of their sessions and
run Azure automation scripts to deallocate VMs.
To configure the deallocation policy:
1. Connect remotely to the VM that you want to set the policy for.
2. Open the Group Policy Editor, then go to Local Computer Policy > Computer
Configuration > Administrative Templates > Windows Components > Remote
Desktop Services > Remote Desktop Session Host > Session Time Limits.
3. Find the policy that says Set time limit for disconnected sessions, then change its
value to Enabled.
4. After you've enabled the policy, select End a disconnected session.
７ Note
Make sure to set the time limit for the "End a disconnected session" policy to a
value greater than five minutes. A low time limit can cause users' sessions to end if
their network loses connection for too long, resulting in lost work.
Signing users out won't deallocate their VMs. To learn how to deallocate VMs, see Start
or stop VMs during off hours for personal host pools and Autoscale for pooled host
pools.
Can users turn off the VM from their clients?

Yes. Users can shut down the VM by using the Start menu within their session, just like
they would with a physical machine. However, shutting down the VM won't deallocate
the VM. To learn how to deallocate VMs, see Start or stop VMs during off hours for
personal host pools and Autoscale for pooled host pools.
How does load balancing affect Start VM on

Connect?
For pooled host pools, Start VM on Connect will wait until all virtual machines hit their
maximum session limit before turning on additional VMs.
For example, let's say your host pool has three VMs and has a maximum session limit of
five users per machine. If you turn on two VMs, Start VM on Connect won't turn on the
third machine until both VMs reach their maximum session limit of five users.
Next steps
To learn how to configure Start VM on Connect, see Start virtual machine on connect.
If you have more general questions about Azure Virtual Desktop, check out our general
FAQ.
Screen capture protection in Azure
Virtual Desktop
Screen capture protection, alongside watermarking, helps prevent sensitive information

from being captured on client endpoints. When you enable screen capture protection,
remote content will be automatically blocked or hidden in screenshots and screen
shares. Also, the Remote Desktop client will hide content from malicious software that
may be capturing the screen.
In Windows 11, version 22H2 or later, you can enable screen capture protection on
session host VMs as well as remote clients. Protection on session host VMs works just
like protection for remote clients.
Prerequisites
Screen capture protection is configured on the session host level and enforced on the
client. Only clients that support this feature can connect to the remote session.
You must connect to Azure Virtual Desktop with one of the following clients to use
support screen capture protection:
The Windows Desktop client supports screen capture protection for full desktops.
The macOS client (version 10.7.0 or later) supports screen capture protection for
both RemoteApps and full desktops.
The Windows Desktop client (running Windows 11, Version 22H2 or later) supports
screen capture protection for RemoteApps.
Configure screen capture protection

To configure screen capture protection:
1. Download the Azure Virtual Desktop policy templates file (AVDGPTemplate.cab)

and extract the contents of the cab file and zip archive.
2. Copy the terminalserver-avd.admx file to the %windir%\PolicyDefinitions folder.
3. Copy the en-us\terminalserver-avd.adml file to the

%windir%\PolicyDefinitions\en-us folder.
4. To confirm the files copied correctly, open the Group Policy Editor and go to
Computer Configuration > Administrative Templates > Windows Components >
Remote Desktop Services > Remote Desktop Session Host > Azure Virtual
Desktop. You should see one or more Azure Virtual Desktop policies, as shown in
the following screenshot.
 Tip
You can also install administrative templates to the group policy Central Store
in your Active Directory domain.
For more information, see How to create and
manage the Central Store for Group Policy Administrative Templates in
Windows.
5. Open the "Enable screen capture protection" policy and set it to "Enabled".
6. To configure screen capture for client and server, set the "Enable screen capture
protection" policy to "Block Screen capture on client and server". By default, the
policy will be set to "Block Screen capture on client".
７ Note
You can only use screen capture protection on session host VMs that use
Windows 11, version 22H2 or later.
Limitations and known issues

If a user tries to connect to a capture-protected session host with an unsupported
client, the connection won't work and will instead show an error message with the
code 0x1151 .
This feature protects the Remote Desktop window from being captured through a
specific set of public operating system features and Application Programming
Interfaces (APIs). However, there's no guarantee that this feature will strictly
protect content in scenarios where a user were to take a photo of their screen with
a physical camera.
For maximum security, customers should use this feature while also disabling
clipboard, drive, and printer redirection. Disabling redirection prevents users from
copying any captured screen content from the remote session.
Users can't share their Remote Desktop window using local collaboration software,
such as Microsoft Teams, while this feature is enabled. When they use Microsoft
Teams, neither the local Teams app nor Teams with media optimization can share
protected content.
Next steps
Learn about how to secure your Azure Virtual Desktop deployment at Security best
practices.
 Documentation





Azure Virtual Desktop security best practices - Azure

Best practices for keeping your Azure Virtual Desktop environment secure.

What is Azure Virtual Desktop remote app streaming? - Azure

An overview of Azure Virtual Desktop remote app streaming.
Show 5 more
Watermarking in Azure Virtual Desktop
(preview)
） Important
Watermarking is currently in PREVIEW.

See the Supplemental Terms of Use for
Microsoft Azure Previews for legal terms that apply to Azure features that are in
beta, preview, or otherwise not yet released into general availability.
Watermarking (preview), alongside screen capture protection, helps prevent sensitive

information from being captured on client endpoints. When you enable watermarking,
QR code watermarks appear as part of remote desktops. The QR code contains the
connection ID of a remote session that admins can use to trace the session.
Watermarking is configured on session hosts and enforced by the Remote Desktop
client.
Here's a screenshot showing what watermarking looks like when it's enabled:
） Important
Once watermarking is enabled on a session host, only clients that support

watermarking can connect to that session host. If you try to connect from an
unsupported client, the connection will fail and you'll get an error message
that is not specific.
Watermarking is for remote desktops only. With remote apps, watermarking is

not applied and the connection is allowed.
If you connect to a session host directly (not through Azure Virtual Desktop)
using the Remote Desktop Connection app ( mstsc.exe ), watermarking is not
applied and the connection is allowed.
Prerequisites
You'll need the following things before you can use watermarking:
A Remote Desktop client that supports watermarking. The following clients

currently support watermarking:
Windows Desktop client, version 1.2.3317 or later, on Windows 10 and later.
Azure Virtual Desktop Insights configured for your environment.
Enable watermarking
To enable watermarking, follow the steps below:
1. Follow the steps to download and add the Administrative template for Azure
Virtual Desktop.
2. Once you've verified that the Azure Virtual Desktop administrative template is
available, open the policy setting Enable watermarking and set it to Enabled.
3. You can configure the following options:
Option Values Description
QR code bitmap 1 to 10
The size in pixels of each QR code dot. This value
scale factor (default determines how many the number of squares per dot in
= 4) the QR code.
QR code bitmap 100 to How transparent the watermark is, where 100 is fully
opacity 9999 transparent.
(default
= 700)
Option Values Description
Width of grid box 100 to Determines the distance between the QR codes in percent.
in percent relevant 1000
When combined with the height, a value of 100 would
to QR code bitmap (default make the QR codes appear side-by-side and fill the entire
width = 320) screen.
Height of grid box 100 to Determines the distance between the QR codes in percent.
in percent relevant 1000
When combined with the width, a value of 100 would make
to QR code bitmap (default the QR codes appear side-by-side and fill the entire screen.
width = 180)
 Tip
We recommend trying out different opacity values to find a balance between

the readability of the remote session and being able to scan the QR code, but
keeping the default values for the other parameters.
4. Apply the policy settings to your session hosts by running a Group Policy update
or Intune device sync.
5. Connect to a remote session, where you should see QR codes appear. For any
changes you make to the policy and apply to the session host, you'll need to
disconnect and reconnect to your remote session to see the difference.
Find session information

Once you've enabled watermarking, you can find the session information from the QR
code by using Azure Virtual Desktop Insights or querying Azure Monitor Log Analytics.

To find out the session information from the QR code by using Azure Virtual Desktop
Insights:
1. Open a web browser and go to https://aka.ms/avdi to open Azure Virtual

Desktop Insights. Sign-in using your Azure credentials when prompted.
2. Select the relevant subscription, resource group, host pool and time range, then
select the Connection Diagnostics tab.
3. In the section Success rate of (re)establishing a connection (% of connections),

there's a list of all connections showing First attempt, Connection Id, User, and
Attempts. You can look for the connection ID from the QR code in this list, or
export to Excel.
Azure Monitor Log Analytics

To find out the session information from the QR code by querying Azure Monitor Log
Analytics:
2. In the search bar, type Log Analytics workspaces and select the matching service
entry.
3. Select to open the Log Analytics workspace that is connected to your Azure Virtual
4. Under General, select Logs.
5. Start a new query, then run the following query to get session information for a
specific connection ID (represented as CorrelationId in Log Analytics), replacing
<connection ID> with the full or partial value from the QR code:
Kusto
WVDConnections
| where CorrelationId contains "<connection ID>"
Next steps
Learn more about Azure Virtual Desktop Insights.
For more information about Azure Monitor Log Analytics, see Overview of Log
Analytics in Azure Monitor.
Azure Virtual Desktop disaster recovery
To keep your organization's data safe, you should adopt and manage a business
continuity and disaster recovery (BCDR) strategy. A sound BCDR strategy keeps your
apps and workloads up and running during planned and unplanned service or Azure
outages. These plans should cover the session host virtual machines (VMs) managed by
customers, as opposed to the Azure Virtual Desktop service that's managed by
Microsoft. For more information about management areas, see Azure Virtual Desktop
disaster recovery concepts.
The Azure Virtual Desktop service is designed with high availability in mind. Azure
Virtual Desktop is a global service managed by Microsoft, with multiple instances of its
independent components distributed across multiple Azure regions. If there's an
unexpected outage in any of the components, your traffic will be diverted to one of the
remaining instances or Microsoft will initiate a full failover to redundant infrastructure in
another Azure region.
To make sure users can still connect during a region outage in session host VMs, you
need to design your infrastructure with high availability and disaster recovery in mind. A
typical disaster recovery plan includes replicating virtual machines (VMs) to a different
location. During outages, the primary site fails over to the replicated VMs in the
secondary location. Users can continue to access apps from the secondary location
without interruption. On top of VM replication, you'll need to keep user identities
accessible at the secondary location. If you're using profile containers, you'll also need
to replicate them. Finally, make sure your business apps that rely on data in the primary
location can fail over with the rest of the data.
To summarize, to keep your users connected during an outage, you'll need to do the
following things:
Replicate the VMs to a secondary location.

If you're using profile containers, set up data replication in the secondary location.
Make sure user identities you set up in the primary location are available in the
secondary location. To ensure availability, make sure your Active Directory Domain
Controllers are available in or from the secondary location.
Make sure any line-of-business applications and data in your primary location are
also failed over to the secondary location.
Active-passive and active-active disaster
recovery plans
There are two different types of disaster recovery infrastructure: active-passive and
active-active. Each type of infrastructure works a different way, so let's look at what
those differences are.
Active-passive plans are when you have a region with one set of resources that's active
and one that's turned off until it's needed (passive). If the active region is taken offline
by an outage or disaster, the organization can switch to the passive region by turning it
on and directing all the users there.
Another option is an active-active deployment, where you use both sets of infrastructure
at the same time. While some users may be affected by outages, the impact is limited to
the users in the region that went down. Users in the other region that's still online won't
be affected, and the recovery is limited to the users in the affected region reconnecting
to the functioning active region. Active-active deployments can take many forms,
including:
Overprovisioning infrastructure in each region to accommodate affected users in

the event one of the regions goes down. A potential drawback to this method is
that maintaining the additional resources costs more.
Have extra session hosts in both active regions, but deallocate them when they
aren't needed, which reduces costs.
Only provision new infrastructure during disaster recovery and allow affected users
to connect to the newly provisioned session hosts. This method requires regular
testing with infrastructure-as-code tools so you can deploy the new infrastructure
as quickly as possible during a disaster.
For more information about types of disaster recovery plans you can use, see Azure
Virtual Desktop disaster recovery concepts.
Identifying which method works best for your organization is the first thing you should
do before you get started. Once you have your plan in place, you can start building your
recovery plan.
VM replication
First, you'll need to replicate your VMs to the secondary location. Your options for doing
so depend on how your VMs are configured:
You can configure replication for all your VMs in both pooled and personal host
pools with Azure Site Recovery. For more information about how this process
works, see Replicate Azure VMs to another Azure region. However, if you have
pooled host pools that you built from the same image and don't have any personal
user data stored locally, you can choose not to replicate them. Instead, you have
the option to build the VMs ahead of time and keep them powered off. You can
also choose to only provision new VMs in the secondary region while a disaster is
happening. If you choose these methods, you'll only need to set up one host pool
and its related app groups and workspaces.
You can create a new host pool in the failover region while keeping all resources in
your failover location turned off. For this method, you'd need to set up new app
groups and workspaces in the failover region. You can then use an Azure Site
Recovery plan to turn on host pools.
You can create a host pool that's populated by VMs built in both the primary and
failover regions while keeping the VMs in the failover region turned off. In this
case, you only need to set up one host pool and its related app groups and
workspaces. You can use an Azure Site Recovery plan to power on host pools with
this method.
We recommend you use Azure Site Recovery to manage replicating VMs to other Azure
locations, as described in Azure-to-Azure disaster recovery architecture. We especially
recommend using Azure Site Recovery for personal host pools because, true to their
name, personal host pools tend to have something personal about them for their users.
Azure Site Recovery supports both server-based and client-based SKUs.
If you use Azure Site Recovery, you won't need to register these VMs manually. The
Azure Virtual Desktop agent in the secondary VM will automatically use the latest
security token to connect to the service instance closest to it. The VM (session host) in
the secondary location will automatically become part of the host pool. The end-user
will have to reconnect during the process, but apart from that, there are no other
manual operations.
If there are existing user connections during the outage, before the admin can start
failing over to the secondary region, you need to end the user connections in the
current region.
To disconnect users in Azure Virtual Desktop (classic), run this cmdlet:
PowerShell
Invoke-RdsUserSessionLogoff
To disconnect users in Azure Virtual Desktop, run this cmdlet:
PowerShell
Remove-AzWvdUserSession
Once you've signed out all users in the primary region, you can fail over the VMs in the
primary region and let users connect to the VMs in the secondary region.
Virtual network
Next, consider your network connectivity during the outage. You'll need to make sure
you've set up a virtual network (VNET) in your secondary region. If your users need to
access on-premises resources, you'll need to configure this VNET to access them. You
can establish on-premises connections with a VPN, ExpressRoute, or virtual WAN.
We recommend you use Azure Site Recovery to set up the VNET in the failover region
because it preserves your primary network's settings and doesn't need peering.
User identities
Next, ensure that the domain controller is available at the secondary location.
There are three ways to keep the domain controller available:
Have one or more Active Directory Domain Controllers in the secondary location
Use an on-premises Active Directory Domain Controller
Replicate Active Directory Domain Controller using Azure Site Recovery
Back up your data

You also have the option to back up your data. You can choose one of the following
methods to back up your Azure Virtual Desktop data:
For Compute data, we recommend only backing up personal host pools with Azure
Backup.
For Storage data, the backup solution we recommend varies based on the back-
end storage you used to store user profiles:
If you used Azure Files Share, we recommend using Azure Backup for File Share.
If you used Azure NetApp Files, we recommend using either Snapshots/Policies
or Azure NetApp Files Backup.
App dependencies
Finally, make sure that any business apps that rely on data located in the primary region
can fail over to the secondary location. Also, be sure to configure the settings the apps
need to work in the new location. For example, if one of the apps is dependent on the
SQL backend, make sure to replicate SQL in the secondary location. You should
configure the app to use the secondary location as either part of the failover process or
as its default configuration. You can model app dependencies on Azure Site Recovery
plans. To learn more, see About recovery plans.
Disaster recovery testing

After you're done setting up disaster recovery, you'll want to test your plan to make sure
it works.
Here are some suggestions for how to test your plan:
If the test VMs have internet access, they'll take over any existing session host for
new connections, but all existing connections to the original session host will
remain active. Make sure the admin running the test signs out all active users
before testing the plan.
You should only do full disaster recovery tests during a maintenance window to
not disrupt your users.
Make sure your test covers all business-critical applications and data.
We recommend you only failover up to 100 VMs at a time. If you have more VMs
than that, we recommend you fail them over in batches 10 minutes apart.
Next steps
If you have questions about how to keep your data secure in addition to planning for
outages, check out our security guide.
Connect to Azure Virtual Desktop with
the Remote Desktop client for Windows
The Microsoft Remote Desktop client is used to connect to Azure Virtual Desktop to
access your desktops and applications. This article shows you how to connect to Azure
Virtual Desktop with the Remote Desktop client for Windows.
You can find a list of all the Remote Desktop clients you can use to connect to Azure
Virtual Desktop at Remote Desktop clients overview.
Prerequisites
Before you can access your resources, you'll need to meet the prerequisites:
Internet access.
A device running one of the following supported versions of Windows:

Windows 11
Windows 11 IoT Enterprise
Windows 10
Windows 10 IoT Enterprise
Windows Server 2019
Windows Server 2016
Windows Server 2012 R2
） Important
Support for Windows 7 ended on January 10, 2023.
Download the Remote Desktop client installer, choosing the correct version for
your device:
Windows 64-bit (most common)
Windows 32-bit
Windows on Arm
.NET Framework 4.6.2 or later. You may need to install this on Windows Server
2012 R2, Windows Server 2016, and some versions of Windows 10. To download
the latest version, see Download .NET Framework .
Install the Remote Desktop client
Once you've downloaded the Remote Desktop client, you'll need to install it by
following these steps:
 Tip
If you want to deploy the Remote Desktop client in an enterprise, you can use
msiexec to install the MSI file. For more information, see Enterprise deployment.
1. Run the installer by double-clicking the file you downloaded.
2. On the welcome screen, select Next.
3. To accept the end-user license agreement, check the box for I accept the terms in
the License Agreement, then select Next.
4. For the Installation Scope, select one of the following options:
Install just for you: Remote Desktop will be installed in a per-user folder and
be available just for your user account. You don't need local Administrator
privileges.
Install for all users of this machine: Remote Desktop will be installed in a
per-machine folder and be available for all users. You must have local
Administrator privileges
5. Select Install.
6. Once installation has completed, select Finish.
7. If you left the box for Launch Remote Desktop when setup exits selected, the
Remote Desktop client will automatically open. Alternatively to launch the client
after installation, use the Start menu to search for and select Remote Desktop.
Subscribe to a workspace
A workspace combines all the desktops and applications that have been made available
to you by your admin. To be able to see these in the Remote Desktop client, you need to
subscribe to the workspace by following these steps:

2. The first time you subscribe to a workspace, from the Let's get started screen,
select Subscribe or Subscribe with URL. Use the tabs below for your scenario.
Subscribe
3. If you selected Subscribe, sign in with your user account when prompted, for
example user@contoso.com . After a few seconds, your workspaces should show
the desktops and applications that have been made available to you by your
admin.
 Tip
If you see the message No workspace is associated with this email

address, your admin might not have set up email discovery. Try the steps
in the Subscribe with URL tab instead.
Connect to your desktops and applications

2. Double-click one of the icons to launch a session to Azure Virtual Desktop. You
may be prompted to enter the password for your user account again, depending
on how your admin has configured Azure Virtual Desktop.
Windows Insider
If you want to help us test new builds before they're released, you should download our
Insider releases. Organizations can use the Insider releases to validate new versions for
their users before they're generally available. For more information, see Enable Windows
Insider releases.
Next steps
To learn more about the features of the Remote Desktop client for Windows, check out
Use features of the Remote Desktop client for Windows when connecting to Azure
Virtual Desktop.
 Documentation
Virtual Desktop
Desktop.
Virtual Desktop.
Privacy settings for managed apps and desktops

Information about privacy settings of the remote system when using managed apps and desktops.
Show 5 more
 Training
Learning path
Plan an Azure Virtual Desktop implementation - Training
Plan an Azure Virtual Desktop implementation
Certification
the Remote Desktop Web client
Virtual Desktop with the Remote Desktop Web client. The web client lets you access
your Azure Virtual Desktop resources directly from a web browser without needing to
install a separate client.
Prerequisites
Internet access.
A supported web browser. While any HTML5-capable web browser should work,
we officially support the following web browsers and operating systems:
Web browser Supported operating system Notes
Microsoft Edge Windows, macOS, Linux, Chrome OS Version 79 or later
Google Chrome Windows, macOS, Linux, Chrome OS Version 57 or later
Apple Safari macOS Version 11 or later
Mozilla Firefox Windows, macOS, Linux Version 55 or later
７ Note
The Remote Desktop Web client doesn't support mobile web browsers.
As of September 30, 2021, the Remote Desktop Web client no longer supports
Internet Explorer. We recommend that you use Microsoft Edge with the Remote
Desktop Web client instead. For more information, see our blog post .
Access your resources

When you sign in to the Remote Desktop Web client, you'll see your workspaces. A
workspace combines all the desktops and applications that have been made available to
you by your admin. You sign in by following these steps:
1. Open your web browser.
2. Go to one of the following URLs:
Azure environment Workspace URL
Azure cloud (most common) https://client.wvd.microsoft.com/arm/webclient/
Azure cloud (classic) https://client.wvd.microsoft.com/webclient/index.html
Azure US Gov https://rdweb.wvd.azure.us/arm/webclient/
Azure China 21Vianet https://rdweb.wvd.azure.cn/arm/webclient/
3. Sign in with your user account. Once you've signed in successfully, your
workspaces should show the desktops and applications that have been made
available to you by your admin.
4. Select one of the icons to launch a session to Azure Virtual Desktop. You may be
prompted to enter the password for your user account again, depending on how
your admin has configured Azure Virtual Desktop.
5. A prompt for Access local resources may be displayed asking you confirm which
local resources you want to be available in the remote session. Make your
selection, then select Allow.
 Tip
If you've already signed in to the web browser with a different Azure Active
Directory account than the one you want to use for Azure Virtual Desktop, you
should either sign out or use a private browser window.
Preview features
If you want to help us test new features, you should enable the preview. A new user
interface is available in preview; to learn how to try the new user interface, see Preview
user interface, and for more information about what's new, see What's new in the
Remote Desktop Web client for Azure Virtual Desktop.
Next steps
To learn more about the features of the Remote Desktop Web client, check out Use
features of the Remote Desktop Web client when connecting to Azure Virtual Desktop.
 Documentation
Virtual Desktop.

Virtual Desktop
Desktop.
Troubleshoot the Remote Desktop client for Windows - Azure Virtual Desktop
Troubleshoot issues you may experience with the Remote Desktop client for Windows when
Show 5 more
 Training
Certification
the Remote Desktop client for macOS
Virtual Desktop with the Remote Desktop client for macOS.
You can find a list of all the Remote Desktop clients at Remote Desktop clients overview.
If you want to connect to Remote Desktop Services or a remote PC instead of Azure

Virtual Desktop, see Connect to Remote Desktop Services with the Remote Desktop
client for macOS.
Prerequisites
Internet access.
A device running macOS 10.14 or later.
Download and install the Remote Desktop client from the Mac App Store .
1. Open the Microsoft Remote Desktop app on your device.
2. In the Connection Center, select +, then select Add Workspace.
3. In the Email or Workspace URL box, either enter your user account, for example
user@contoso.com , or the relevant URL from the following table. After a few
seconds, the message A workspace is associated with this URL should be
displayed.
 Tip
If you see the message No workspace is associated with this email address,
your admin might not have set up email discovery. Use one of the following
workspace URLs instead.
Azure cloud (most common) https://rdweb.wvd.microsoft.com
Azure US Gov https://rdweb.wvd.azure.us/api/arm/feeddiscovery
Azure China 21Vianet https://rdweb.wvd.azure.cn/api/arm/feeddiscovery
4. Select Add.
5. Sign in with your user account. After a few seconds, your workspaces should show
admin.
Once you've subscribed to a workspace, its content will update automatically every six
hours and each time you start the client. Resources may be added, changed, or removed
based on changes made by your admin.

1. Open the Microsoft Remote Desktop app on your device.
2. Double-click one of the icons to launch a session to Azure Virtual Desktop. You
may be prompted to enter the password for your user account again, depending
on how your admin has configured Azure Virtual Desktop.
Beta client
beta client. Organizations can use the beta client to validate new versions for their users
before they're generally available. For more information, see Test the beta client.
Next steps
To learn more about the features of the Remote Desktop client for macOS, check out
Use features of the Remote Desktop client for macOS when connecting to Azure Virtual
Desktop.
the Remote Desktop client for iOS and
iPadOS
Virtual Desktop with the Remote Desktop client for iOS and iPadOS.

client for iOS and iPadOS.
Prerequisites
Before you can access your resources, you'll need to meet the following prerequisites:
Internet access.
An iPhone running iOS 15 or later or an iPad running iPadOS 15 or later.
Download and install the Remote Desktop client from the App Store .
1. Open the RD Client app on your device.
2. In the Connection Center, tap +, then tap Add Workspace.
displayed.
 Tip
4. Tap Next.
admin.
Once you've subscribed to a workspace, its content will update automatically regularly.
Resources may be added, changed, or removed based on changes made by your admin.

2. Tap one of the icons to launch a session to Azure Virtual Desktop. You may be
Beta client
Next steps
To learn more about the features of the Remote Desktop client for iOS and iPadOS,
check out Use features of the Remote Desktop client for iOS and iPadOS when
the Remote Desktop client for Android
and Chrome OS
Virtual Desktop with the Remote Desktop client for Android and Chrome OS.

client for Android and Chrome OS.
Prerequisites
Internet access
One of the following:

Smartphone or tablet running Android 9 or later.
Chromebook running Chrome OS 53 or later. Learn more about Android
applications running in Chrome OS .
Download and install the Remote Desktop client from Google Play .
） Important
The Android client is not available on platforms built on the Android Open Source
Project (AOSP) that do not include Google Mobile Services (GMS), the client is only
available through the canonical Google Play Store.
2. In the Connection Center, tap +, then tap Add Workspace.

displayed.
 Tip
4. Tap Next.
admin.

2. Tap one of the icons to launch a session to Azure Virtual Desktop. You may be
prompted to enter the password for your user account again, and to make sure
you trust the remote PC before you connect, depending on how your admin has
configured Azure Virtual Desktop.
Beta client
Next steps
To learn more about the features of the Remote Desktop client for Android and Chrome
OS, check out Use features of the Remote Desktop client for Android and Chrome OS
when connecting to Azure Virtual Desktop.
the Remote Desktop Microsoft Store
client
Virtual Desktop with the Remote Desktop Microsoft Store client.
） Important
We're no longer updating the Microsoft Store client with new features.
For the best Azure Virtual Desktop experience that includes the latest features and
fixes, we recommend you download the Remote Desktop client for Windows
instead.

Microsoft Store client.
Prerequisites
Internet access.
A device running Windows 11 or Windows 10.
Download and install the Remote Desktop client from the Microsoft Store .
2. In the Connection Center, select + Add, then select Workspaces.
seconds, the message We found Workspaces at the following URLs should be
displayed.
 Tip
If you see the message We couldn't find any Workspaces associated with
this email address. Try providing a URL instead, your admin might not have
set up email discovery. Use one of the following workspace URLs instead.
4. Select Subscribe.
admin.

2. Select one of the icons to launch a session to Azure Virtual Desktop. You may be
Next steps
To learn more about the features of the Remote Desktop client for Windows from the
Microsoft Store, check out Use features of the Remote Desktop client for Windows
(Microsoft Store) when connecting to Azure Virtual Desktop.
 Documentation
Virtual Desktop.
Virtual Desktop
Desktop.
Use features of the Remote Desktop client for macOS - Azure Virtual Desktop
Learn how to use features of the Remote Desktop client for macOS when connecting to Azure Virtual
Desktop.
What's new in the Remote Desktop client for Windows - Azure Virtual Desktop
Show 5 more
thin clients
Thin clients are available from several partners you can use to connect to Azure Virtual
Desktop to access your desktops and applications. This article provides links to those
partners where you can read more about connecting to Azure Virtual Desktop. You can
also use a web browser on a thin client to access Azure Virtual Desktop using the web
client.
Partner thin client devices

The following partners have thin client devices that have been approved to use with
Azure Virtual Desktop. Visit their documentation to learn how to connect to Azure
Virtual Desktop with thin clients.
Partner Partner documentation Partner support
10ZiG 10ZiG client documentation 10ZiG support
Dell Dell client documentation Dell support
HP HP client documentation HP support
IGEL IGEL client documentation IGEL support
NComputing NComputing client documentation NComputing support
Stratodesk Stratodesk client documentation Stratodesk support
Next steps
Learn more about Remote Desktop clients at Remote Desktop clients overview.
Use features of the Remote Desktop
client for Windows when connecting to
Once you've connected to Azure Virtual Desktop using the Remote Desktop client, it's
important to know how to use the features. This article shows you how to use the
features available in the Remote Desktop client for Windows. If you want to learn how to
connect to Azure Virtual Desktop, see Connect to Azure Virtual Desktop with the
Remote Desktop client for Windows.
For more information about the differences between the clients, see Compare the
Remote Desktop clients.
７ Note
Your admin can choose to override some of these settings in Azure Virtual Desktop,
such as being able to copy and paste between your local device and your remote
session. If some of these settings are disabled, please contact your admin.
Refresh or unsubscribe from a workspace or

see its details
To refresh or unsubscribe from a workspace or see its details:
1. Open the Remote Desktop application on your device.
2. Select the three dots to the right-hand side of the name of a workspace where
you'll see a menu with options for Details, Refresh, and Unsubscribe.
Details shows you details about the workspace, such as:

The name of the workspace.
The URL and username used to subscribe.
The number of desktops and apps.
The date and time of the last refresh.
The status of the last refresh.
Refresh makes sure you have the latest desktops and apps and their settings
provided by your admin.
Unsubscribe removes the workspace from the Remote Desktop client.
User accounts
Manage user accounts

You can save a user account and associate it with workspaces to simplify the connection
sequence, as the sign-in credentials will be used automatically. You can also edit a saved
account or remove accounts you no longer want to use.
User accounts are stored and managed in Credential Manager in Windows as a generic
credential.
To save a user account:
2. Double-click one of the icons to launch a session to Azure Virtual Desktop. If

you're prompted to enter the password for your user account again, enter the
password and check the box Remember me, then select OK.
To edit or remove a saved user account:
1. Open Credential Manager from the Control Panel. You can also open Credential
Manager by searching the Start menu.
2. Select Windows Credentials.
3. Under Generic Credentials, find your saved user account and expand its details. It
will begin with RDPClient.
4. To edit the user account, select Edit. You can update the username and password.
Once you're done, select Save.
5. To remove the user account, select Remove and confirm that you want to delete it.
Display preferences
Display settings for each remote desktop

If you want to use different display settings to those specified by your admin, you can
configure custom settings.
2. Right-click the name of a desktop or app, for example SessionDesktop, then select
Settings.
3. Toggle Use default settings to off.
4. On the Display tab, you can select from the following options:
Display Description
configuration
All displays Automatically use all displays for the desktop. If you have multiple
displays, all of them will be used.
For information on limits, see Compare the features of the Remote

Desktop clients.
Single display Only a single display will be used for the remote desktop.
Select displays Only select displays will be used for the remote desktop.
Each display configuration in the table above has its own settings. Use the
following table to understand each setting:
Setting Display Description

configurations
Single All displays

Only use a single display when running in windows mode,
display Select displays rather than full screen.
when in
windowed
mode
Start in Single display The desktop will be displayed full screen.

full screen
Fit session All displays

When you resize the window, the scaling of the desktop will
to Single display
automatically adjust to fit the new window size. The
window Select displays resolution will stay the same.
Update Single display When you resize the window, the resolution of the desktop
the will automatically change to match.
resolution
on resize If this is disabled, a new option for Resolution is displayed
where you can select from a pre-defined list of resolutions.
Setting Display Description
configurations
Choose Select displays Select which displays you want to use. All selected displays
which must be next to each other.
display to
use for
this
session
Maximize Select displays The remote desktop will show full screen on the current
to current display(s) the window is on, even if this isn't the display
displays selected in the settings. If this is off, the remote desktop will
show full screen the same display(s) regardless of the current
display the window is on. If your window overlaps multiple
displays, those displays will be used when maximizing the
remote desktop.
Input methods
You can use touch input, or a built-in or external PC keyboard, trackpad and mouse to
control desktops or apps.
Use touch gestures and mouse modes in a remote session

You can use touch gestures to replicate mouse actions in your remote session. If you
connect to Windows 10 or later with Azure Virtual Desktop, native Windows touch and
multi-touch gestures are supported.
The following table shows which mouse operations map to which gestures:
Mouse operation Gesture
Left-click Tap with one finger
Right-click Tap and hold with one finger
Left-click and drag Double-tap and hold with one finger, then drag
Right-click Tap with two fingers
Right-click and drag Double-tap and hold with two fingers, then drag
Mouse wheel Tap and hold with two fingers, then drag up or down
Zoom With two fingers, pinch to zoom out and move fingers apart to zoom in
Keyboard
There are several keyboard shortcuts you can use to help use some of the features.
Some of these are for controlling how the Remote Desktop client displays the session.
These are:
Key Description
combination
CTRL + ALT + Activates the connection bar when in full-screen mode and the connection
HOME bar isn't pinned.
CTRL + ALT + Switches the client between full-screen mode and window mode.
PAUSE
Most common Windows keyboard shortcuts, such as CTRL + C for copy and CTRL + Z
for undo, are the same when using Azure Virtual Desktop. There are some keyboard
shortcuts that are different so Windows knows when to use them in Azure Virtual
Desktop or on your local device. These are:
Windows Azure Virtual Description

shortcut Desktop shortcut
CTRL + ALT CTRL + ALT + END Shows the Windows Security dialog box.
+ DELETE
ALT + TAB ALT + PAGE UP Switches between programs from left to right.
ALT + ALT + PAGE DOWN Switches between programs from right to left.
SHIFT +
TAB
WINDOWS ALT + HOME Shows the Start menu.

key, or
CTRL + ESC
ALT + ALT + DELETE Shows the system menu.

SPACE BAR
PRINT CTRL + ALT + + Takes a snapshot of the entire remote session, and places
SCREEN
(plus sign) it in the clipboard.
ALT + CTRL + ALT + - Takes a snapshot of the active window in the remote
PRINT (minus sign) session, and places it in the clipboard.
SCREEN
７ Note
Keyboard shortcuts will not work when using Remote Desktop or RemoteApp
sessions that are nested.
Keyboard language
By default, remote desktops and apps will use the same keyboard language, also known
as locale, as your Windows PC. For example, if your Windows PC uses en-GB for English
(United Kingdom), that will also be used by Windows in the remote session.
You can manually set which keyboard language to use in the remote session by
following the steps at Managing display language settings in Windows . You might
need to close and restart the application you're currently using for the keyboard
changes to take effect.
Redirections
Folder redirection
The Remote Desktop client can make local folders available in your remote session. This
is known as folder redirection. This means you can open files from and save files to your
Windows PC with your remote session. Redirected folders appear as a network drive in
Windows Explorer.
Folder redirection can't be configured using the Remote Desktop client for Windows.
This behavior is configured by your admin in Azure Virtual Desktop. By default, all local
drives are redirected to a remote session.
Redirect devices, audio, and clipboard

The Remote Desktop client can make your local clipboard and local devices available in
your remote session where you can copy and paste text, images, and files. The audio
from the remote session can also be redirected to your local device. However,
redirection can't be configured using the Remote Desktop client for Windows. This
behavior is configured by your admin in Azure Virtual Desktop. Here's a list of some of
the devices and resources that can be redirected. For the full list, see Compare the
features of the Remote Desktop clients when connecting to Azure Virtual Desktop.
Printers
USB devices
Audio output
Smart cards
Clipboard
Microphones
Cameras
Update the client

By default, you'll be notified whenever a new version of the client is available as long as
your admin hasn't disabled notifications. The notification will appear in the client and
the Windows Action Center. To update your client, just select the notification.
You can also manually search for new updates for the client:
2. Select the three dots at the top right-hand corner to show the menu, then select
About. The client will automatically search for updates.
3. If there's an update available, tap Install update to update the client. If the client is
already up to date, you'll see a green check box, and the message You're up to
date.
App display modes

You can configure the Remote Desktop client to be displayed in light or dark mode, or
match the mode of your system:
2. Select Settings.
3. Under App mode, select Light, Dark, or Use System Mode. The change is applied
instantly.
Views
You can view your remote desktops and apps as either a tile view (default) or list view:
2. If you want to switch to List view, select Tile, then select List view.
3. If you want to switch to Tile view, select List, then select Tile view.
Enable Windows Insider releases
Insider releases. Organizations can use the Insider releases to validate new versions for
their users before they're generally available.
７ Note
Insider releases shouldn't be used in production.
Insider releases are made available in the Remote Desktop client once you've configured
the client to use Insider releases. To configure the client to use Insider releases:
1. Add the following registry key and value:
Key: HKLM\Software\Microsoft\MSRDC\Policies
Type: REG_SZ
Name: ReleaseRing
Data: insider
You can do this with PowerShell. On your local device, open PowerShell as an
administrator and run the following commands:
PowerShell
New-Item -Path "HKLM:\SOFTWARE\Microsoft\MSRDC\Policies" -Force
New-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\MSRDC\Policies" -Name

ReleaseRing -PropertyType String -Value insider -Force
2. Restart your local device.
3. Open the Remote Desktop client. The title in the top left-hand corner should be
Remote Desktop (Insider):
If you already have configured the Remote Desktop client to use Insider releases, you
can check for updates to ensure you have the latest Insider release by checking for
updates in the normal way. For more information, see Update the client.
Admin management
Enterprise deployment
To deploy the Remote Desktop client in an enterprise, you can use msiexec to install the
MSI file. You can install the client per-device or per-user by running the relevant
command from Command Prompt as an administrator:
Per-device installation:
msiexec /i <path to the MSI> /qn ALLUSERS=1
Per-user installation:
msiexec /i <path to the MSI> /qn ALLUSERS=2 MSIINSTALLPERUSER=1
Update behavior
You can control notifications about updates and when updates are installed. The update
behavior of the client depends on two factors:
Whether the app is installed for only the current user or for all users on the
machine
The value of the following registry key:

Key: HKLM\Software\Microsoft\MSRDC\Policies
Type: REG_DWORD
Name: AutomaticUpdates
The Remote Desktop client offers three ways to update:
Notification-based updates, where the client shows the user a notification in the
client UI or a pop-up message in the taskbar. The user can choose to update the
client by selecting the notification.
Silent on-close updates, where the client automatically updates after the user has
closed the Remote Desktop client.
Silent background updates, where a background process checks for updates a few
times a day and will update the client if a new update is available.
To avoid interrupting users, silent updates won't happen while users have the client
open, have a remote connection active, or if you've disabled automatic updates. If the
client is running while a silent background update occurs, the client will show a
notification to let users know an update is available.
You can set the AutomaticUpdates registry key to one of the following values:
Value Update behavior (per user Update behavior (per machine installation)
installation)
0 Disable notifications and turn off Disable notifications and turn off auto-update.
auto-update.
1 Notification-based updates. Notification-based updates.
2 Notification-based updates when Notification-based updates. No support for

(default) the app is running. Otherwise, silent update mechanisms, as users may not
silent on-close and background have administrator access rights on the client
updates. device.
URI to subscribe to a workspace

The Remote Desktop client for Windows supports the ms-rd and ms-avd (preview)
Uniform Resource Identifier (URI) schemes. This enables you to invoke the Remote
Desktop client with specific commands, parameters, and values for use with Azure
Virtual Desktop. For example, you can subscribe to a workspace or connect to a
particular desktop or Remote App.
For more information and the available commands, see Uniform Resource Identifier
schemes with the Remote Desktop client for Azure Virtual Desktop
Azure Virtual Desktop (HostApp)

The Azure Virtual Desktop (HostApp) is a platform component containing a set of
predefined user interfaces and APIs that Azure Virtual Desktop developers can use to
deploy and manage Remote Desktop connections to their Azure Virtual Desktop
resources. If this application is required on a device for another application to work
correctly, it will automatically be downloaded by the other application. There should be
no need for user interaction.
The purpose of the Azure Virtual Desktop (HostApp) is to provide core functionality to
other client apps in the Microsoft Store. This is known as the Hosted App Model. For
more information, see Hosted App Model .
Provide feedback
If you want to provide feedback to us on the Remote Desktop client for Windows, you
can do so by selecting the button that looks like a smiley face emoji in the client app, as
shown in the following image. This will open the Feedback Hub.
To best help you, we need you to give us as detailed information as possible. Along with
a detailed description, you can include screenshots, attach a file, or make a recording.
For more tips about how to provide helpful feedback, see Feedback.
Next steps
If you're having trouble with the Remote Desktop client, see Troubleshoot the Remote
Desktop client.
 Documentation
Desktop.
Use features of the Remote Desktop client for macOS - Azure Virtual Desktop
Learn how to use features of the Remote Desktop client for macOS when connecting to Azure Virtual
Desktop.
Show 5 more
Web client when connecting to Azure
Virtual Desktop
features available in the Remote Desktop Web client. If you want to learn how to
Remote Desktop Web client.
７ Note
Display preferences
A remote desktop will automatically fit the size of the browser window. If you resize the
browser window, the remote desktop will resize with it. You can also enter fullscreen by
selecting fullscreen (the diagonal arrows icon) on the taskbar.
If you use a high-DPI display, the Remote Desktop Web client supports using native
display resolution during remote sessions. In sessions running on a high-DPI display,
native resolution can provide higher-fidelity graphics and improved text clarity.
７ Note
Enabling native display resolution with a high-DPI display may cause increased CPU
or network usage.
Native resolution is set to off by default. To turn on native resolution:

1. Sign in to the Remote Desktop Web client, then select Settings on the taskbar.
2. Set Enable native display resolution to On.
Preview user interface (preview)

A new user interface is available in preview for you to try. To enable the new user
interface:
1. Sign in to the Remote Desktop Web client.
2. Toggle Try the new client (Preview) to On. To revert to the original user interface,
toggle this to Off.
Grid view and list view (preview)

You can change the view of remote resources assigned to you between grid view
(default) and list view. To change between grid view and list view:
1. Sign in to the Remote Desktop Web client and make sure you have toggled Try the
new client (Preview) to On.
2. In the top-right hand corner, select Grid View icon or the List View icon. The
change will take effect immediately.
Light mode and dark mode (preview)

You can change between light mode (default) and dark mode. To change between light
mode and dark mode:
new client (Preview) to On, then select Settings on the taskbar.
2. Toggle Dark Mode to On to use dark mode, or Off to use light mode. The change
will take effect immediately.
Input methods
You can use a built-in or external PC keyboard, trackpad and mouse to control desktops
or apps.
Keyboard
There are several keyboard shortcuts you can use to help use some of the features. Most
common Windows keyboard shortcuts, such as CTRL + C for copy and CTRL + Z for
undo, are the same when using Azure Virtual Desktop. There are some keyboard
Windows Azure Virtual Desktop shortcut Description

shortcut
CTRL + ALT + CTRL + ALT + END (Windows) Shows the Windows Security dialog
DELETE box.
CTRL + ALT + FN + Control + Option + Delete Shows the Windows Security dialog
DELETE (macOS) box.
Windows ALT + F3 Sends the Windows key to the remote

session.
ALT + TAB ALT + PAGE UP Switches between programs from left

to right.
ALT + SHIFT + ALT + PAGE DOWN Switches between programs from right
TAB to left.
７ Note
You can copy and paste text only. Files can't be copied or pasted to and from the
web client. Additionally, you can only use CTRL + C and CTRL + V to copy and paste
text.
Input Method Editor
The web client supports Input Method Editor (IME) in the remote session. Before you
can use the IME, you must install the language pack for the keyboard you want to use in
the remote session must be installed on your session host by your admin. To learn more
about setting up language packs in the remote session, see Add language packs to a
Windows 10 multi-session image.
To enable IME input using the web client:
2. Set Enable Input Method Editor to On.

3. In the drop-down menu, select the keyboard you want to use in a remote session.
4. Connect to a remote session.
The web client will suppress the local IME window when you're focused on the remote
session. If you change the IME settings after you've already connected to the remote
session, the setting changes won't have any effect.
７ Note
The web client doesn't support IME input while using a private browsing window.
If the language pack isn't installed on the session host, the keyboard in the remote
session will default to English (United States).
Redirections
You can allow the remote computer to access to files, printers, and the clipboard on
your local device. When you connect to a remote session, you'll be prompted whether
you want to allow access to local resources.
Transfer files
To transfer files between your local device and your remote session:
1. Sign in to the Remote Desktop Web client and launch a remote session.
2. For the prompt Access local resources, check the box for File transfer, then select
Allow.
3. Once you're remote session has started, an extra icon will appear in the Remote
Desktop Web client taskbar for Upload new file (the upwards arrow icon).
Selecting this will open a file explorer window on your local device.
4. Browse to and select files you want to upload to the remote session. You can select
multiple files by holding down the CTRL key on your keyboard for Windows, or the
Command key for macOS, then select Open. There is a file size limit of 255MB.
5. In your remote session, open File Explorer, then select This PC.
6. You'll see a redirected drive called Remote Desktop Virtual Drive on

RDWebClient. Inside this drive are two folders: Uploads and Downloads. Uploads
contains the files you uploaded through the Remote Desktop Web client.
7. To transfer files from your remote session to your local device, copy and paste files
to the Downloads folder. Before the paste can complete, the Remote Desktop Web
client will prompt you Are you sure you want to download N file(s)?. Select
Confirm. Your browser will download the files in its normal way.
If you don't want to see this prompt every time you download files from the
current browser, check the box for Don’t ask me again on this browser before
confirming.
） Important
We recommend using Copy rather than Cut when transferring files from your
remote session to your local device as an issue with the network connection
can cause the files to be lost.
Uploaded files are available in a remote session until you sign out of the
Remote Desktop Web client.
Clipboard
To use the clipboard between your local device and your remote session:
2. For the prompt Access local resources, check the box for Clipboard, then select
Allow.
The Remote Desktop Web client supports copying and pasting text only. Files can't
be copied or pasted to and from the web client. To transfer files, see Transfer files.
Printer
You can enable the Remote Desktop Virtual Printer in your remote session. When you
print to this printer, a PDF file of your print job will be generated for you to download
and print on your local device. To enable the Remote Desktop Virtual Printer:
2. For the prompt Access local resources, check the box for Printer, then select
Allow.
3. Start the printing process as you would normally for the app you want to print
from.
4. When prompted to choose a printer, select Remote Desktop Virtual Printer.
5. If you wish, you can set the orientation and paper size. When you're ready, select
Print. A PDF file of your print job will be generated and your browser will
download the files in its normal way. You can choose to either open the PDF and
print its contents to your local printer or save it to your PC for later use.
Launch remote session with another Remote

Desktop client
If you have another Remote Desktop client installed, you can download an RDP file
instead of using the browser window for a remote session. To configure the Remote
Desktop Web client to download RDP files:
2. For Resources Launch Method, select Download the RDP file.
3. Select the resource you want to open (for example, Excel). Your browser will
download the RDP in its normal way.
4. Open the downloaded RDP file in your Remote Desktop client to launch a remote
session.
Reset user settings (preview)

If you want to reset your user settings back to the default, you can do this in the web
client for the current browser. To reset user settings:
new client (Preview) to On, then select Settings on the taskbar.
2. Select Reset user settings. You'll need to confirm that you want reset the web
client settings to default.
Provide feedback
If you want to provide feedback to us on the Remote Desktop Web client, you can do so
in the Web client:
1. Sign in to the Remote Desktop Web client, then select the three dots (...) on the
taskbar to show the menu.
2. Select Feedback to open the Azure Virtual Desktop Feedback page.
Next steps
Desktop client.
 Documentation
Virtual Desktop.
Chrome OS - Azure Virtual Desktop
Chrome OS.
Show 5 more
client for macOS when connecting to
features available in the Remote Desktop client for macOS. If you want to learn how to
Remote Desktop client for macOS.
７ Note
Some of the settings in this article can be overridden by your admin, such as being
able to copy and paste between your local device and your remote session. If some
of these settings are disabled, please contact your admin.
Edit, refresh, or delete a workspace

To edit, refresh or delete a workspace:
1. Open the Microsoft Remote Desktop application on your device, then select
Workspaces.
2. Right-click the name of a workspace or hover your mouse cursor over it and you'll
see a menu with options for Edit, Refresh, and Delete.
Edit allows you to specify a user account to use each time you connect to the
workspace without having to enter the account each time. To learn more, see
Manage user accounts.
Delete removes the workspace from the Remote Desktop client.
User accounts
Add user credentials to a workspace

sequence, as the sign-in credentials will be used automatically.
Workspaces.
2. Right-click the name of a workspace, then select Edit.
3. For User account, select Add User Account... to add a new account, or select an
account you've previously added.
4. If you selected Add User Account..., enter a username, password, and optionally a
friendly name, then select Add.
5. Select Save.

sequence, as the sign-in credentials will be used automatically. You can also remove
accounts you no longer want to use.
1. Open the Microsoft Remote Desktop application on your device.
2. From the macOS menu bar, select Microsoft Remote Desktop, then select
Preferences.
3. Select the User Accounts tab, then the + (plus) icon.
4. Enter a username, password, and optionally a friendly name, then select Add. You
can then add this account to a workspace by following the steps in Add user
credentials to a workspace.
5. Close Preferences.
To remove an account you no longer want to use:

Preferences.
3. Select the User Accounts tab, then select the account you want to remove.
4. Select the - (minus) icon, then confirm you want to delete the user account.
5. Close Preferences.
Display preferences
Add, remove, or restore display resolutions

To add, remove or restore display resolutions:
Preferences.
3. Select the Resolutions tab.
4. To add a custom resolution, select the + (plus) icon and enter in the width and
height in pixels, then select Add.
5. To remove a resolution, select the resolution you want to remove, then select the -
(minus) icon. Confirm you want to delete the resolution by selecting Delete.
6. To restore default resolutions, select Restore Defaults.
Display settings for each remote desktop

configure custom settings.
Workspaces.
2. Right-click the name of a desktop, for example SessionDesktop, then select Edit.
3. Check the box for Use custom settings.
4. On the Display tab, you can select from the following options:
Option Description
Resolution Select the resolution to use for the desktop. You can select from a
predefined list, or add custom resolutions.
Use all monitors Automatically use all monitors for the desktop. If you have multiple
monitors, all of them will be used.
For information on limits, see Compare the features of the Remote Desktop
clients.
Start session in full The desktop will be displayed full screen, rather than windowed.
screen
Fit session to When you resize the window, the scaling of the desktop will automatically
window adjust to fit the new window size. The resolution will stay the same.
Color quality The quality and number of colors used. Higher quality will use more
bandwidth.
Optimize for Retina Scale the desktop to match the scaling used on the Mac client. This will use
displays four times more bandwidth.
Update the session When you resize the window, the resolution of the desktop will
resolution on resize automatically change to match.
Displays have separate spaces

macOS allows you to create extra desktops, called Spaces, where only the Windows that
are in that space are visible. This is set in macOS System Preferences > Mission Control
> Displays have separate Spaces. If this is disabled, macOS will use the same desktop
across all monitors.
When separate Spaces are disabled, if the Remote Desktop client has Start session in
full screen enabled, but Use all monitors disabled, only one monitor will be used and
the others will be blank. Either enable Use all monitors so the remote desktop is
displayed on all monitors, or enable Displays have separate spaces in Mission Control
so that the remote desktop will be displayed full screen on one monitor, but others will
show the macOS desktop.
Sidecar
You can use Apple Sidecar during a remote session, allowing you to extend a Mac
desktop display using an iPad as an extra monitor.
Input methods
You can use a built-in or external Mac keyboard, trackpad and mouse to control
desktops or apps.
Keyboard
Mac and Windows keyboard layouts differ slightly - for example, the Command key on a
Mac keyboard equals the Windows key on a Windows keyboard. To help with the
differences this makes when using keyboard shortcuts, the Remote Desktop client
automatically maps common shortcuts found in macOS so they'll work in Windows.
These are:
Key combination Function
CMD + C Copy
CMD + X Cut
CMD + V Paste
CMD + A Select all
CMD + Z Undo
CMD + F Find
In addition, the Alt key to the right of the space bar on a Mac keyboard equals the
Alt Gr in Windows.
Keyboard language
as locale, as your Mac. For example, if your Mac uses en-GB for English (United
Kingdom), that will also be used by Windows in the remote session.
There are some Mac-specific layouts or custom layouts for which an exact match may
not be available on the version of Windows you're connecting to. Your Mac keyboard
will be matched to the best available on the remote session.
If your keyboard layout is set to a variation of a language, such as Canadian-French, and

if the remote session can't map you to that exact variation, it will map the closest
available language instead. For example, if you chose the Canadian-French locale and it
wasn't available, the closest language would be French. However, some of the Mac
keyboard shortcuts you're used to using on your Mac may not work as expected in the
remote session.
There are some scenarios where characters in the remote session don't match the
characters you typed on the Mac keyboard:
Using a keyboard that the remote session doesn't recognize. When Azure Virtual
Desktop doesn't recognize the keyboard, it defaults to the language last used with
the remote PC.
Connecting to a previously disconnected session from Azure Virtual Desktop where
that session uses a different keyboard language than the language you're currently
trying to use.
Needing to switch keyboard modes between unicode and scancode. To learn
more, see Keyboard modes.
Keyboard modes
There are two different modes you can use that control how keyboard input is
interpreted in a remote session: Scancode and Unicode.
With Scancode, user input is redirected by sending key press up and down information
to the remote session. Each key is identified by its physical position on the keyboard and
uses the keyboard layout of the remote session, not the keyboard of the local device.
For example, scancode 31 is the key next to Caps Lock . On a US keyboard this key would
produce the character "A", while on a French keyboard this key would produce the
character "Q".
With Unicode, user input is redirected by sending each character to the remote session.
When a key is pressed, the locale of the user is used to translate this input to a
character. This can be as simple as the character "a" by simply pressing the "a" key, but
it can enable an Input Method Editor (IME), allowing you to input multiple keystrokes to
create more complex characters, such as for Chinese and Japanese input sources. Below
are some examples of when to use each mode.
When to use Scancode:
Dealing with characters that aren't printable, such as Arrow Up or shortcut

combinations.
Certain applications that don't accept Unicode input for characters such as: Hyper-
V VMConnect (for example, no way to input a BitLocker password), VMware
Remote Console, all applications written using the Qt framework (for example R
Studio, TortoiseHg, QtCreator).
Applications that utilize scancode input for actions, such as Space bar to
check/uncheck a checkbox, or individual keys as shortcuts, for example
applications in browser.
When to use Unicode:
To avoid a mismatch in expectations. A user who expects the keyboard to behave

like a Mac keyboard and not like a PC keyboard can run into issues where Mac and
PC have differences for the same locale/region layout.
When the keyboard layout used on the client might not be available on the server.
To switch between keyboard modes:
2. From the macOS menu bar, select Connections, then select Keyboard Mode.
3. Choose Scancode or Unicode.
Alternatively, you can use the following keyboard shortcut to select each mode:
Scancode: Ctrl + Command + K
Unicode: Ctrl + Command + U
Input Method Editor
The Remote Desktop client supports Input Method Editor (IME) in a remote session for
input sources. The local macOS IME experience will be accessible in the remote session.
） Important
For an IME to work, the input mode needs to be in Unicode Mode. To learn more,
see Keyboard modes.
Mouse and trackpad

You can use a mouse or trackpad with the Remote Desktop client. In order to use the
right-click or secondary-click, you may need to configure macOS to enable right-click, or
you can plug in a standard PC two-button USB mouse. To enable right-click in macOS:
1. Open System Preferences.
2. For the Apple Magic Mouse, select Mouse, then check the box for Secondary click.
3. For the Apple Magic Trackpad of MacBook Trackpad, select Trackpad, then check
the box for Secondary click.
Redirections
Folder redirection
The Remote Desktop client enables you to make local folders available in your remote
session. This is known as folder redirection. This means you can open files from and save
files to your Mac with your remote session. Folders can also be redirected as read-only.
Redirected folders appear in the remote session as a network drive in Windows Explorer.
All remote sessions

To enable folder redirection for all remote desktops:
Preferences.
3. Select the General tab, then for If folder redirection is enabled for RDP files or
managed resources, redirect:, select Choose Folder....
4. Navigate to the folder you want to be available in all your remote desktop
sessions, then select Choose.
5. Close the Preferences window. Optionally, if you want to make this folder available
as read-only, check the box before closing the window.
Each remote resource
To enable folder redirection for each remote desktop individually:
If you want to use different display settings to those specified by your admin for the
workspace, you can configure custom settings.
Workspaces.
4. On the Folders tab, check the box Redirect folders, then select the + (plus) icon.
5. Navigate to the folder you want to be available when accessing this remote
resource, then select Open. You can add multiple folders by repeating the previous
step and this step.
6. Select Save. Optionally, if you want to make this folder available as read-only,
check the box, then select Save.
Redirect devices, audio, and clipboard

The Remote Desktop client can make your local clipboard and local devices available in
your remote desktop where you can copy and paste text, images, and files. You can also
redirect the audio from the remote desktop to your local device. You can redirect:
Printers
Smart cards
Clipboard
Microphones
Cameras
To enable redirection of devices, audio and the clipboard:
Workspaces.
4. On the Devices & Audio tab, check the box for each device you want to use in the
remote desktop.
5. Select whether you want to play sound On this computer, On the remote PC, or
Never.
6. Select Save.
Microsoft Teams optimizations
You can use Microsoft Teams on Azure Virtual Desktop to chat, collaborate, make calls,
and join meetings. With media optimization, the Remote Desktop client handles audio
and video locally for Teams calls and meetings. For more information, see Use Microsoft
Starting with version 10.7.7 of the Remote Desktop client for macOS, optimizations for
Teams is enabled by default. If you need to enable optimizations for Microsoft Teams:
Preferences.
3. Select the General tab, then check the box Enable optimizations for Microsoft
Teams.
General app settings

To set other general settings of the Remote Desktop app to use with Azure Virtual
Desktop:
Preferences.
3. Select the General tab. You can change the following settings:
Setting Value Description
Show PC Check On or Show thumbnails of remote sessions.

thumbnails Off
Help improve Check On or Send anonymous data to Microsoft.

Remote Desktop Off
Use Mac shortcuts Check On or Use these shortcuts in remote sessions.

for copy, cut, paste Off
and select all, undo,
and find
Use system proxy Check On or Use the proxy specified in macOS network
configuration Off settings.
Graphics Select from As the interpolation level is increased, most text

interpolation level Automatic, and graphics appear smoother, but rendering
None, Low, performance will decrease (if hardware
Medium, or acceleration is disabled).
High
Use hardware Check On or Use graphics hardware to render graphics.

acceleration when Off
possible
Admin link to subscribe to a workspace

The Remote Desktop client for macOS supports the ms-rd Uniform Resource Identifier
(URI) scheme. This enables you to use a link that users can help to automatically
subscribe to a workspace, rather than them having to manually add the workspace in
the Remote Desktop client.
To subscribe to a workspace with a link:
1. Open the following link in a web browser: ms-rd:subscribe?

url=https://rdweb.wvd.microsoft.com .
2. If you see the prompt This site is trying to open Microsoft Remote Desktop.app,
select Open. The Microsoft Remote Desktop application should open and
automatically show a sign-in prompt.
3. Enter your user account, then select Sign in. After a few seconds, your workspaces
should show the desktops and applications that have been made available to you
by your admin.
Test the beta client

before they're generally available.
７ Note
The beta client shouldn't be used in production.

You can download the beta client for macOS from our preview channel on AppCenter .
You don't need to create an account or sign into AppCenter to download the beta client.
If you already have the beta client, you can check for updates to ensure you have the
latest version by following these steps:
2. From the macOS menu bar, select Microsoft Remote Desktop, then select Check
for updates.
Provide feedback
If you want to provide feedback to us on the Remote Desktop client for macOS, you can
do so in the app:
2. From the macOS menu bar, select Help, then select Submit Feedback.
Next steps
Desktop client.
 Documentation
Virtual Desktop
Chrome OS.
(Microsoft Store).


Show 5 more
client for iOS and iPadOS when
connecting to Azure Virtual Desktop
features available in the Remote Desktop client for iOS and iPadOS. If you want to learn
how to connect to Azure Virtual Desktop, see Connect to Azure Virtual Desktop with the
Remote Desktop client for iOS and iPadOS.
７ Note

1. Open the RD Client application on your device, then tap Workspaces.
2. Tap and hold the name of a workspace and you'll see a menu with options for Edit,
Refresh, and Delete. You can also pull down to refresh all workspaces.
User accounts
Learn how to add user credentials to a workspace and manage them.

1. Open the RD Client application on your device, then tap Workspaces.
2. Tap and hold the name of a workspace, then select Edit.
3. Tap User account, then select Add User Account to add a new account, or select
an account you've previously added.
4. If you selected Add User Account, enter a username, password, and optionally a
friendly name, then tap the back arrow (<).
5. Tap the X mark to return to Workspaces.

1. Open the RD Client application on your device.
2. In the top left-hand corner, tap the menu icon (the circle with three dots inside),
then tap Settings.
3. Tap User Accounts, then tap Add User Account.
4. Enter a username, password, and optionally a friendly name, then tap the back
arrow (<). You can then add this account to a workspace by following the steps in
Add user credentials to a workspace.
5. Tap the back arrow (<), then tap the X mark.
then tap Settings.
3. Tap User Accounts, then select the account you want to remove.
4. Tap Delete. The account will be removed immediately.
Display preferences
Learn how to set display preferences, such as orientation and resolution.
Set orientation
You can set the orientation of the Remote Desktop client to landscape, portrait, or auto-
adjust, where it will match the orientation of your device. Auto-adjust is supported when
your remote session is running Windows 10 and Windows Server 2012 R2 or later. The
window will maintain the same scaling and update the resolution to match the new
orientation. This setting applies to all workspaces.
To set the orientation:
then tap Settings.
3. Tap Display, then tap Orientation.
4. Tap your preference from Auto-adjust, Lock to Landscape or Lock to Portrait.
5. You can also set Use Home Indicator Area. Toggling this on will show graphics
from the remote session in the area at the bottom of the screen occupied by the
Home indicator. This setting only applies in landscape orientation.
Set display resolution

You can choose the resolution for your remote session from a predefined list. This
setting applies to all workspaces.
７ Note
Changes to the display resolution only take effect for new connections. For current
connections, you'll need to disconnect and reconnect from a remote session
To set the resolution:
then tap Settings.
3. Tap Display.
4. Tap a resolution from the list.
Use full display or home indicator area

On iPadOS, you can set Use Full Display. Toggling this on will use the full display of your
device, but will result in some content from the remote session being obscured, such as
graphics n the rounded corners of the screen.
then tap Settings.
3. Tap Display.
4. Toggle Use Full Display.
On iOS, you can set Use Home Indicator Area. Toggling this on will show graphics from
the remote session in the area at the bottom of the screen occupied by the Home
indicator. This setting only applies in landscape orientation. For more information about
display orientation, see Set orientation. To set Use Home Indicator Area:
then tap Settings.
3. Tap Display.
4. Toggle Use Home Indicator Area.

Connection bar and session overview menu

When you've connected to Azure Virtual Desktop, you'll see a bar at the top, which is
called the connection bar. This gives you quick access to a zoom control, represented
by a magnifying glass icon, and the ability to toggle between showing and hiding the
on-screen keyboard. You can move the connection bar around the top and side edges
of the display by tapping and dragging it to where you want it. If you tap and hold the
zoom control, you can choose the percentage by which to zoom by using the slider. If
you use a keyboard, you can also show and hide the connection bar by pressing Shift +
CMD + Space bar .
The middle icon in the connection bar is of the Remote Desktop logo. If you tap this, it
shows the session overview screen. The session overview screen enables you to:
Go to the Connection Center using the Home icon.

Switch inputs between touch and the mouse pointer (when not using a separate
mouse).
Switch between active desktops and apps.
Disconnect all active sessions.
Pressing Tab on a keyboard will switch between the PCs and Apps tab in the session
overview menu. You can also use arrow keys to navigate and select an active session to
open.
You can return back to an active session from the Connection Center using the Return
Arrow button found in the bottom right corner of the Connection Center.
Input methods
The Remote Desktop client supports native touch gestures, keyboard, mouse, and
trackpad.

You can use touch gestures to replicate mouse actions in your remote session. Two
mouse modes are available:
Direct touch: where you tap on the screen is the equivalent to clicking a mouse in
that position. The mouse pointer isn't shown on screen.
Mouse pointer: The mouse pointer is shown on screen. When you tap the screen
and move your finger, the mouse pointer will move.
If you connect to Windows 10 or later with Azure Virtual Desktop, native Windows touch
and multi-touch gestures are supported in direct touch mode.
The following table shows which mouse operations map to which gestures in specific
mouse modes:
Mouse Mouse Gesture

mode operation
Direct touch Left-click Tap with one finger
Direct touch Right-click Tap and hold with one finger
Mouse Left-click Tap with one finger

pointer
Mouse Left-click and Double-tap and hold with one finger, then drag
pointer drag
Mouse Right-click Tap with two fingers, or tap and hold with one finger
pointer
Mouse Right-click drag Double-tap and hold with two fingers, then drag
pointer
Mouse Mouse wheel Tap and hold with two fingers, then drag up or down
pointer
Mouse Zoom With two fingers, pinch to zoom out and spread fingers apart to
pointer zoom in
Keyboard
You can use familiar keyboard shortcuts when using a keyboard with your iPad or
iPhone and Azure Virtual Desktop. Mac and Windows keyboard layouts differ slightly -
for example, the Command key on a Mac keyboard equals the Windows key on a Windows
keyboard. To help with the differences this makes when using keyboard shortcuts, the
Remote Desktop client automatically maps common shortcuts found in iOS and iPadOS
so they'll work in Windows. These are:
CMD + C Copy
CMD + X Cut
CMD + V Paste
CMD + A Select all
CMD + Z Undo
CMD + F Find
CMD + + Zoom in
CMD + - Zoom out
In addition, the Alt key to the right of the space bar on a Mac keyboard equals the
Alt Gr in Windows.
Mouse and trackpad

You can use a mouse or trackpad with the Remote Desktop client. However, support for
these devices depends on whether you're using iOS or iPadOS. iPadOS natively supports
a mouse and trackpad as an input method, whereas support can only be enabled in iOS
with AssistiveTouch. For more information, see Connect a Bluetooth mouse or trackpad
to your iPad or How to use a pointer device with AssistiveTouch on your iPhone, iPad,
or iPod touch .
Redirections
The Remote Desktop client enables you to make your local clipboard available in your
remote session. By default, text you copy on your iOS or iPadOS device is available to
paste in your remote session, and text you copy in your remote session is available to
paste on your iOS or iPadOS device.

Desktop:

then tap Settings.
3. You can change the following settings:
Show PC Toggle On or Off Show thumbnails of remote sessions.

Thumbnails
Allow Display Toggle On or Off Allow your device to turn off its screen.
Auto-Lock
Use HTTP Toggle On or Off Use the HTTP proxy specified in iOS/iPadOS
Proxy network settings.
Appearance Select from Light, Set the appearance of the Remote Desktop client.
Dark, or System
Send Data to Toggle On or Off Help improve the Remote Desktop client by
Microsoft sending anonymous data to Microsoft.

７ Note
The beta client shouldn't be used in production.
You can download the beta client for iOS and iPadOS from TestFlight. To get started, see
Microsoft Remote Desktop for iOS .
Provide feedback
If you want to provide feedback to us on the Remote Desktop client for iOS and iPadOS,
you can do so in the app:
then tap Settings.
3. Tap Submit feedback, which will open the feedback page in your browser.
Next steps
Desktop client.
client for Android and Chrome OS when
features available in the Remote Desktop client for Android and Chrome OS. If you want
to learn how to connect to Azure Virtual Desktop, see Connect to Azure Virtual Desktop
with the Remote Desktop client for Android and Chrome OS.
７ Note

1. Open the RD Client app on your device, then tap Workspaces.
2. Tap the three dots to the right-hand side of the name of a workspace where you'll
see a menu with options for Edit, Refresh, and Delete.
User accounts
1. Open the RD Client app on your device, then tap Workspaces.
2. Tap the three dots to the right-hand side of the name of a workspace, then select
Edit.
3. For User account, tap the drop-down menu, then select Add User Account to add
a new account, or select an account you've previously added.
4. If you selected Add User Account, enter a username and password, then tap Save.
5. Tap Save again to return to Workspaces.

2. In the top left-hand corner, tap the menu icon (three horizontal lines), then tap
User Accounts.
3. Tap the plus icon (+).
4. Enter a username and password, then tap Save. You can then add this account to a
workspace by following the steps in Add user credentials to a workspace.
5. Tap the back arrow (<) to return to Workspaces.
User Accounts.
3. Tap and hold the account you want to remove.

4. Tap delete (the bin icon). Confirm you want to delete the account.
Display preferences
Set orientation
You can set the orientation of the Remote Desktop client to landscape, portrait, or auto-
adjust, where it will match the orientation of your device. Auto-adjust is supported when
your remote session is running Windows 10 and Windows Server 2012 R2 or later. The
window will maintain the same scaling and update the resolution to match the new
orientation. This setting applies to all workspaces.
To set the orientation:
Display.
3. For orientation, tap your preference from Auto-adjust, Lock to landscape or Lock
to portrait.
Set display resolution

You can choose the resolution for your remote session from a predefined list. This
setting applies to all workspaces. You'll need to reconnect to remote sessions if you
changed the resolution while connected.
To set the resolution:
Display.
3. You can tap Default, Match this device, or tap + Customized for a drop-down list
of predefined resolutions. If you choose a customized resolution, you can also
choose the scaling percentage.

DeX
You can use Samsung DeX with a remote session, which enables you to extend your
Android or Chromebook device's display to a larger monitor or TV.
Connection bar and session overview menu

by a magnifying glass icon, and the ability to toggle between showing and hiding the
on-screen keyboard. You can move the connection bar around the top edge of the
display by tapping and dragging it to where you want it.
The middle icon in the connection bar is of the Remote Desktop logo. If you tap this, it
shows the session overview screen. The session overview screen enables you to:
Go to the Connection Center using the Home icon.

Switch inputs between touch and the mouse pointer (when not using a separate
mouse).
Switch between active desktops and apps.
Disconnect all active sessions.
You can return back to an active session from the Connection Center using the Return
Arrow button found in the bottom right corner of the Connection Center.
Input methods
The Remote Desktop client supports native touch gestures, keyboard, mouse, and
trackpad.

mouse modes:
Mouse Mouse Gesture

mode operation

pointer
pointer drag
Mouse Right-click Tap with two fingers, or tap and hold with one finger
pointer
Mouse Right-click drag Double-tap and hold with two fingers, then drag
pointer
pointer
Mouse Zoom With two fingers, pinch to zoom out and spread fingers apart to
pointer zoom in
Input Method Editor
The Remote Desktop client supports Input Method Editor (IME) in a remote session for
input sources. The local Android or Chrome OS IME experience will be accessible in the
remote session.
） Important
For an IME to work, the input mode needs to be in Unicode Mode. To learn more,
see Keyboard modes.
Keyboard
You can use some familiar keyboard shortcuts when using a keyboard with your Android
or Chrome OS device and Azure Virtual Desktop, for example using CTRL + C for copy.
Some Windows keyboard shortcuts are also used as shortcuts on Android and Chrome
OS devices, for example using ALT + TAB to switch between open applications. By
default, these shortcuts won't be passed through to a remote session. Depending on
your Android or Chrome OS device, you may be able to disable certain shortcuts being
used locally, where they'll then be passed through to a remote session.
Keyboard modes
There are two different modes you can use that control how keyboard input is
interpreted in a remote session: Scancode and Unicode.
With Scancode, user input is redirected by sending key press up and down information
to the remote session. Each key is identified by its physical position on the keyboard and
uses the keyboard layout of the remote session, not the keyboard of the local device.
For example, scancode 31 is the key next to Caps Lock . On a US keyboard this key would
produce the character "A", while on a French keyboard this key would produce the
character "Q".
With Unicode, user input is redirected by sending each character to the remote session.
When a key is pressed, the locale of the user is used to translate this input to a
character. This can be as simple as the character "a" by simply pressing the "a" key, but
it can enable an Input Method Editor (IME), allowing you to input multiple keystrokes to
create more complex characters, such as for Chinese and Japanese input sources. Below
are some examples of when to use each mode.
When to use Scancode:
Dealing with characters that aren't printable, such as Arrow Up or shortcut

combinations.
Certain applications that don't accept Unicode input for characters such as: Hyper-
V VMConnect (for example, no way to input a BitLocker password), VMware
Remote Console, all applications written using the Qt framework (for example R
Studio, TortoiseHg, QtCreator).
Applications that utilize scancode input for actions, such as Space bar to
check/uncheck a checkbox, or individual keys as shortcuts, for example
applications in browser.
When to use Unicode:
To avoid a mismatch in expectations. A user who expects the keyboard to behave

in a certain way can run into issues where there are differences for the same
locale/region layout.
When the keyboard layout used on the client might not be available on the server.
By default, the Remote Desktop client uses Unicode. To switch between keyboard
modes:
General.
3. Toggle Use scancode input when available to On to use scancode, or Off to use
Unicode.
Redirections
You can allow the remote computer to the clipboard on your local device. When you
connect to a remote session, you'll be prompted whether you want to allow access to
local resources. The Remote Desktop client supports copying and pasting text only.
To use the clipboard between your local device and your remote session:
2. Tap one of the icons to launch a session to Azure Virtual Desktop.
3. For the prompt Make sure you trust the remote PC before you connect, check the
box for Clipboard, then select Connect.

Desktop:
General.
3. You can change the following settings:

Show desktop Toggle On or Off Show thumbnails of remote sessions.

previews
Use HTTP Proxy Toggle On or Off Use the HTTP proxy specified in Android or
Chrome OS network settings.
Help improve Toggle On or Off Send anonymous data to Microsoft.

Remote Desktop
Theme Select from Light, Set the appearance of the Remote Desktop
Dark, or System client.

７ Note
The beta client shouldn't be used in production environments.
You can download the beta client for Android and Chrome OS from Google Play .
You'll need to give consent to access preview versions and download the client. You'll
receive preview versions directly through the Google Play Store.
Provide feedback
If you want to provide feedback to us on the Remote Desktop client for Android and
Chrome OS, you can do so in the app:
General.
3. Tap Submit feedback, which will open the feedback page in your browser.
Next steps
Desktop client.
 Documentation
Chrome OS.
Remote Desktop clients feature comparison

Learn how the different Remote Desktop clients compare when it comes to features.
Virtual Desktop.
Get started with the web client for Remote Desktop Services
Describes how to sign in to the Remote Desktop web client.
What's new in the web client

Learn about recent changes to the Remote Desktop web client
Show 5 more
Microsoft Store client when connecting
to Azure Virtual Desktop
features available in the Remote Desktop Microsoft Store client. If you want to learn how
to connect to Azure Virtual Desktop, see Connect to Azure Virtual Desktop with the
Remote Desktop Microsoft Store client.
７ Note
Refresh or unsubscribe from a workspace or

see its details
To refresh or unsubscribe from a workspace or see its details:
2. Select the three dots to the right-hand side of the name of a workspace where
you'll see a menu with options for Details, Refresh, and Unsubscribe.
Details shows you details about the workspace, such as:

The name of the workspace.
The URL and username used to subscribe.
The number of desktops and apps.
The date and time of the last refresh.
The status of the last refresh.
Unsubscribe removes the workspace from the Remote Desktop client.
User accounts

1. Open the Remote Desktop application on your device, then select Workspaces.
2. Select one of the icons to launch a session to Azure Virtual Desktop.
3. When prompted to choose an account, select + for User Account to add a new
account, or select an account you've previously added.
4. If you selected to add an account, enter a username, password, and optionally a

friendly name, then select Add.
5. Select Save, then select Connect.

sequence, as the sign-in credentials will be used automatically. You can also edit a saved
account or remove accounts you no longer want to use.
2. Select Settings.
3. Select the + (plus) icon next to User account.
4. Enter a username, password, and optionally a display name, then select Save. You
can then add this account to a workspace by following the steps in Add user
credentials to a workspace.

2. Select Settings.
3. Select the user account from the drop-down list you want to remove, then select
Edit (pencil icon).
4. Select Remove account, then confirm you want to delete the user account.
To change the user account a remote session is using, you'll need to remove the
workspace and add it again.
Display preferences
configure custom settings. Display settings apply to all workspaces.
2. Select Settings.
3. You can configure the following settings:
Setting Value
Start connections in full screen On or off
Start each connection in a new window On or off
When resizing the app - Stretch the content, preserving aspect ratio
- Stretch the content
- Show scroll bars
Prevent the screen from timing out On or off
Connection bar and command menu

by a magnifying glass icon, and more options. You can move the connection bar around
the top edge of the display by tapping and dragging it to where you want it.
The icon with three dots in the connection bar shows the command menu that enables
you to:
Disconnect the remote session.

Toggle between full screen and a window.
Toggle between direct touch and mouse input.
Input methods
You can use touch input, or a built-in or external PC keyboard, trackpad and mouse to
control desktops or apps.

mouse modes:
Mouse Mouse Gesture

mode operation

pointer
pointer drag
Mouse Right-click Tap with two fingers

pointer
Mouse Right-click and Double-tap and hold with two fingers, then drag
pointer drag
pointer
Mouse Mouse Gesture
mode operation
Mouse Zoom With two fingers, pinch to zoom out and move fingers apart to
pointer zoom in
Keyboard
There are several keyboard shortcuts you can use to help use some of the features. Most
common Windows keyboard shortcuts, such as CTRL + C for copy and CTRL + Z for
undo, are the same when using Azure Virtual Desktop. There are some keyboard
Windows shortcut Azure Virtual Desktop Description

shortcut
CTRL + ALT + CTRL + ALT + END Shows the Windows Security dialog
DELETE box.
You can configure the Remote Desktop client whether to send keyboard commands to
the remote session:
2. Select Settings.
3. For Use keyboard commands with, select from one of the following:
My local PC only.
My remote session when it's in full screen (default).
My remote session when it's in use.
Keyboard language
as locale, as your Windows PC. For example, if your Windows PC uses en-GB for English
(United Kingdom), that will also be used by Windows in the remote session.
Redirections
The Remote Desktop client can make your local clipboard and microphone available in
your remote session where you can copy and paste text, images, and files. The audio
from the remote session can also be redirected to your local device. However,
redirection can't be configured using the Remote Desktop client for Windows. This
behavior is configured by your admin in Azure Virtual Desktop.
Update the client

Updates for the Remote Desktop client are delivered through the Microsoft Store. Use
the Microsoft Store to check for and download updates.
App display modes

You can configure the Remote Desktop client to be displayed in light or dark mode, or
match the mode of your system:
2. Select Settings.
3. Under Theme preference, select Light, Dark, or Use system setting. Restart the
app to apply the change.
Pin to the Start menu

You can pin your remote desktops to the Start menu on your local device to make them
easier to launch:
2. Right-click a resource, then select Pin to Start.
Admin link to subscribe to a workspace

The Remote Desktop client for Windows supports the ms-rd Uniform Resource Identifier
(URI) scheme. This enables you to use a link that users can help to automatically
subscribe to a workspace, rather than them having to manually add the workspace in
the Remote Desktop client.
To subscribe to a workspace with a link:
1. Open the following link in a web browser: ms-rd:subscribe?

url=https://rdweb.wvd.microsoft.com .
2. If you see the prompt This site is trying to open Remote Desktop, select Open.
The Remote Desktop application should open and automatically show a sign-in
prompt.
3. Enter your user account, then select Sign in. After a few seconds, your workspaces
should show the desktops and applications that have been made available to you
by your admin.
Provide feedback
If you want to provide feedback to us on the Remote Desktop client for Windows, you
can do so by selecting the button that looks like a smiley face emoji in the client app, as
shown in the following image. This will open the Feedback Hub.
To best help you, we need you to give us as detailed information as possible. Along with
a detailed description, you can include screenshots, attach a file, or make a recording.
For more tips about how to provide helpful feedback, see Feedback.
Next steps
Desktop client.
 Documentation
Virtual Desktop.

Desktop.
Chrome OS.
Show 5 more
Configure device redirection
Configuring device redirection for your Azure Virtual Desktop environment allows you to
use printers, USB devices, microphones, and other peripheral devices in the remote
session. Some device redirections require changes to both Remote Desktop Protocol
(RDP) properties and Group Policy settings.
Supported device redirection

Each client supports different kinds of device redirections. Check out Compare the
clients for the full list of supported device redirections for each client.
） Important
You can only enable redirections with binary settings that apply to both to and
from the remote machine.
Customizing RDP properties for a host pool

To learn more about customizing RDP properties for a host pool using PowerShell or the
Azure portal, check out RDP properties. For the full list of supported RDP properties, see
Supported RDP file settings.
Setup device redirection

You can use the following RDP properties and Group Policy settings to configure device
redirection.
Audio input (microphone) redirection

Set the following RDP property to configure audio input redirection:
audiocapturemode:i:1 enables audio input redirection.
audiocapturemode:i:0 disables audio input redirection.
Audio output (speaker) redirection

Set the following RDP property to configure audio output redirection:
audiomode:i:0 enables audio output redirection.

audiomode:i:1 or audiomode:i:2 disable audio output redirection.
Camera redirection
Set the following RDP property to configure camera redirection:
camerastoredirect:s:* redirects all cameras.
camerastoredirect:s: disables camera redirection.
７ Note
Even if the camerastoredirect:s: property is disabled, local cameras may be

redirected through the devicestoredirect:s: property. To fully disable camera
redirection set camerastoredirect:s: and either set devicestoredirect:s: or define
some subset of plug and play devices that does not include any camera.
You can also redirect specific cameras using a semicolon-delimited list of

KSCATEGORY_VIDEO_CAMERA interfaces, such as camerastoredirect:s:\?
\usb#vid_0bda&pid_58b0&mi .
Clipboard redirection
Set the following RDP property to configure clipboard redirection:
redirectclipboard:i:1 enables clipboard redirection.

redirectclipboard:i:0 disables clipboard redirection.
COM port redirection

Set the following RDP property to configure COM port redirection:
redirectcomports:i:1 enables COM port redirection.
redirectcomports:i:0 disables COM port redirection.
USB redirection
） Important
To redirect a mass storage USB device connected to your local computer to a
remote session host that uses a supported operating system for Azure Virtual
Desktop, you'll need to configure the Drive/storage redirection RDP property.
Enabling the USB redirection RDP property by itself won't work.
To configure the property, open the Azure portal and set the following RDP property to
enable USB device redirection:
usbdevicestoredirect:s:* enables USB device redirection for all supported devices

on the client.
usbdevicestoredirect:s: disables USB device redirection.
For more information, see Local drive redirection.
In order to use USB redirection, you'll need to enable Plug and Play device redirection
on your session host first. To enable Plug and Play:
1. Next, decide whether you want to configure Group Policy centrally from your
domain or locally for each session host:
To configure it from an Active Directory (AD) Domain, open the Group Policy
Management Console (GPMC) and create or edit a policy that targets your
session hosts.
To configure it locally, open the Local Group Policy Editor on the session host.
2. Go to Computer Configuration > Administrative Templates > Windows

Device and resource redirection.
3. Select Do not allow supported Plug and Play device redirection and set it to
Disabled.
4. Restart your VM.
After that, to enable USB redirection:
1. For client devices, apply the following Group Policy setting. You can apply this
policy centrally for devices joined to an Active Directory domain or managed by
Intune, or locally on the device using the Local Group Policy editor:
Computer Configuration > Policies > Administrative Templates > Windows

Components > Remote Desktop Services > Remote Desktop Connection Client >
RemoteFX USB Device Redirection.
2. Select Allows RDP redirection of other supported RemoteFX USB devices from
this computer.
3. Select the Enabled option, and then select the Administrators and Users in
RemoteFX USB Redirection Access Rights box.
4. Select OK.
5. Open an elevated Command Prompt and run the following command:
gpupdate /force
6. Restart the local device.
７ Note
If the USB device you're looking for isn't appearing, check out our troubleshooting
article at Some USB devices are not available through RemoteFX USB redirection.
Next, make sure the USB device you're trying to connect to is compatible with Azure
Virtual Desktop. To check compatibility:
1. Connect the USB device to your local machine.
2. Run mstsc.exe to open the Remote Desktop client.
７ Note
Although you can use mstc.exe to confirm the device supports redirection,
you can't use the program to connect to Azure Virtual Desktop.
3. Select Show Options.
4. Select the Local Resources tab.
5. Under Local devices and resources, select More.
6. If your device is compatible, it should appear under Other supported Remote FX

USB devices. You can only use USB redirection on USB devices that appear in this
list.
Plug and play device redirection
Set the following RDP property to configure plug and play device redirection:
devicestoredirect:s:* enables redirection of all plug and play devices.
devicestoredirect:s: disables redirection of plug and play devices.
You can also select specific plug and play devices using a semicolon-delimited list, such
as devicestoredirect:s:root\*PNP0F08 .
Local drive redirection

Set the following RDP property to configure local drive redirection:
drivestoredirect:s:* enables redirection of all disk drives.
drivestoredirect:s: disables local drive redirection.
You can also select specific drives using a semicolon-delimited list, such as
drivestoredirect:s:C:;E:; .
To enable web client file transfer, set drivestoredirect:s:* . If you set any other value
for this RDP property, web client file transfer will be disabled.
Location redirection
Set the following RDP property to configure location redirection:
redirectlocation:i:1 enables location redirection.
redirectlocation:i:0 disables location redirection.
When enabled, the location of the local device is sent to the session host and set as its
location. Location redirection lets applications like Maps or Printer Search use your
physical location. When you disable location redirection, these applications will use the
location of the session host instead.
Printer redirection
Set the following RDP property to configure printer redirection:
redirectprinters:i:1 enables printer redirection.
redirectprinters:i:0 disables printer redirection.

Smart card redirection
Set the following RDP property to configure smart card redirection:
redirectsmartcards:i:1 enables smart card redirection.
redirectsmartcards:i:0 disables smart card redirection.
WebAuthn redirection
Set the following RDP property to configure WebAuthn redirection:
redirectwebauthn:i:1 enables WebAuthn redirection.
redirectwebauthn:i:0 disables WebAuthn redirection.
When enabled, WebAuthn requests from the session are sent to the local PC to be
completed using the local Windows Hello for Business or security devices like FIDO keys.
For more information, see In-session passwordless authentication.
Disable drive redirection

If you're making RDP connections from personal resources to corporate ones on the
Terminal Server or Windows Desktop clients, you can disable drive redirection for
security purposes. To disable drive redirection:
1. Open the Registry Editor (regedit).
2. Go to HKEY_LOCAL_MACHINE > SOFTWARE > Microsoft > Terminal Server

Client.
3. Create the following registry key:
Key: HKLM\Software\Microsoft\Terminal Server Client

Type: REG_DWORD
Name: DisableDriveRedirection
4. Set the value of the registry key to 0.
Disable printer redirection

Terminal Server or Windows Desktop clients, you can disable printer redirection for
security purposes. To disable printer redirection:

Client.

Type: REG_DWORD
Name: DisablePrinterRedirection
Disable clipboard redirection

Terminal Server or Windows Desktop clients, you can disable clipboard redirection for
security purposes. To disable clipboard redirection:

Client.

Type: REG_DWORD
Name: DisableClipboardRedirection
Next steps
For more information about how to configure RDP settings, see Customize RDP
properties.
For a list of RDP settings you can change, see Supported RDP properties for Azure
Virtual Desktop.
 Documentation
Virtual Desktop.
Set up email discovery to subscribe to your RDS feed

Learn how to set up email discovery in your RDS deployment.
Show 5 more
Set up email discovery to subscribe to
your RDS feed
Have you ever had trouble getting your end users connected to their published RDS
feed, either because of a single missing character in the feed URL or because they lost
the email with the URL? Nearly all Remote Desktop client applications support finding
your subscription by entering your email address, making it easier than ever to get your
users connected to their RemoteApps and desktops.
Before you set up email discovery, do the following:
Make sure you have permission to add a TXT record to the domain associated with
your email (for example, if your users have @contoso.com email addresses, you
would need permissions for the contoso.com domain)
Create an RD Web feed URL (https://<rdweb-dns-
name>.domain/RDWeb/Feed/webfeed.aspx, such as
https://rdweb.contoso.com/RDWeb/Feed/webfeed.aspx )
７ Note
If you're using Azure Virtual Desktop instead of Remote Desktop, you'll want to use
these URLs instead:
If you're using Azure Virtual Desktop (classic):

https://rdweb.wvd.microsoft.com/api/feeddiscovery/webfeeddiscovery.aspx
If you're using Azure Virtual Desktop:

https://rdweb.wvd.microsoft.com/api/arm/feeddiscovery
Now, follow these steps to set up email discovery:
1. In your browser, connect to the website of the domain name registrar where your
domain is registered.
2. Navigate to the appropriate page for your registered domain where you can view,
add, and edit DNS records.
3. Enter a new DNS record with the following properties:
Host: _msradc
Text: <RD Web Feed URL>
TTL: 300 seconds
The names of the DNS records fields vary by domain name registrar, but this
process will result in a TXT record named _msradc.<domain_name> (such as
_msradc.contoso.com) that has a value of the full RD Web feed.
That's it! Now, launch the Remote Desktop application on your device and subscribe
yourself!
Customize the feed for Azure Virtual
Desktop users
） Important
You can customize the feed so the RemoteApp and remote desktop resources appear in
a recognizable way for your users.
Prerequisites
This article assumes you've already downloaded and installed the Azure Virtual Desktop
PowerShell module. If you haven't, follow the instructions in Set up the PowerShell
module.
Customize the display name for a session host

You can change the display name for a remote desktop for your users by setting its
session host friendly name. By default, the session host friendly name is empty, so users
only see the app name. You can set the session host friendly name using REST API.
７ Note
The following instructions only apply to personal desktops, not pooled desktops.
Also, personal host pools only allow and support desktop app groups.
To add or change a session host's friendly name, use the Session Host - Update REST
API and update the properties.friendlyName parameter with a REST API request.
Customize the display name for a RemoteApp

You can change the display name for a published RemoteApp by setting the friendly
name. By default, the friendly name is the same as the name of the RemoteApp
program.
To retrieve a list of published RemoteApps for an app group, run the following
PowerShell cmdlet:
PowerShell
Get-AzWvdApplication -ResourceGroupName <resourcegroupname> -

ApplicationGroupName <appgroupname>
To assign a friendly name to a RemoteApp, run the following cmdlet with the required
parameters:
PowerShell
Update-AzWvdApplication -ResourceGroupName <resourcegroupname> -

ApplicationGroupName <appgroupname> -Name <applicationname> -FriendlyName
<newfriendlyname>
For example, let's say you retrieved the current applications with the following example
cmdlet:
PowerShell
Get-AzWvdApplication -ResourceGroupName 0301RG -ApplicationGroupName 0301RAG

| format-list
The output would look like this:
PowerShell
CommandLineSetting : DoNotAllow
Description :
FilePath : C:\Program Files\Windows NT\Accessories\wordpad.exe
FriendlyName : Microsoft Word
IconContent : {0, 0, 1, 0…}
IconHash : --iom0PS6XLu-EMMlHWVW3F7LLsNt63Zz2K10RE0_64
IconIndex : 0
IconPath : C:\Program Files\Windows NT\Accessories\wordpad.exe
Id :
/subscriptions/<subid>/resourcegroups/0301RG/providers/Microsoft.DesktopVirt
ualization/applicationgroups/0301RAG/applications/Microsoft Word
Name : 0301RAG/Microsoft Word
ShowInPortal : False
Type :
Microsoft.DesktopVirtualization/applicationgroups/applications
To update the friendly name, run this cmdlet:
PowerShell
Update-AzWvdApplication -GroupName 0301RAG -Name "Microsoft Word" -

FriendlyName "WordUpdate" -ResourceGroupName 0301RG -IconIndex 0 -IconPath
"C:\Program Files\Windows NT\Accessories\wordpad.exe" -ShowInPortal:$true -
CommandLineSetting DoNotallow -FilePath "C:\Program Files\Windows
NT\Accessories\wordpad.exe"
To confirm you've successfully updated the friendly name, run this cmdlet:
PowerShell
Get-AzWvdApplication -ResourceGroupName 0301RG -ApplicationGroupName 0301RAG

| format-list FriendlyName
The cmdlet should give you the following output:
PowerShell
FriendlyName : WordUpdate
Customize the display name for a Remote

Desktop
You can change the display name for a published remote desktop by setting a friendly
name. If you manually created a host pool and desktop app group through PowerShell,
the default friendly name is "Session Desktop." If you created a host pool and desktop
app group through the GitHub Azure Resource Manager template or the Azure
Marketplace offering, the default friendly name is the same as the host pool name.
To retrieve the remote desktop resource, run the following PowerShell cmdlet:
PowerShell
Get-AzWvdDesktop -ResourceGroupName <resourcegroupname> -

ApplicationGroupName <appgroupname> -Name <applicationname>
To assign a friendly name to the remote desktop resource, run the following PowerShell
cmdlet:
PowerShell
Update-AzWvdDesktop -ResourceGroupName <resourcegroupname> -
ApplicationGroupName <appgroupname> -Name <applicationname> -FriendlyName
<newfriendlyname>
Customize a display name in the Azure portal

You can change the display name for a published remote desktop by setting a friendly
name using the Azure portal.
2. Search for Azure Virtual Desktop.
4. On the Azure Virtual Desktop page, select Application groups on the left side of
the screen, then select the name of the app group you want to edit. (For example,
if you want to edit the display name of the desktop app group, select the app
group named Desktop.)
5. Select Applications in the menu on the left side of the screen.
6. Select the application you want to update, then enter a new Display name.
7. Select Save. The application you edited should now display the updated name.
Next steps
Now that you've customized the feed for users, you can sign in to a Azure Virtual
Desktop client to test it out. To do so, continue to the Connect to Azure Virtual Desktop
How-tos:
Connect with Windows

Use multimedia redirection on Azure
Virtual Desktop
This article will show you how to use multimedia redirection (MMR) for Azure Virtual
Desktop with Microsoft Edge or Google Chrome browsers. For more information about
how multimedia redirection works, see Understanding multimedia redirection for Azure
Virtual Desktop.
７ Note
Multimedia redirection isn't supported on Azure Virtual Desktop for Microsoft 365
Government (GCC), GCC-High environments, and Microsoft 365 DoD.
Desktop client on Windows 11, Windows 10, or Windows 10 IoT Enterprise devices.
Multimedia redirection requires the Windows Desktop client, version 1.2.3916 or
later with Insider releases enabled. For more information, see Prerequisites.
Prerequisites
Before you can use multimedia redirection on Azure Virtual Desktop, you'll need the
following things:
An Azure Virtual Desktop deployment.

Microsoft Edge or Google Chrome installed on your session hosts.
Microsoft Visual C++ Redistributable 2015-2022, version 14.32.31332.0 or later
installed on your session hosts. You can download the latest version from
Microsoft Visual C++ Redistributable latest supported downloads.
Windows Desktop client, version 1.2.3916 or later on Windows 11, Windows 10, or
Windows 10 IoT Enterprise devices. This includes the multimedia redirection plugin
( C:\Program Files\Remote Desktop\MsMmrDVCPlugin.dll ), which is required on the
client device. Your device must meet the hardware requirements for Teams on a
Windows PC.
Install the multimedia redirection extension

For multimedia redirection to work, there are two parts to install on your session hosts:
the host component and the browser extension for Edge or Chrome. You install the host
component and browser extension from an MSI file, and you can also get and install the
browser extension from Microsoft Edge Add-ons or the Chrome Web Store, depending
on which browser you're using.
Install the host component

To install the host component on your session hosts, you can install the MSI manually on
each session host or use your enterprise deployment tool with msiexec . To install the
MSI manually, you'll need to:
1. Sign in to a session host as a local administrator.
2. Download the MMR host MSI installer .
3. Open the file that you downloaded to run the setup wizard.
4. Follow the prompts. Once it's completed, select Finish.
Install the browser extension

Next, you'll need to install the browser extension. This is installed on session hosts
where you already have Edge or Chrome available. Installing the host component also
installs the browser extension. Users will see a prompt that says New Extension added.
In order to use the app, they'll need to enable the extension. A user can enable the
extension by doing the following:
1. Sign in to Azure Virtual Desktop and open Edge or Chrome.
2. At the prompt to enable the extension, select Turn on extension. Users should also
pin the extension so that they can see from the icon if multimedia redirection is
connected.
） Important
If the user selects Remove extension, it will be removed from the browser and
they will need to add it from Microsoft Edge Add-ons or the Chrome Web
Store. To install it again, see Installing the browser extension manually.
You can also automate installing the browser extension from Microsoft Edge Add-ons or
the Chrome Web Store for all users by using Group Policy.
Using Group Policy has the following benefits:
You can install the extension silently and without user interaction.
You can restrict which websites use multimedia redirection.
You can pin the extension icon in Google Chrome by default.
Install the browser extension manually

If you need to install the browser extension separately, you can download it from
Microsoft Edge Add-ons or the Chrome Web Store.
To install the multimedia redirection extension manually, follow these steps:
1. Sign in to Azure Virtual Desktop.
2. In your browser, open one of the following links, depending on which browser
you're using:
For Microsoft Edge: Microsoft Multimedia Redirection Extension
For Google Chrome: Microsoft Multimedia Redirection Extension
3. Install the extension by selecting Get (for Microsoft Edge) or Add to Chrome (for
Google Chrome), then at the additional prompt, select Add extension. Once the
installation is finished, you'll see a confirmation message saying that you've
successfully added the extension.
Install the browser extension using Group Policy

You can install the multimedia redirection extension using Group Policy, either centrally
from your domain for session hosts that are joined to an Active Directory (AD) domain,
or using the Local Group Policy Editor for each session host. This process will change
depending on which browser you're using.
Edge
1. Download and install the Microsoft Edge administrative template by following

the directions in Configure Microsoft Edge policy settings on Windows devices
2. Next, decide whether you want to configure Group Policy centrally from your
domain or locally for each session host:
To configure it from an AD Domain, open the Group Policy Management

Console (GPMC) and create or edit a policy that targets your session
hosts.
To configure it locally, open the Local Group Policy Editor on the session
host.
3. Go to Computer Configuration > Administrative Templates > Microsoft

Edge > Extensions.
4. Open the policy setting Configure extension management settings and set it
to Enabled.
5. In the field for Configure extension management settings, enter the

following:
JSON
{ "joeclbldhdmoijbaagobkhlpfjglcihd": { "installation_mode":
"force_installed", "update_url":
"https://edge.microsoft.com/extensionwebstorebase/v1/crx" } }
You can specify additional parameters to allow or block specific domains. For
example, to only allow youtube.com, enter the following:
JSON
{ "joeclbldhdmoijbaagobkhlpfjglcihd": { "installation_mode":
"force_installed", "runtime_allowed_hosts": [ "*://*.youtube.com"
], "runtime_blocked_hosts": [ "*://*" ], "update_url":
"https://edge.microsoft.com/extensionwebstorebase/v1/crx" } }
6. Apply the changes by running the following command in Command Prompt

or PowerShell on each session host:

gpupdate /force
Check the extension status

Once you've installed the extension, you can check its status by visiting a website with
media content, such as one from the list at Websites that work with multimedia
redirection, and hovering your mouse cursor over the multimedia redirection extension
icon in the extension bar on the top-right corner of your browser. A message will appear
and tell you about the current status, as shown in the following screenshot.
Another way you can check the extension status is by selecting the extension icon, then
you'll see a list of Features supported on this website with a green check mark if the
website supports that feature.
Teams live events

To use multimedia redirection with Teams live events:
1. Sign in to Azure Virtual Desktop.
2. Open the link to the Teams live event in either the Edge or Chrome browser.
3. Make sure you can see a green play icon as part of the multimedia redirection
status icon. If the green play icon is there, MMR is enabled for Teams live events.
4. Select Watch on the web instead. The Teams live event should automatically start
playing in your browser. Make sure you only select Watch on the web instead, as
shown in the following screenshot. If you use the native Teams app, MMR won't
work.
Enable video playback for all sites
Multimedia redirection is currently limited to the sites listed in Websites that work with
multimedia redirection by default. However, you can enable video playback for all sites
to allow you to test the feature with other websites. To enable video playback for all
sites:
1. Select the extension icon in your browser.
2. Select Show Advanced Settings.
3. Toggle Enable video playback for all sites(beta) to on.
Redirected video outlines

Redirected video outlines will allow you to highlight the currently redirected video
elements. When this is enabled, you will see a bright highlighted border around the
video element that is being redirected. To enable redirected video outlines:

3. Toggle Redirected video outlines to on. You will need to refresh the webpage for
the change to take effect.
Video status overlay

When you enable video status overlay, you'll see a short message at the top of the video
player that indicates the redirection status of the current video. The message will
disappear after five seconds. To enable video status overlay:
3. Toggle Video Status Overlay to on. You'll need to refresh the webpage for the
change to take effect.
Next steps
For more information about multimedia redirection and how it works, see What is
multimedia redirection for Azure Virtual Desktop?.
To troubleshoot issues or view known issues, see our troubleshooting article.
If you're interested in learning more about using Teams for Azure Virtual Desktop, check
out Teams for Azure Virtual Desktop.
 Documentation

Desktop.




Show 5 more
Set up diagnostics to monitor agent
updates
Diagnostic logs can tell you which agent version is installed for an update, when it was
installed, and if the update was successful. If an update is unsuccessful, it might be
because the session host was turned off during the update. If that happened, you
should turn the session host back on.
This article describes how to use diagnostic logs in a Log Analytics workspace to
monitor agent updates.
Enable sending diagnostic logs to your Log

Analytics workspace
To enable sending diagnostic logs to your Log Analytics workspace:
1. Create a Log Analytics workspace, if you haven't already. Next, get the workspace
ID and primary key by following the instructions in Use Log Analytics for the
diagnostics feature.
2. Send diagnostics to the Log Analytics workspace you created by following the
instructions in Push diagnostics data to your workspace.
3. Follow the directions in How to access Log Analytics to access the logs in your
workspace.
７ Note
The log query results only cover the last 30 days of data in your deployment.
Use diagnostics to see when an update

becomes available
To see when agent component updates are available:
1. Access the logs in your Log Analytics workspace.
2. Select the + button to create a new query.

3. Copy and paste the following Kusto query to see if agent component updates are
available for the specified session host. Make sure to change the
sessionHostName parameter to the name of your session host.
７ Note
If you haven't enabled the Scheduled Agent Updates feature, you won't see
anything in the NewPackagesAvailable field.
Kusto
| where TimeGenerated >= ago(30d)
| where SessionHostName == "sessionHostName"
| project TimeGenerated, AgentVersion, SessionHostName,

LastUpgradeTimeStamp, UpgradeState, UpgradeErrorMsg
| sort by TimeGenerated desc
| take 1
Use diagnostics to see when agent updates are

happening
To see when agent updates are happening or to make sure that the Scheduled Agent
Updates feature is working:
1. Access the logs in your Log Analytics workspace.
2. Select the + button to create a new query.
3. Copy and paste the following Kusto query to see when the agent has updated for
the specified session host. Make sure to change the sessionHostName parameter
to the name of your session host.
Kusto
| where TimeGenerated >= ago(30d)
| where SessionHostName == "sessionHostName"
| project TimeGenerated, AgentVersion, SessionHostName,

LastUpgradeTimeStamp, UpgradeState, UpgradeErrorMsg
| summarize arg_min(TimeGenerated, *) by AgentVersion
| sort by TimeGenerated asc
Next steps
For more information about Scheduled Agent Updates and the agent components,
check out the following articles:
To learn how to schedule agent updates, see Scheduled Agent Updates.

For more information about the Azure Virtual Desktop agent, side-by-side stack,
and Geneva Monitoring agent, see Getting Started with the Azure Virtual Desktop
Agent.
Learn more about the latest and previous agent versions at What's new in the
Azure Virtual Desktop agent.
If you're experiencing agent or connectivity-related issues, see the Azure Virtual
Desktop Agent issues troubleshooting guide.
Use Azure Virtual Desktop Insights to
monitor your deployment
Azure Virtual Desktop Insights is a dashboard built on Azure Monitor Workbooks that
helps IT professionals understand their Azure Virtual Desktop environments. This topic
will walk you through how to set up Azure Virtual Desktop Insights to monitor your
Azure Virtual Desktop environments.
Requirements
Before you start using Azure Virtual Desktop Insights, you'll need to set up the following
things:
All Azure Virtual Desktop environments you monitor must be based on the latest
release of Azure Virtual Desktop that’s compatible with Azure Resource Manager.
At least one configured Log Analytics Workspace. Use a designated Log Analytics
workspace for your Azure Virtual Desktop session hosts to ensure that
performance counters and events are only collected from session hosts in your
Azure Virtual Desktop deployment.
Enable data collection for the following things in your Log Analytics workspace:
Diagnostics from your Azure Virtual Desktop environment
Recommended performance counters from your Azure Virtual Desktop session
hosts
Recommended Windows Event Logs from your Azure Virtual Desktop session
hosts
The data setup process described in this article is the only one you'll need to monitor
Azure Virtual Desktop. You can disable all other items sending data to your Log
Analytics workspace to save costs.
Anyone monitoring Azure Virtual Desktop Insights for your environment will also need
the following read-access permissions:
Read-access to the Azure resource groups that hold your Azure Virtual Desktop
resources.
Read-access to the subscription's resource groups that hold your Azure Virtual
Desktop session hosts.
Read access to the Log Analytics workspace. In the case that multiple Log Analytics
workspaces are used, read access should be granted to each to allow viewing data.
７ Note
Read access only lets admins view data. They'll need different permissions to
manage resources in the Azure Virtual Desktop portal.
Open Azure Virtual Desktop Insights

You can open Azure Virtual Desktop Insights with one of the following methods:
Go to aka.ms/avdi .
Search for and select Azure Virtual Desktop from the Azure portal, then select
Insights.
Search for and select Azure Monitor from the Azure portal. Select Insights Hub
under Insights, then select Azure Virtual Desktop.
Once you have the page open,
enter the Subscription, Resource group, Host pool, and Time range of the
environment you want to monitor.
Log Analytics settings

To start using Azure Virtual Desktop Insights, you'll need at least one Log Analytics
workspace. Use a designated Log Analytics workspace for your Azure Virtual Desktop
session hosts to ensure that performance counters and events are only collected from
session hosts in your Azure Virtual Desktop deployment. If you already have a
workspace set up, skip ahead to Set up using the configuration workbook. To set one
up, see Create a Log Analytics workspace in the Azure portal.
７ Note
Standard data storage charges for Log Analytics will apply. To start, we recommend
you choose the pay-as-you-go model and adjust as you scale your deployment and
take in more data. To learn more, see Azure Monitor pricing .
Set up using the configuration workbook

If it's your first time opening Azure Virtual Desktop Insights, you'll need set up Azure
Virtual Desktop Insights for your Azure Virtual Desktop environment. To configure your
resources:
1. Open Azure Virtual Desktop Insights in the Azure portal at aka.ms/avdi , then
select configuration workbook.
2. Select an environment to configure under Subscription, Resource Group, and Host
Pool.
The configuration workbook sets up your monitoring environment and lets you check
the configuration after you've finished the setup process. It's important to check your
configuration if items in the dashboard aren't displaying correctly, or when the product
group publishes updates that require new settings.
Resource diagnostic settings

To collect information on your Azure Virtual Desktop infrastructure, you'll need to
enable several diagnostic settings on your Azure Virtual Desktop host pools and
workspaces (this is your Azure Virtual Desktop workspace, not your Log Analytics
workspace). To learn more about host pools, workspaces, and other Azure Virtual
Desktop resource objects, see our environment guide.
You can learn more about Azure Virtual Desktop diagnostics and the supported
diagnostic tables at Send Azure Virtual Desktop diagnostics to Log Analytics.
To set your resource diagnostic settings in the configuration workbook:
1. Select the Resource diagnostic settings tab in the configuration workbook.

2. Select Log Analytics workspace to send Azure Virtual Desktop diagnostics.
Host pool diagnostic settings

To set up host pool diagnostics using the resource diagnostic settings section in the
configuration workbook:
1. Under Host pool, check to see whether Azure Virtual Desktop diagnostics are
enabled. If they aren't, an error message will appear that says "No existing
diagnostic configuration was found for the selected host pool." You'll need to
enable the following supported diagnostic tables:
Checkpoint
Error
Management
Connection
HostRegistration
AgentHealthStatus
７ Note
If you don't see the error message, you don't need to do steps 2 through 4.
2. Select Configure host pool.
3. Select Deploy.
4. Refresh the configuration workbook.
Workspace diagnostic settings
To set up workspace diagnostics using the resource diagnostic settings section in the
configuration workbook:
1. Under Workspace, check to see whether Azure Virtual Desktop diagnostics are
enabled for the Azure Virtual Desktop workspace. If they aren't, an error message
will appear that says "No existing diagnostic configuration was found for the
selected workspace." You'll need to enable the following supported diagnostics
tables:
Checkpoint
Error
Management
Feed
７ Note
If you don't see the error message, you don't need to do steps 2-4.
2. Select Configure workspace.
3. Select Deploy.
Session host data settings

To collect information on your Azure Virtual Desktop session hosts, you'll need to install
the Log Analytics agent on all session hosts in the host pool, make sure the session
hosts are sending to a Log Analytics workspace, and configure your Log Analytics agent
settings to collect performance data and Windows Event Logs.
The Log Analytics workspace you send session host data to doesn't have to be the same
one you send diagnostic data to. If you have Azure session hosts outside of your Azure
Virtual Desktop environment, we recommend having a designated Log Analytics
workspace for the Azure Virtual Desktop session hosts.
To set the Log Analytics workspace where you want to collect session host data:
1. Select the Session host data settings tab in the configuration workbook.
2. Select the Log Analytics workspace you want to send session host data to.
Session hosts
You'll need to install the Log Analytics agent on all session hosts in the host pool and
send data from those hosts to your selected Log Analytics workspace. If Log Analytics
isn't configured for all the session hosts in the host pool, you'll see a Session hosts
section at the top of Session host data settings with the message "Some hosts in the
host pool are not sending data to the selected Log Analytics workspace."
７ Note
If you don't see the Session hosts section or error message, all session hosts are set
up correctly. Skip ahead to set up instructions for Workspace performance
counters. Currently automated deployment is limited to 1000 session hosts or
fewer.
To set up your remaining session hosts using the configuration workbook:
1. Select Add hosts to workspace.

７ Note
For larger host pools (> 1000 session hosts), or if there are deployment issues, it is
recommended to install the Log Analytics agent at time of session host creation
through the use of an ARM template.
Workspace performance counters

You'll need to enable specific performance counters to collect performance information
from your session hosts and send it to the Log Analytics workspace.
If you already have performance counters enabled and want to remove them, follow the
instructions in Configuring performance counters. You can add and remove performance
counters in the same location.
To set up performance counters using the configuration workbook:
1. Under Workspace performance counters in the configuration workbook, check

Configured counters to see the counters you've already enabled to send to the
Log Analytics workspace. Check Missing counters to make sure you've enabled all
required counters.
2. If you have missing counters, select Configure performance counters.
3. Select Apply Config.
5. Make sure all the required counters are enabled by checking the Missing counters
list.
Configure Windows Event Logs

You'll also need to enable specific Windows Event Logs to collect errors, warnings, and
information from the session hosts and send them to the Log Analytics workspace.
If you've already enabled Windows Event Logs and want to remove them, follow the
instructions in Configuring Windows Event Logs. You can add and remove Windows
Event Logs in the same location.
To set up Windows Event Logs using the configuration workbook:
1. Under Windows Event Logs configuration, check Configured Event Logs to see
the Event Logs you've already enabled to send to the Log Analytics workspace.
Check Missing Event Logs to make sure you've enabled all Windows Event Logs.
2. If you have missing Windows Event Logs, select Configure Events.
3. Select Deploy.
5. Make sure all the required Windows Event Logs are enabled by checking the
Missing Event Logs list.
７ Note
If automatic event deployment fails, select Open agent configuration in the

configuration workbook to manually add any missing Windows Event Logs.
Optional: configure alerts
Azure Virtual Desktop Insights allows you to monitor Azure Monitor alerts happening
within your selected subscription in the context of your Azure Virtual Desktop data.
Azure Monitor alerts are an optional feature on your Azure subscriptions, and you need
to set them up separately from Azure Virtual Desktop Insights. You can use the Azure
Monitor alerts framework to set custom alerts on Azure Virtual Desktop events,
diagnostics, and resources. To learn more about Azure Monitor alerts, see Azure Monitor
Log Alerts.
Diagnostic and usage data

Microsoft automatically collects usage and performance data through your use of the
Azure Virtual Desktop Insights service. Microsoft uses this data to improve the quality,
security, and integrity of the service.
To provide accurate and efficient troubleshooting capabilities, the collected data

includes the portal session ID, Azure Active Directory user ID, and the name of the portal
tab where the event occurred. Microsoft doesn't collect names, addresses, or other
contact information.
For more information about data collection and usage, see the Microsoft Online Services
Privacy Statement .
７ Note
To learn about viewing or deleting your personal data collected by the service, see
Azure Data Subject Requests for the GDPR. For more information about GDPR, see
the GDPR section of the Service Trust portal .
Next steps
Now that you’ve configured Azure Virtual Desktop Insights for your Azure Virtual
Desktop environment, here are some resources that might help you start monitoring
your environment:
Check out our glossary to learn more about terms and concepts related to Azure
Virtual Desktop Insights costs.
If you encounter a problem, check out our troubleshooting guide for help and
known issues.
To see what's new in each version update, see What's new in Azure Virtual Desktop
Insights.
Use Log Analytics for the diagnostics
feature
） Important
Azure Virtual Desktop uses Azure Monitor for monitoring and alerts like many other
Azure services. This lets admins identify issues through a single interface. The service
creates activity logs for both user and administrative actions. Each activity log falls under
the following categories:
Management Activities:
Track whether attempts to change Azure Virtual Desktop objects using APIs or
PowerShell are successful. For example, can someone successfully create a host
pool using PowerShell?
Feed:
Can users successfully subscribe to workspaces?
Do users see all resources published in the Remote Desktop client?
Connections:
When users initiate and complete connections to the service.
Host registration:
Was the session host successfully registered with the service upon connecting?
Errors:
Are users encountering any issues with specific activities? This feature can
generate a table that tracks activity data for you as long as the information is
joined with the activities.
Checkpoints:
Specific steps in the lifetime of an activity that were reached. For example,
during a session, a user was load balanced to a particular host, then the user
was signed on during a connection, and so on.
Agent Health Status:
Monitor the health and status of the Azure Virtual Desktop agent installed on
each session host. For example, verify that the agents are up to date, or whether
the agent is in a healthy state and ready to accept new user sessions.
Connection Network Data:
Track the average network data for user sessions to monitor for details including
the estimated round trip time and available bandwidth throughout their
connection.
Connections that don't reach Azure Virtual Desktop won't show up in diagnostics results
because the diagnostics role service itself is part of Azure Virtual Desktop. Azure Virtual
Desktop connection issues can happen when the user is experiencing network
connectivity issues.
Azure Monitor lets you analyze Azure Virtual Desktop data and review virtual machine
(VM) performance counters, all within the same tool. This article will tell you more about
how to enable diagnostics for your Azure Virtual Desktop environment.
７ Note
To learn how to monitor your VMs in Azure, see Monitoring Azure virtual
machines with Azure Monitor. Also, make sure to review the Azure Virtual
Desktop Insights glossary for a better understanding of your user experience on
the session host.
Before you get started

Before you can use Log Analytics, you'll need to create a workspace. To do that, follow
the instructions in one of the following two articles:
If you prefer using Azure portal, see Create a Log Analytics workspace in Azure
portal.
If you prefer PowerShell, see Create a Log Analytics workspace with PowerShell.
After you've created your workspace, follow the instructions in Connect Windows
computers to Azure Monitor to get the following information:
The workspace ID
The primary key of your workspace
You'll need this information later in the setup process.
Make sure to review permission management for Azure Monitor to enable data access
for those who monitor and maintain your Azure Virtual Desktop environment. For more
information, see Get started with roles, permissions, and security with Azure Monitor.
Push diagnostics data to your workspace
You can push diagnostics data from your Azure Virtual Desktop objects into the Log
Analytics for your workspace. You can set up this feature right away when you first
create your objects.
To set up Log Analytics for a new object:
1. Sign in to the Azure portal and go to Azure Virtual Desktop.
2. Navigate to the object (such as a host pool, app group, or workspace) that you
want to capture logs and events for.
3. Select Diagnostic settings in the menu on the left side of the screen.
4. Select Add diagnostic setting in the menu that appears on the right side of the
screen.
The options shown in the Diagnostic Settings page will vary depending on what
kind of object you're editing.
For example, when you're enabling diagnostics for an app group, you'll see options
to configure checkpoints, errors, and management. For workspaces, these
categories configure a feed to track when users subscribe to the list of apps. To
learn more about diagnostic settings see Create diagnostic setting to collect
resource logs and metrics in Azure.
） Important
Remember to enable diagnostics for each Azure Resource Manager object

that you want to monitor. Data will be available for activities after diagnostics
has been enabled. It might take a few hours after first set-up.
5. Enter a name for your settings configuration, then select Send to Log Analytics.
The name you use shouldn't have spaces and should conform to Azure naming
conventions. As part of the logs, you can select all the options that you want
added to your Log Analytics, such as Checkpoint, Error, Management, and so on.
6. Select Save.
７ Note
Log Analytics gives you the option to stream data to Event Hubs or archive it in a
storage account. To learn more about this feature, see Stream Azure monitoring
data to an event hub and Archive Azure resource logs to storage account.
How to access Log Analytics

You can access Log Analytics workspaces on the Azure portal or Azure Monitor.
Access Log Analytics on a Log Analytics workspace

2. Search for Log Analytics workspace.
3. Under Services, select Log Analytics workspaces.
4. From the list, select the workspace you configured for your Azure Virtual Desktop
object.
5. Once in your workspace, select Logs. You can filter out your menu list with the
Search function.
Access Log Analytics on Azure Monitor

1. Sign into the Azure portal
2. Search for and select Monitor.
3. Select Logs.
4. Follow the instructions in the logging page to set the scope of your query.
5. You are ready to query diagnostics. All diagnostics tables have a "WVD" prefix.
７ Note
For more detailed information about the tables stored in Azure Monitor Logs, see
the Azure Monitor data reference. All tables related to Azure Virtual Desktop are
prefixed with "WVD."
Cadence for sending diagnostic events

Diagnostic events are sent to Log Analytics when completed.
Log Analytics only reports in these intermediate states for connection activities:
Started: when a user selects and connects to an app or desktop in the Remote
Desktop client.
Connected: when the user successfully connects to the VM where the app or
desktop is hosted.
Completed: when the user or server disconnects the session the activity took place
in.
Example queries
Access example queries through the Azure Monitor Log Analytics UI:
1. Go to your Log Analytics workspace, and then select Logs. The example query UI is
shown automatically.
2. Change the filter to Category.
3. Select Azure Virtual Desktop to review available queries.
4. Select Run to run the selected query.
Learn more about the sample query interface in Saved queries in Azure Monitor Log
Analytics.
The following query list lets you review connection information or issues for a single
user. You can run these queries in the Log Analytics query editor. For each query, replace
userupn with the UPN of the user you want to look up.
To find all connections for a single user:
Kusto
WVDConnections
|where UserName == "userupn"
|take 100
|sort by TimeGenerated asc, CorrelationId
To find the number of times a user connected per day:
Kusto
WVDConnections
|where UserName == "userupn"
|take 100
|sort by TimeGenerated asc, CorrelationId
|summarize dcount(CorrelationId) by bin(TimeGenerated, 1d)
To find session duration by user:
Kusto
let Events = WVDConnections | where UserName == "userupn" ;
Events
| where State == "Connected"
| project CorrelationId , UserName, ResourceAlias , StartTime=TimeGenerated
| join (Events
| where State == "Completed"
| project EndTime=TimeGenerated, CorrelationId)
on CorrelationId
| project Duration = EndTime - StartTime, ResourceAlias
| sort by Duration asc
To find errors for a specific user:
Kusto
WVDErrors
| where UserName == "userupn"
|take 100
To find out whether a specific error occurred for other users:
Kusto
WVDErrors
| where CodeSymbolic =="ErrorSymbolicCode"
| summarize count(UserName) by CodeSymbolic
７ Note
When a user launches a full desktop session, their app usage in the session
isn't tracked as checkpoints in the WVDCheckpoints table.
The ResourcesAlias column in the WVDConnections table shows whether a
user has connected to a full desktop or a published app. The column only
shows the first app they open during the connection. Any published apps the
user opens are tracked in WVDCheckpoints .
The WVDErrors table shows you management errors, host registration issues,
and other issues that happen while the user subscribes to a list of apps or
desktops.
The WVDErrors table also helps you to identify issues that can be resolved by
admin tasks. The value on ServiceError should always equal false for these
types of issues. If ServiceError equals true , you'll need to escalate the issue
to Microsoft. Ensure you provide the CorrelationID for errors you escalate.
When debugging connectivity issues, in some cases client information might
be missing even if the connection events completes. This applies to the
WVDConnections and WVDCheckpoints tables.
Next steps
To review common error scenarios that the diagnostics feature can identify for you, see
Identify and diagnose issues.
Set up service alerts
） Important
You can use Azure Service Health to monitor service issues and health advisories for
Azure Virtual Desktop. Azure Service Health can notify you with different types of alerts
(for example, email or SMS), help you understand the effect of an issue, and keep you
updated as the issue resolves. Azure Service Health can also help you mitigate
downtime and prepare for planned maintenance and changes that could affect the
availability of your resources.
To learn more about Azure Service Health, see the Azure Health Documentation.
Create service alerts

This section shows you how to configure Azure Service Health and how to set up
notifications, which you can access on the Azure portal. You can set up different types of
alerts and schedule them to notify you in a timely manner.
Recommended service alerts

We recommend you create service alerts for the following health event types:
Service issue: Receive notifications on major issues that impact connectivity of

your users with the service or with the ability to manage Azure Virtual Desktop.
Health advisory: Receive notifications that require your attention. The following
are some examples of this type of notification:
Virtual Machines (VMs) not securely configured as open port 3389
Deprecation of functionality
Configure service alerts

To configure service alerts:

2. Select Service Health.
3. Follow the instructions in Create activity log alerts on service notifications to set up
your alerts and notifications.
Next steps
Learn how to configure Azure Virtual Desktop Insights.
How to resolve Azure Advisor
recommendations
This article describes how you can resolve recommendations that appear in Azure
Advisor for Azure Virtual Desktop.
“No validation environment enabled”
This recommendation appears under Operational Excellence. The recommendation

should also show you a warning message like this:
"You don't have a validation environment enabled in this subscription. When you made
your host pools, you selected No for "Validation environment" in the Properties tab. To
ensure business continuity through Azure Virtual Desktop service deployments, make
sure you have at least one host pool with a validation environment where you can test
for potential issues.”
You can make this warning message go away by enabling a validation environment in
one of your host pools.
To enable a validation environment:
1. Go to your Azure portal home page and select the host pool you want to change.
2. Next, select the host pool you want to change from a production environment to a
validation environment.
3. In your host pool, select Properties on the left column. Next, scroll down until you
see “Validation environment.” Select Yes, then select Apply.
These changes won't make the warning go away immediately, but it should disappear
eventually. Azure Advisor updates twice a day. Until then, you can postpone or dismiss
the recommendation manually. We recommend you let the recommendation go away
on its own. That way, Azure Advisor can let you know if it comes across any problems as
the settings change.
“Not enough production (non-validation)

environments enabled”
This recommendation appears under Operational Excellence.
For this recommendation, the warning message appears for one of these reasons:
You have too many host pools in your validation environment.

You don't have any production host pools.
We recommend users have fewer than half of their host pools in a validation
environment.
To resolve this warning:
1. Go to your Azure portal home page.
2. Select the host pools you want either want to change from validation to
production.
3. In your host pool, select the Properties tab in the column on the right side of the
screen. Next, scroll down until you see “Validation environment.” Select No, then
select Apply.
These changes won't make the warning go away immediately, but it should disappear
eventually. Azure Advisor updates twice a day. Until then, you can postpone or dismiss
the recommendation manually. We recommend you let the recommendation go away
on its own. That way, Azure Advisor can let you know if it comes across any problems as
the settings change.
“Not enough links are unblocked to

successfully implement your VM”
This recommendation appears under Operational Excellence.
You need to unblock specific URLs to make sure that your virtual machine (VM)
functions properly. You can see the list at Safe URL list. If the URLs aren't unblocked,
then your VM won't work properly.
To solve this recommendation, make sure you unblock all the URLs on the Safe URL list.
You can use Service Tag or FQDN tags to unblock URLs, too.
Next steps
If you're looking for more in-depth guides about how to resolve common issues, check
out Troubleshooting overview, feedback, and support for Azure Virtual Desktop.
Collect and query connection quality
data
） Important
The Connection Graphics Data Logs are currently in preview. See the Supplemental
Terms of Use for Microsoft Azure Previews for legal terms that apply to Azure
features that are in beta, preview, or otherwise not yet released into general
availability.
Connection quality is essential for good user experiences, so it's important to be able to
monitor connections for potential issues and troubleshoot problems as they arise. Azure
Virtual Desktop offers tools like Log Analytics that can help you monitor your
deployment's connection health. This article will show you how to configure your
diagnostic settings to let you collect connection quality data and query data for specific
parameters.
Prerequisites
To start collecting connection quality data, you’ll need to set up a Log Analytics
workspace.
７ Note
Normal storage charges for Log Analytics will apply. Learn more at Azure Monitor
Logs pricing details.
Configure diagnostics settings

To check and modify your diagnostics settings in the Azure portal:
1. Sign in to the Azure portal, then go to Azure Virtual Desktop and select Host
pools.
2. Select the host pool you want to collect network data for.
3. Select Diagnostic settings, then create a new setting if you haven't configured
your diagnostic settings yet. If you've already configured your diagnostic settings,
select Edit setting.
4. Select allLogs if you want to collect data for all tables. The allLogs parameter will
automatically add new tables to your data table in the future.
If you'd prefer to view more specific tables, first select Network Data Logs and
Connection Graphics Data Logs Preview, then select the names of the other tables
you want to see.
5. Select where you want to send the collected data. Azure Virtual Desktop Insights
users should select a Log Analytics workspace.
6. Select Save to apply your changes.
7. Repeat this process for all other host pools you want to measure.
8. To check network data, return to the host pool's resource page, select Logs, then
run one of the queries in Sample queries for Azure Log Analytics. In order for your
query to get results, your host pool must have active users who've connected to
sessions before. Keep in mind that it can take up to 15 minutes for network data to
appear in the Azure portal.
Sample queries for Azure Log Analytics:

network data
In this section, we have a list of queries that will help you review connection quality
information. You can run queries in the Log Analytics query editor.
７ Note
For each example, replace the userupn variable with the UPN of the user you want
to look up.
Query average RTT and bandwidth

To look up the average round trip time and bandwidth:
Kusto
// 90th, 50th, 10th Percentile for RTT in 10 min increments
WVDConnectionNetworkData
| summarize
RTTP90=percentile(EstRoundTripTimeInMs,90),RTTP50=percentile(EstRoundTripTim
eInMs,50),RTTP10=percentile(EstRoundTripTimeInMs,10) by
bin(TimeGenerated,10m)
| render timechart
// 90th, 50th, 10th Percentile for BW in 10 min increments
| summarize
BWP90=percentile(EstAvailableBandwidthKBps,90),BWP50=percentile(EstAvailable
BandwidthKBps,50),BWP10=percentile(EstAvailableBandwidthKBps,10) by
bin(TimeGenerated,10m)
| render timechart
To look up the round-trip time and bandwidth per connection:
Kusto
// RTT and BW Per Connection Summary
// Returns P90 Round Trip Time (ms) and Bandwidth (KBps) per connection with
connection details.
| summarize
RTTP90=percentile(EstRoundTripTimeInMs,90),BWP90=percentile(EstAvailableBand
widthKBps,90),StartTime=min(TimeGenerated), EndTime=max(TimeGenerated) by
CorrelationId
| join kind=leftouter (
WVDConnections
| extend Protocol = iff(UdpUse in ("0","<>"),"TCP","UDP")
| distinct CorrelationId, SessionHostName, Protocol, ClientOS, ClientType,

ClientVersion, ConnectionType, ResourceAlias, SessionHostSxSStackVersion,
UserName
) on CorrelationId
| project CorrelationId, StartTime, EndTime, UserName, SessionHostName,

RTTP90, BWP90, Protocol, ClientOS, ClientType, ClientVersion,
ConnectionType, ResourceAlias, SessionHostSxSStackVersion
Query data for a specific user

To look up the bandwidth for a specific user:
Kusto
let user = "alias@domain";
WVDConnections
| distinct CorrelationId, UserName
) on CorrelationId
| where UserName == user
| project EstAvailableBandwidthKBps, TimeGenerated
| render columnchart
To look up the round trip time for a specific user:
Kusto
let user = "alias@domain";
WVDConnections
) on CorrelationId
| where UserName == user
| project EstRoundTripTimeInMs, TimeGenerated
| render columnchart
To look up the top 10 users with the highest round trip time:
Kusto
WVDConnections
) on CorrelationId
| summarize
AvgRTT=avg(EstRoundTripTimeInMs),RTT_P95=percentile(EstRoundTripTimeInMs,95)
by UserName
| top 10 by AvgRTT desc
To look up the 10 users with the lowest bandwidth:
Kusto
WVDConnections
) on CorrelationId
| summarize
AvgBW=avg(EstAvailableBandwidthKBps),BW_P95=percentile(EstAvailableBandwidth
KBps,95) by UserName
| top 10 by AvgBW asc
Next steps
Learn more about connection quality at Connection quality in Azure Virtual Desktop.
Troubleshooting overview, feedback,
and support for Azure Virtual Desktop
） Important
This article provides an overview of the issues you may encounter when setting up an
Azure Virtual Desktop environment and provides ways to resolve the issues.
Troubleshoot deployment and connection

issues
Azure Virtual Desktop Insights is a dashboard built on Azure Monitor workbooks that
can quickly troubleshoot and identify issues in your Azure Virtual Desktop environment
for you. If you prefer working with Kusto queries, we recommend using the built-in
diagnostic feature, Log Analytics, instead.
Report issues
To report issues or suggest features for Azure Virtual Desktop with Azure Resource
Manager integration, visit the Azure Virtual Desktop Tech Community . You can use the
Tech Community to discuss best practices or suggest and vote for new features.
When you make a post asking for help or propose a new feature, make sure you
describe your topic in as much detail as possible. Detailed information can help other
users answer your question or understand the feature you're proposing a vote for.
Escalation tracks
Before doing anything else, make sure to check the Azure status page and Azure
Service Health to make sure your Azure service is running properly.
Use the following table to identify and resolve issues you may encounter when setting
up an environment using Remote Desktop client. Once your environment's set up, you
can use our new Diagnostics service to identify issues for common scenarios.
Issue Suggested Solution
Session host pool Azure Open an Azure support request , then select the appropriate service
Virtual Network (VNET) (under the Networking category).
and Express Route
settings
Session host pool Virtual Open an Azure support request , then select Azure Virtual Desktop
Machine (VM) creation for the service.
when Azure Resource

Manager templates For issues with the Azure Resource Manager templates that are
provided with Azure provided with Azure Virtual Desktop, see Azure Resource Manager
Virtual Desktop aren't template errors section of Host pool creation.
being used
Managing Azure Virtual Open an Azure support request .
Desktop session host

environment from the For management issues when using Remote Desktop Services/Azure
Azure portal Virtual Desktop PowerShell, see Azure Virtual Desktop PowerShell or
open an Azure support request , select Azure Virtual Desktop for
the service, select Configuration and management for the problem
type, then select Issues configuring environment using PowerShell
for the problem subtype.
Managing Azure Virtual See Azure Virtual Desktop PowerShell, or open an Azure support
Desktop configuration request , select Azure Virtual Desktop for the service, then select
tied to host pools and the appropriate problem type.
application groups (app
groups)
Deploying and manage See Troubleshooting guide for FSLogix products and if that doesn't
FSLogix Profile Containers resolve the issue, Open an Azure support request , select Azure
Virtual Desktop for the service, select FSLogix for the problem type,
then select the appropriate problem subtype.
Remote desktop clients See Troubleshoot the Remote Desktop client and if that doesn't
malfunction on start resolve the issue, Open an Azure support request , select Azure
Virtual Desktop for the service, then select Remote Desktop clients
for the problem type.
If it's a network issue, your users need to contact their network

administrator.
Issue Suggested Solution
Connected but no feed Troubleshoot using the User connects but nothing is displayed (no
feed) section of Azure Virtual Desktop service connections.
If your users have been assigned to an app group, open an Azure

support request , select Azure Virtual Desktop for the service, then
select Remote Desktop Clients for the problem type.
Feed discovery problems Your users need to contact their network administrator.
due to the network
Connecting clients See Azure Virtual Desktop service connections and if that doesn't
solve your issue, see Session host virtual machine configuration.
Responsiveness of remote If issues are tied to a specific application or product, contact the
applications or desktop team responsible for that product.
Licensing messages or If issues are tied to a specific application or product, contact the
errors team responsible for that product.
Issues with third-party Verify that your third-party provider supports Azure Virtual Desktop
authentication methods scenarios and approach them regarding any known issues.
or tools
Issues using Log Analytics For issues with the diagnostics schema, open an Azure support
for Azure Virtual Desktop request .
For queries, visualization, or other issues in Log Analytics, select the

appropriate problem type under Log Analytics.
Issues using Microsoft Contact the Microsoft 365 admin center with one of the Microsoft
365 apps 365 admin center help options.
Next steps
To troubleshoot issues while creating a host pool in an Azure Virtual Desktop
environment, see host pool creation.
To troubleshoot issues while configuring a virtual machine (VM) in Azure Virtual
Desktop, see Session host virtual machine configuration.
To troubleshoot issues related to the Azure Virtual Desktop agent or session
connectivity, see Troubleshoot common Azure Virtual Desktop Agent issues.
To troubleshoot issues with Azure Virtual Desktop client connections, see Azure
Virtual Desktop service connections.
To troubleshoot issues with Remote Desktop clients, see Troubleshoot the Remote
Desktop client
To troubleshoot issues when using PowerShell with Azure Virtual Desktop, see
Azure Virtual Desktop PowerShell.
To learn more about the service, see Azure Virtual Desktop environment.
To go through a troubleshoot tutorial, see Tutorial: Troubleshoot Resource
Manager template deployments.
To learn about auditing actions, see Audit operations with Resource Manager.
To learn about actions to determine errors during deployment, see View
deployment operations.
Troubleshoot the Azure Virtual Desktop
getting started feature
The Azure Virtual Desktop getting started feature uses nested templates to deploy
Azure resources for validation and automation in Azure Virtual Desktop. The getting
started feature creates either two or three resource groups based on whether the
subscription it's running on has existing Active Directory Domain Services (AD DS) or
Azure Active Directory Domain Services (Azure AD DS) or not. All resource groups start
with the same user-defined prefix.
When you run the nested templates, they create three resource groups and a template
that provisions Azure Resource Manager resources. The following lists show each
resource group and the templates they run.
The resource group that ends in "-deployment" runs these templates:
easy-button-roleassignment-job-linked-template
easy-button-prerequisitecompletion-job-linked-template
easy-button-prerequisite-job-linked-template
easy-button-inputvalidation-job-linked-template
easy-button-deploymentResources-linked-template
easy-button-prerequisite-user-setup-linked-template
７ Note
The easy-button-prerequisite-user-setup-linked-template is optional and will only

appear if you created a validation user.
The resource group that ends in "-wvd" runs these templates:
NSG-linkedTemplate
vmCreation-linkedTemplate
Workspace-linkedTemplate
wvd-resources-linked-template
easy-button-wvdsetup-linked-template
The resource group that ends in "-prerequisite" runs these templates:
easy-button-prerequisite-resources-linked-template
７ Note
This resource group is optional, and will only appear if your subscription doesn't
have Azure AD DS or AD DS.
No subscriptions
In this issue, you see an error message that says "no subscriptions" when opening the
getting started feature. This happens when you try to open the feature without an active
Azure subscription.
To fix this issue, check to see if your subscription or the affected user has an active Azure
subscription. If they don't, assign the user the Owner Role-based Access Control (RBAC)
role on their subscription.
You don’t have permissions

This issue happens when you open the getting started feature and get an error message
that says, "You don't have permissions." This message appears when the user running
the feature doesn't have Owner permissions on their active Azure subscription.
To fix this issue, sign in with an Azure account that has Owner permissions, then assign
the Owner RBAC role to the affected account.
Fields under Virtual Machine tab are grayed

out
This issue happens when you open the Virtual machine tab and see that the fields
under "Do you want users to share this machine?" are grayed out. This issue then
prevents you from changing the image type, selecting an image to use, or changing the
VM size.
This issue happens when you run the feature with a prefix that was already used to start
a deployment. When the feature creates a deployment, it creates an object to represent
the deployment in Azure. Certain values in the object, like the image, become attached
to that object to prevent multiple objects from using the same images.
To fix this issue, you can either delete all resource groups with the existing prefix or use
a new prefix.
Username must not include reserved words
This issue happens when the getting started feature won't accept the new username you
enter into the field.
This error message appears because Azure doesn't allow certain words in usernames for
public endpoints. For a full list of blocked words, see Resolve reserved resource name
errors.
To resolve this issue, either try a new word or add letters to the blocked word to make it
unique. For example, if the word "admin" is blocked, try using "AVDadmin" instead.
The value must be between 12 and 72

characters long
This error message appears when entering a password that is either too long or too
short to meet the character length requirement. Azure password length and complexity
requirements even apply to fields that you later use in Windows, which has less strict
requirements.
To resolve this issue, make sure you use an account that follows Microsoft's password
guidelines or uses Azure AD Password Protection.
Error messages for easy-button-prerequisite-

user-setup-linked-template
If the AD DS VM you're using already has an extension named Microsoft.Powershell.DSC
associated with it, you'll see an error message that looks like this:
azure
"error": {
"code": "DeploymentFailed",
"message": "At least one resource deployment operation failed.

Please list deployment operations for details. Please see
https://aka.ms/DeployOperations for usage details.",
"details": [
"code": "Conflict",
"message": "{\r\n \"status\": \"Failed\",\r\n \"error\":

{\r\n \"code\": \"ResourceDeploymentFailure\",\r\n \"message\": \"The
resource operation completed with terminal provisioning state
'Failed'.\",\r\n \"details\": [\r\n {\r\n \"code\":
\"VMExtensionProvisioningError\",\r\n \"message\": \"VM has reported
a failure when processing extension 'Microsoft.Powershell.DSC'. Error
message: \\\"DSC Configuration 'AddADDSUser' completed with error(s).
Following are the first few: PowerShell DSC resource MSFT_ScriptResource
failed to execute Set-TargetResource functionality with error message: Some
error occurred in DSC CreateUser SetScript: \\r\\n\\r\\nException
: Microsoft.ActiveDirectory.Management.ADIdentityNotFoundException: Cannot
find an object with \\r\\n identity: 'Adam S' under:
'DC=GT090617,DC=onmicrosoft,DC=com'.\\r\\n at
Microsoft.ActiveDirectory.Management.Commands.ADFactoryUtil.GetObjectFromIde
ntitySearcher(\\r\\n ADObjectSearcher searcher,
ADEntity identityObj, String searchRoot, AttributeSetRequest attrs, \\r\\n
CmdletSessionInfo cmdletSessionInfo, String[]& warningMessages)\\r\\n
at \\r\\n
Microsoft.ActiveDirectory.Management.Commands.ADFactory`1.GetDirectoryObject
FromIdentity(T \\r\\n identityObj, String searchRoot,
Boolean showDeleted)\\r\\n at \\r\\n
Microsoft.ActiveDirectory.Management.Commands.SetADGroupMember`1.ValidateMem
bersParameter()\\r\\nTargetObject : Adam S\\r\\nCategoryInfo
: ObjectNotFound: (Adam S:ADPrincipal) [Add-ADGroupMember],
ADIdentityNotFoundException\\r\\nFullyQualifiedErrorId :
SetADGroupMember.ValidateMembersParameter,Microsoft.ActiveDirectory.Manageme
nt.Commands.AddADGro\\r\\n upMember\\r\\nErrorDetails
: \\r\\nInvocationInfo :
System.Management.Automation.InvocationInfo\\r\\nScriptStackTrace : at
<ScriptBlock>,
C:\\\\Packages\\\\Plugins\\\\Microsoft.Powershell.DSC\\\\2.83.1.0\\\\DSCWork
\\\\DSCADUserCreatio\\r\\n nScripts_2020-04-
28.2\\\\Script-CreateADDSUser.ps1: line 98\\r\\n at
<ScriptBlock>, <No file>: line 8\\r\\n at
ScriptExecutionHelper,
C:\\\\Windows\\\\system32\\\\WindowsPowerShell\\\\v1.0\\\\Modules\\\\PSDesir
edStateConfi\\r\\n
guration\\\\DscResources\\\\MSFT_ScriptResource\\\\MSFT_ScriptResource.psm1:
line 270\\r\\n at Set-TargetResource,
C:\\\\Windows\\\\system32\\\\WindowsPowerShell\\\\v1.0\\\\Modules\\\\PSDesir
edStateConfigur\\r\\n
ation\\\\DscResources\\\\MSFT_ScriptResource\\\\MSFT_ScriptResource.psm1:
line 144\\r\\nPipelineIterationInfo : {}\\r\\nPSMessageDetails :
\\r\\n\\r\\n\\r\\n\\r\\n The SendConfigurationApply function did not
succeed.\\\"\\r\\n\\r\\nMore information on troubleshooting is available at
https://aka.ms/VMExtensionDSCWindowsTroubleshoot \"\r\n }\r\n ]\r\n
}\r\n}"
To resolve this issue, uninstall the Microsoft.Powershell.DSC extension, then run the
getting started feature again.
Error messages for easy-button-prerequisite-
job-linked-template
If you see an error message like this, that means the resource operation for the easy-
button-prerequisite-job-linked-template template didn't complete successfully:
azure
"status": "Failed",
"error": {
"message": "At least one resource deployment operation failed.

Please list deployment operations for details. Please see
https://aka.ms/DeployOperations for usage details.",
"details": [
"code": "Conflict",
"message": "{\r\n \"status\": \"Failed\",\r\n \"error\":

resource operation completed with terminal provisioning state
'Failed'.\"\r\n }\r\n}"
To make sure this is the issue you're dealing with:
1. Select easy-button-prerequisite-job-linked-template, then select Ok on the error

message window that pops up.
2. Go to <prefix>-deployment resource group and select resourceSetupRunbook.
3. Select the status, which should say Failed.
4. Select the Exception tab. You should see an error message that looks like this:
azure
The running command stopped because the preference variable

"ErrorActionPreference" or common parameter is set to Stop: Error while
creating and adding validation user <your-username-here> to group
<your-resource-group-here>
There currently isn't a way to fix this issue permanently. As a workaround, run The Azure
Virtual Desktop getting started feature again, but this time don't create a validation
user. After that, create your new users with the manual process only.
Validate that the domain administrator UPN exists for a

new profile
To check if the UPN address is causing the issue with the template:
1. Select easy-button-prerequisite-job-linked-template and then on the failed step.

Confirm the error message.
2. Navigate to the <prefix>-deployment resource group and click on the

resourceSetupRunbook.
3. Select the status, which should say Failed.
4. Select the Output tab.
If the UPN exists on your new subscription, there are two potential causes for the issue:
The getting started feature didn't create the domain administrator profile, because
the user already exists. To resolve this, run the getting started feature again, but
this time enter a username that doesn't already exist in your identity provider.
The getting started feature didn't create the validation user profile. To resolve this
issue, run the getting started feature again, but this time don't create any
validation users. After that, create new users with the manual process only.
Error messages for easy-button-

inputvalidation-job-linked-template
If there's an issue with the easy-button-inputvalidation-job-linked-template template,
you'll see an error message that looks like this:
azure
"status": "Failed",
"error": {
"code": "ResourceDeploymentFailure",
"message": "The resource operation completed with terminal

provisioning state 'Failed'."
To make sure this is the issue you've encountered:

1. Open the <prefix>-deployment resource group and look for
inputValidationRunbook.
2. Under recent jobs there will be a job with failed status. Click on Failed.
3. In the job details window, select Exception.
This error happens when the Azure admin UPN you entered isn't correct. To resolve this
issue, make sure you're entering the correct username and password, then try again.
Multiple VMExtensions per handler not

supported
When you run the getting started feature on a subscription that has Azure AD DS or AD
DS, then the feature will use a Microsoft.Powershell.DSC extension to create validation
users and configure FSLogix. However, Windows VMs in Azure can't run more than one
of the same type of extension at the same time.
If you try to run multiple versions of Microsoft.Powershell.DSC, you'll get an error

message that looks like this:
azure
"status": "Failed",
"error": {
"code": "BadRequest",
"message": "Multiple VMExtensions per handler not supported for OS

type 'Windows'. VMExtension 'Microsoft.Powershell.DSC' with handler
'Microsoft.Powershell.DSC' already added or specified in input."
To resolve this issue, before you run the getting started feature, make sure to remove
any currently running instance of Microsoft.Powershell.DSC from the domain controller
VM.
Failure in easy-button-prerequisitecompletion-
job-linked-template
The user group for the validation users is located in the "USERS" container. However, the
user group must be synced to Azure AD in order to work properly. If it isn't, you'll get an
error message that looks like this:
azure
"status": "Failed",
"error": {
"code": "ResourceDeploymentFailure",
"message": "The resource operation completed with terminal

provisioning state ‘Failed’."
To make sure the issue is caused by the validation user group not syncing, open the
<prefix>-prerequisites resource group and look for a file named
prerequisiteSetupCompletionRunbook. Select the runbook, then select All Logs.
To resolve this issue:
1. Enable syncing with Azure AD for the "USERS" container.
2. Create the AVDValidationUsers group in an organization unit that's syncing with

Azure.
Next steps
Learn more about the getting started feature at Deploy Azure Virtual Desktop with the
getting started feature.
Host pool creation
） Important
This article covers issues during the initial setup of the Azure Virtual Desktop tenant and
the related session host pool infrastructure.
Provide feedback
Visit the Azure Virtual Desktop Tech Community to discuss the Azure Virtual Desktop
service with the product team and active community members.
Acquiring the Windows 10 Enterprise multi-

session image
To use the Windows 10 Enterprise multi-session image, go to the Azure Marketplace,
select Get Started > Microsoft Windows 10 > and Windows 10 Enterprise multi-session,
Version 1809 .
Issues with using the Azure portal to create

host pools
Error: "Create a free account" appears when accessing the

service
Cause: There aren't active subscriptions in the account you signed in to Azure with, or
the account doesn't have permissions to view the subscriptions.
Fix: Sign in to the subscription where you'll deploy the session host virtual machines
(VMs) with an account that has at least contributor-level access.
Error: "Exceeding quota limit"

If your operation goes over the quota limit, you can do one of the following things:
Create a new host pool with the same parameters but fewer VMs and VM cores.
Open the link you see in the statusMessage field in a browser to submit a request
to increase the quota for your Azure subscription for the specified VM SKU.
Error: Can't see user assignments in app groups.

Cause: This error usually happens after you've moved the subscription from one Azure
Active Directory tenant to another. If your old assignments are still tied to the previous
Azure Active Directory tenant, the Azure portal will lose track of them.
Fix: You'll need to reassign users to app groups.
I don't see the Azure region I want to use when selecting

the location for my service objects
Cause: Azure doesn't currently support that region for the Azure Virtual Desktop service.
To learn about which geographies we support, check out Data locations. If Azure Virtual
Desktop supports the location but it still doesn't appear when you're trying to select a
location, that means your resource provider hasn't updated yet.
Fix: To get the latest list of regions, re-register the resource provider:
1. Go to Subscriptions and select the relevant subscription.

2. Select Resource Provider.
3. Select Microsoft.DesktopVirtualization, then select Re-register from the action
menu.
When you re-register the resource provider, you won't see any specific UI feedback or
update statuses. The re-registration process also won't interfere with your existing
environments.
Azure Resource Manager template errors

Follow these instructions to troubleshoot unsuccessful deployments of Azure Resource
Manager templates and PowerShell DSC.
1. Review errors in the deployment using View deployment operations with Azure
Resource Manager.
2. If there are no errors in the deployment, review errors in the activity log using View
activity logs to audit actions on resources.
3. Once the error is identified, use the error message and the resources in
Troubleshoot common Azure deployment errors with Azure Resource Manager to
address the issue.
4. Delete any resources created during the previous deployment and retry deploying
the template again.
Error: Your deployment failed….<hostname>/joindomain

Example of raw error:
Error
{"code":"DeploymentFailed","message":"At least one resource deployment

operation failed. Please list deployment operations for details.
Please see https://aka.ms/arm-debug for usage details.","details":

[{"code":"Conflict","message":"{\r\n \"status\": \"Failed\",\r\n \"error\":

resource operation completed with terminal provisioning state 'Failed'.
\",\r\n \"details\": [\r\n {\r\n \"code\":

\"VMExtensionProvisioningError\",\r\n \"message\": \"VM has reported a
failure when processing
extension 'joindomain'. Error message: \\\"Exception(s) occurred while

joining Domain 'diamondsg.onmicrosoft.com'\\\".\"\r\n }\r\n ]\r\n }\r\n}"}]}
Cause 1: Credentials provided for joining VMs to the domain are incorrect.
Fix 1: See the "Incorrect credentials" error for VMs are not joined to the domain in
Session host VM configuration.
Cause 2: Domain name doesn't resolve.
Fix 2: See Error: Domain name doesn't resolve in Session host VM configuration.
Cause 3: Your virtual network (VNET) DNS configuration is set to Default.
To fix this, do the following things:
1. Open the Azure portal and go to the Virtual networks tab.

2. Find your VNET, then select DNS servers.
3. The DNS servers menu should appear on the right side of your screen. On that
menu, select Custom.
4. Make sure the DNS servers listed under Custom match your domain controller or
Active Directory domain. If you don't see your DNS server, you can add it by
entering its value into the Add DNS server field.
Error: Your deployment failed...\Unauthorized

Error

operation failed. Please list deployment operations for details. Please see
https://aka.ms/arm-debug for usage details.","details":
[{"code":"Unauthorized","message":"{\r\n \"Code\": \"Unauthorized\",\r\n
\"Message\": \"The scale operation is not allowed for this subscription in
this region. Try selecting different region or scale option.\",\r\n
\"Target\": null,\r\n \"Details\": [\r\n {\r\n \"Message\": \"The scale
operation is not allowed for this subscription in this region. Try selecting
different region or scale option.\"\r\n },\r\n {\r\n \"Code\":
\"Unauthorized\"\r\n },\r\n {\r\n \"ErrorEntity\": {\r\n \"ExtendedCode\":
\"52020\",\r\n \"MessageTemplate\": \"The scale operation is not allowed for
this subscription in this region. Try selecting different region or scale
option.\",\r\n \"Parameters\": [\r\n \"default\"\r\n ],\r\n \"Code\":
\"Unauthorized\",\r\n \"Message\": \"The scale operation is not allowed for
this subscription in this region. Try selecting different region or scale
option.\"\r\n }\r\n }\r\n ],\r\n \"Innererror\": null\r\n}"}]}
Cause: The subscription you're using is a type that can't access required features in the
region where the customer is trying to deploy. For example, MSDN, Free, or Education
subscriptions can show this error.
Fix: Change your subscription type or region to one that can access the required
features.
Error: VMExtensionProvisioningError
Cause 1: Transient error with the Azure Virtual Desktop environment.
Cause 2: Transient error with connection.
Fix: Confirm Azure Virtual Desktop environment is healthy by signing in using

PowerShell. Finish the VM registration manually in Create a host pool with PowerShell.
Error: The Admin Username specified isn't allowed

Error
{ …{ "provisioningOperation":
"Create", "provisioningState": "Failed", "timestamp": "2019-01-

29T20:53:18.904917Z", "duration": "PT3.0574505S", "trackingId":
"1f460af8-34dd-4c03-9359-9ab249a1a005", "statusCode": "BadRequest",

"statusMessage": { "error": { "code": "InvalidParameter", "message":
"The Admin Username specified is not allowed.", "target": "adminUsername" }

… }
Cause: Password provided contains forbidden substrings (admin, administrator, root).
Fix: Update username or use different users.
Error: VM has reported a failure when processing

extension
Error
{ … "code": "ResourceDeploymentFailure", "message":
"The resource operation completed with terminal provisioning state

'Failed'.", "details": [ { "code":
"VMExtensionProvisioningError", "message": "VM has reported a failure when

processing extension 'dscextension'.
Error message: \"DSC Configuration 'SessionHost' completed with error(s).

Following are the first few:
PowerShell DSC resource MSFT_ScriptResource failed to execute Set-

TargetResource functionality with error message:
One or more errors occurred. The SendConfigurationApply function did not

succeed.\"." } ] … }
Cause: PowerShell DSC extension was not able to get admin access on the VM.
Fix: Confirm username and password have administrative access on the virtual machine
and run the Azure Resource Manager template again.
Error: DeploymentFailed – PowerShell DSC Configuration

'FirstSessionHost' completed with Error(s)
Error
"message": "At least one resource deployment operation failed. Please

list
deployment operations for details. 4 Please see https://aka.ms/arm-debug

for usage details.",
"details": [
{ "code": "Conflict",
"message": "{\r\n \"status\": \"Failed\",\r\n \"error\": {\r\n

\"code\":
\"ResourceDeploymentFailure\",\r\n \"message\": \"The resource
operation completed with terminal provisioning state

'Failed'.\",\r\n
\"details\": [\r\n {\r\n \"code\":
\"VMExtensionProvisioningError\",\r\n \"message\": \"VM has
reported a failure when processing extension 'dscextension'.
Error message: \\\"DSC Configuration 'FirstSessionHost'
completed with error(s). Following are the first few:
PowerShell DSC resource MSFT ScriptResource failed to
execute Set-TargetResource functionality with error message:
One or more errors occurred. The SendConfigurationApply
function did not succeed.\\\".\"\r\n }\r\n ]\r\n }\r\n}" }
Cause: PowerShell DSC extension was not able to get admin access on the VM.
Fix: Confirm username and password provided have administrative access on the virtual
machine and run the Azure Resource Manager template again.
Error: DeploymentFailed – InvalidResourceReference

Error
operation
failed. Please list deployment operations for details. Please see

https://aka.ms/arm-
debug for usage details.","details":[{"code":"Conflict","message":"{\r\n

\"status\":
\"Failed\",\r\n \"error\": {\r\n \"code\":

\"ResourceDeploymentFailure\",\r\n
\"message\": \"The resource operation completed with terminal provisioning

state

\"DeploymentFailed\",\r\n
\"message\": \"At least one resource deployment operation failed. Please

list
deployment operations for details. Please see https://aka.ms/arm-debug for

usage
details.\",\r\n \"details\": [\r\n {\r\n \"code\": \"BadRequest\",\r\n

\"message\":
\"{\\r\\n \\\"error\\\": {\\r\\n \\\"code\\\":

\\\"InvalidResourceReference\\\",\\r\\n
\\\"message\\\": \\\"Resource /subscriptions/EXAMPLE/resourceGroups/ernani-

wvd-
demo/providers/Microsoft.Network/virtualNetworks/wvd-vnet/subnets/default
referenced by resource /subscriptions/EXAMPLE/resourceGroups/ernani-wvd-
demo/providers/Microsoft.Network/networkInterfaces/erd. Please make sure

that
the referenced resource exists, and that both resources are in the same
region.\\\",\\r\\n\\\"details\\\": []\\r\\n }\\r\\n}\"\r\n }\r\n ]\r\n }\r\n

]\r\n }\r\n}"}]}
Cause: Part of the resource group name is used for certain resources being created by
the template. Due to the name matching existing resources, the template may select an
existing resource from a different group.
Fix: When running the Azure Resource Manager template to deploy session host VMs,
make the first two characters unique for your subscription resource group name.
Error: DeploymentFailed – InvalidResourceReference

Error

operation
failed. Please list deployment operations for details. Please see

https://aka.ms/arm-
debug for usage details.","details":[{"code":"Conflict","message":"{\r\n

\"status\":
\"Failed\",\r\n \"error\": {\r\n \"code\":

\"ResourceDeploymentFailure\",\r\n
\"message\": \"The resource operation completed with terminal provisioning

state

\"DeploymentFailed\",\r\n
\"message\": \"At least one resource deployment operation failed. Please

list
deployment operations for details. Please see https://aka.ms/arm-debug for

usage
details.\",\r\n \"details\": [\r\n {\r\n \"code\": \"BadRequest\",\r\n

\"message\":
\"{\\r\\n \\\"error\\\": {\\r\\n \\\"code\\\":

\\\"InvalidResourceReference\\\",\\r\\n
\\\"message\\\": \\\"Resource /subscriptions/EXAMPLE/resourceGroups/ernani-

wvd-
demo/providers/Microsoft.Network/virtualNetworks/wvd-vnet/subnets/default
referenced by resource
/subscriptions/EXAMPLE/resourceGroups/DEMO/providers/Microsoft.Network/netwo
rkInterfaces
/EXAMPLE was not found. Please make sure that the referenced resource
exists, and that both
resources are in the same region.\\\",\\r\\n \\\"details\\\": []\\r\\n

}\\r\\n}\"\r\n
}\r\n ]\r\n }\r\n ]\r\n }\r\n\
Cause: This error is because the NIC created with the Azure Resource Manager template
has the same name as another NIC already in the VNET.
Fix: Use a different host prefix.
Error: DeploymentFailed – Error downloading

Error
\\\"The DSC Extension failed to execute: Error downloading
https://catalogartifact.azureedge.net/publicartifacts/rds.wvd-provision-
host-pool-
2dec7a4d-006c-4cc0-965a-02bbe438d6ff-prod
/Artifacts/DSC/Configuration.zip after 29 attempts: The remote name could

not be
resolved: 'catalogartifact.azureedge.net'.\\nMore information about the

failure can
be found in the logs located under
'C:\\\\WindowsAzure\\\\Logs\\\\Plugins\\\\Microsoft.Powershell.DSC\\\\2.77.0
.0' on
the VM.\\\"
Cause: This error is due to a static route, firewall rule, or NSG blocking the download of
the zip file tied to the Azure Resource Manager template.
Fix: Remove blocking static route, firewall rule, or NSG. Optionally, open the Azure
Resource Manager template json file in a text editor, take the link to zip file, and
download the resource to an allowed location.
Error: Can't delete a session host from the host pool after
deleting the VM
Cause: You need to delete the session host before you delete the VM.
Fix: Put the session host in drain mode, sign out all users from the session host, then
delete the host.
Next steps
For an overview on troubleshooting Azure Virtual Desktop and the escalation
tracks, see Troubleshooting overview, feedback, and support.
Desktop client
To learn about actions to determine the errors during deployment, see View
Session host virtual machine
configuration
） Important
Use this article to troubleshoot issues you're having when configuring the Azure Virtual
Desktop session host virtual machines (VMs).
Provide feedback
VMs aren't joined to the domain

Follow these instructions if you're having issues joining virtual machines (VMs) to the
domain.
Join the VM manually using the process in Join a Windows Server virtual machine
to a managed domain or using the domain join template .
Try pinging the domain name from a command line on the VM.
Review the list of domain join error messages in Troubleshooting Domain Join
Error Messages .
Error: Incorrect credentials

Cause: There was a typo made when the credentials were entered in the Azure Resource
Manager template interface fixes.
Fix: Take one of the following actions to resolve.
Manually add the VMs to a domain.

Redeploy the template once credentials have been confirmed. See Create a host
pool with PowerShell.
Join VMs to a domain using a template with Joins an existing Windows VM to AD
Domain .
Error: Timeout waiting for user input

Cause: The account used to complete the domain join may have multifactor
authentication (MFA).
Temporarily remove MFA for the account.

Use a service account.
Error: The account used during provisioning doesn't have

permissions to complete the operation
Cause: The account being used doesn't have permissions to join VMs to the domain due
to compliance and regulations.
Use an account that is a member of the Administrator group.

Grant the necessary permissions to the account being used.
Error: Domain name doesn't resolve

Cause 1: VMs are on a virtual network that's not associated with the virtual network
(VNET) where the domain is located.
Fix 1: Create VNET peering between the VNET where VMs were provisioned and the
VNET where the domain controller (DC) is running. See Create a virtual network peering
- Resource Manager, different subscriptions.
Cause 2: When using Azure Active Directory Domain Services (Azure AD DS), the virtual
network doesn't have its DNS server settings updated to point to the managed domain
controllers.
Fix 2: To update the DNS settings for the virtual network containing Azure AD DS, see
Update DNS settings for the Azure virtual network.
Cause 3: The network interface's DNS server settings don't point to the appropriate DNS
server on the virtual network.
Fix 3: Take one of the following actions to resolve, following the steps in [Change DNS
servers].
Change the network interface's DNS server settings to Custom with the steps from
Change DNS servers and specify the private IP addresses of the DNS servers on the
virtual network.
Change the network interface's DNS server settings to Inherit from virtual
network with the steps from Change DNS servers, then change the virtual
network's DNS server settings with the steps from Change DNS servers.
Azure Virtual Desktop Agent and Azure Virtual

Desktop Boot Loader aren't installed
The recommended way to provision VMs is using the Azure portal creation template.
The template automatically installs the Azure Virtual Desktop Agent and Azure Virtual
Desktop Agent Boot Loader.
Follow these instructions to confirm the components are installed and to check for error
messages.
1. Confirm that the two components are installed by checking in Control Panel >
Programs > Programs and Features. If Azure Virtual Desktop Agent and Azure
Virtual Desktop Agent Boot Loader aren't visible, they aren't installed on the VM.
2. Open File Explorer and navigate to C:\Windows\Temp\ScriptLog.log. If the file is
missing, it indicates that the PowerShell DSC that installed the two components
wasn't able to run in the security context provided.
3. If the file C:\Windows\Temp\ScriptLog.log is present, open it and check for error
messages.
Error: Azure Virtual Desktop Agent and Azure Virtual

Desktop Agent Boot Loader are missing.
C:\Windows\Temp\ScriptLog.log is also missing
Cause 1: Credentials provided during input for the Azure Resource Manager template
were incorrect or permissions were insufficient.
Fix 1: Manually add the missing components to the VMs using Create a host pool with
PowerShell.
Cause 2: PowerShell DSC was able to start and execute but failed to complete as it can't
sign in to Azure Virtual Desktop and obtain needed information.
Fix 2: Confirm the items in the following list.
Make sure the account doesn't have MFA.

Confirm the host pool's name is accurate and the host pool exists in Azure Virtual
Desktop.
Confirm the account has at least Contributor permissions on the Azure
subscription or resource group.
Error: Authentication failed, error in

C:\Windows\Temp\ScriptLog.log
Cause: PowerShell DSC was able to execute but couldn't connect to Azure Virtual
Desktop.
Fix: Confirm the items in the following list.
Manually register the VMs with the Azure Virtual Desktop service.
Confirm account used for connecting to Azure Virtual Desktop has permissions on
the Azure subscription or resource group to create host pools.
Confirm account doesn't have MFA.
Azure Virtual Desktop Agent isn't registering

with the Azure Virtual Desktop service
When the Azure Virtual Desktop Agent is first installed on session host VMs (either
manually or through the Azure Resource Manager template and PowerShell DSC), it
provides a registration token. The following section covers troubleshooting issues that
apply to the Azure Virtual Desktop Agent and the token.
Error: The status filed in Get-AzWvdSessionHost cmdlet

shows status as Unavailable
Cause: The agent isn't able to update itself to a new version.
Fix: Follow these instructions to manually update the agent.
1. Download a new version of the agent on the session host VM.

2. Launch Task Manager and, in the Service Tab, stop the RDAgentBootLoader service.
3. Run the installer for the new version of the Azure Virtual Desktop Agent.
4. When prompted for the registration token, remove the entry INVALID_TOKEN and
press next (a new token isn't required).
5. Complete the installation Wizard.
6. Open Task Manager and start the RDAgentBootLoader service.
Error: Azure Virtual Desktop Agent registry

entry IsRegistered shows a value of 0
Cause: Registration token has expired.
Fix: Follow these instructions to fix the agent registry error.
1. If there's already a registration token, remove it with Remove-

AzWvdRegistrationInfo.
2. Run the New-AzWvdRegistrationInfo cmdlet to generate a new token.
3. Confirm that the -ExpriationTime parameter is set to three days.
Error: Azure Virtual Desktop agent isn't reporting a

heartbeat when running Get-AzWvdSessionHost
Cause 1: RDAgentBootLoader service has been stopped.
Fix 1: Launch Task Manager and, if the Service Tab reports a stopped status for
RDAgentBootLoader service, start the service.
Cause 2: Port 443 may be closed.
Fix 2: Follow these instructions to open port 443.
1. Confirm port 443 is open by downloading the PSPing tool from Sysinternal tools.
2. Install PSPing on the session host VM where the agent is running.
3. Open the command prompt as an administrator and issue the command below:
psping rdbroker.wvdselfhost.microsoft.com:443
4. Confirm that PSPing received information back from the RDBroker:
PsPing v2.10 - PsPing - ping, latency, bandwidth measurement utility
Copyright (C) 2012-2016 Mark Russinovich
Sysinternals - www.sysinternals.com
TCP connect to 13.77.160.237:443:

5 iterations (warmup 1) ping test:
Connecting to 13.77.160.237:443 (warmup): from 172.20.17.140:60649:

2.00ms
Connecting to 13.77.160.237:443: from 172.20.17.140:60650: 3.83ms
TCP connect statistics for 13.77.160.237:443:
Sent = 4, Received = 4, Lost = 0 (0% loss),
Minimum = 2.12ms, Maximum = 3.83ms, Average = 2.58ms
Troubleshooting issues with the Azure Virtual

Desktop side-by-side stack
The Azure Virtual Desktop side-by-side stack is automatically installed with Windows
Server 2019 and newer. Use Microsoft Installer (MSI) to install the side-by-side stack on
Microsoft Windows Server 2016 or Windows Server 2012 R2. For Microsoft Windows 10,
the Azure Virtual Desktop side-by-side stack is enabled with enablesxstackrs.ps1.
There are three main ways the side-by-side stack gets installed or enabled on session
host pool VMs:
With the Azure portal creation template

By being included and enabled on the master image
Installed or enabled manually on each VM (or with extensions/PowerShell)
If you're having issues with the Azure Virtual Desktop side-by-side stack, type the
qwinsta command from the command prompt to confirm that the side-by-side stack is
installed or enabled.
The output of qwinsta will list rdp-sxs in the output if the side-by-side stack is installed
and enabled.
Examine the registry entries listed below and confirm that their values match. If registry
keys are missing or values are mismatched, make sure you're running a supported
operating system. If you are, follow the instructions in Create a host pool with
PowerShell on how to reinstall the side-by-side stack.
registry
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal
Server\WinStations\rds-sxs\"fEnableWinstation":DWORD=1
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal
Server\ClusterSettings\"SessionDirectoryListener":rdp-sxs
Error: O_REVERSE_CONNECT_STACK_FAILURE
Cause: The side-by-side stack isn't installed on the session host VM.
Fix: Follow these instructions to install the side-by-side stack on the session host VM.
1. Use Remote Desktop Protocol (RDP) to get directly into the session host VM as
local administrator.
2. Install the side-by-side stack using Create a host pool with PowerShell.
How to fix an Azure Virtual Desktop side-by-

side stack that malfunctions
There are known circumstances that can cause the side-by-side stack to malfunction:
Not following the correct order of the steps to enable the side-by-side stack
Auto update to Windows 10 Enhanced Versatile Disc (EVD)
Missing the Remote Desktop Session Host (RDSH) role
Running enablesxsstackrc.ps1 multiple times
Running enablesxsstackrc.ps1 in an account that doesn't have local admin
privileges
The instructions in this section can help you uninstall the Azure Virtual Desktop side-by-
side stack. Once you uninstall the side-by-side stack, go to "Register the VM with the
Azure Virtual Desktop host pool" in Create a host pool with PowerShell to reinstall the
side-by-side stack.
The VM used to run remediation must be on the same subnet and domain as the VM
with the malfunctioning side-by-side stack.
Follow these instructions to run remediation from the same subnet and domain:
1. Connect with standard Remote Desktop Protocol (RDP) to the VM from where fix
will be applied.
2. Download PsExec from PsExec v2.40.
3. Unzip the downloaded file.
4. Start command prompt as local administrator.
5. Navigate to folder where PsExec was unzipped.
6. From command prompt, use the following command:

psexec.exe \\<VMname> cmd
７ Note
VMname is the machine name of the VM with the malfunctioning side-by-side

stack.
7. Accept the PsExec License Agreement by clicking Agree.
７ Note
This dialog will show up only the first time PsExec is run.
8. After the command prompt session opens on the VM with the malfunctioning
side-by-side stack, run qwinsta and confirm that an entry named rdp-sxs is
available. If not, a side-by-side stack isn't present on the VM so the issue isn't tied
to the side-by-side stack.
9. Run the following command, which will list Microsoft components installed on the
VM with the malfunctioning side-by-side stack.
wmic product get name
10. Run the command below with product names from step above.
wmic product where name="<Remote Desktop Services Infrastructure

Agent>" call uninstall
11. Uninstall all products that start with "Remote Desktop."
12. After all Azure Virtual Desktop components have been uninstalled, follow the
instructions for your operating system:
13. If your operating system is Windows Server, restart the VM that had the
malfunctioning side-by-side stack (either with Azure portal or from the PsExec
tool).
If your operating system is Microsoft Windows 10, continue with the instructions below:
14. From the VM running PsExec, open File Explorer and copy disablesxsstackrc.ps1 to
the system drive of the VM with the malfunctioned side-by-side stack.
\\<VMname>\c$\
７ Note
VMname is the machine name of the VM with the malfunctioning side-by-side

stack.
15. The recommended process: from the PsExec tool, start PowerShell and navigate to
the folder from the previous step and run disablesxsstackrc.ps1. Alternatively, you
can run the following cmdlets:
PowerShell
Remove-ItemProperty -Path
"HKLM:\SYSTEM\CurrentControlSet\Control\Terminal
Server\ClusterSettings" -Name "SessionDirectoryListener" -Force
Remove-Item -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Terminal

Server\WinStations\rdp-sxs" -Recurse -Force
Remove-ItemProperty -Path
"HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations" -
Name "ReverseConnectionListener" -Force
16. When the cmdlets are done running, restart the VM with the malfunctioning side-
by-side stack.
Remote Desktop licensing mode isn't

configured
If you sign in to Windows 10 Enterprise multi-session using an administrative account,
you might receive a notification that says, "Remote Desktop licensing mode isn't
configured, Remote Desktop Services will stop working in X days. On the Connection
Broker server, use Server Manager to specify the Remote Desktop licensing mode."
If the time limit expires, an error message will appear that says, "The remote session was
disconnected because there are no Remote Desktop client access licenses available for
this computer."
If you see either of these messages, it means the image doesn't have the latest Windows
updates installed or you're setting the Remote Desktop licensing mode through group
policy. Follow the steps in the next sections to check the group policy setting, identify
the version of Windows 10 Enterprise multi-session, and install the corresponding
update.
７ Note
Azure Virtual Desktop only requires an RDS client access license (CAL) when your
host pool contains Windows Server session hosts. To learn how to configure an RDS
CAL, see License your RDS deployment with client access licenses.
Disable the Remote Desktop licensing mode group policy

setting
Check the group policy setting by opening the Group Policy Editor in the VM and
navigating to Administrative Templates > Windows Components > Remote Desktop
Services > Remote Desktop Session Host > Licensing > Set the Remote Desktop
licensing mode. If the group policy setting is Enabled, change it to Disabled. If it's
already disabled, then leave it as-is.
７ Note
If you set group policy through your domain, disable this setting on policies that
target these Windows 10 Enterprise multi-session VMs.
Identify which version of Windows 10 Enterprise multi-

session you're using
To check which version of Windows 10 Enterprise multi-session you have:
1. Sign in with your admin account.
2. Enter "About" into the search bar next to the Start menu.
3. Select About your PC.
4. Check the number next to "Version." The number should be either "1809" or
"1903," as shown in the following image.
Now that you know your version number, skip ahead to the relevant section.
Version 1809
If your version number says "1809," install the KB4516077 update .
Version 1903
Redeploy the host operating system with the latest version of the Windows 10, version
1903 image from the Azure Gallery.
We couldn't connect to the remote PC because
of a security error
If your users see an error that says, "We couldn't connect to the remote PC because of a
security error. If this keeps happening, ask your admin or tech support for help," validate
any existing policies that change default RDP permissions. One policy that might cause
this error to appear is "Allow log on through Remote Desktop Services security policy."
To learn more about this policy, see Allow log on through Remote Desktop Services.
I can't deploy the golden image

Golden images must not include the Azure Virtual Desktop agent. You can install the
agent only after you deploy the golden image.
Next steps
To troubleshoot issues while creating a host pool in an Azure Virtual Desktop
environment, see Environment and host pool creation.
Desktop client
 Documentation




environment.

Delete Azure Virtual Desktop host pool - Azure

How to delete a host pool in Azure Virtual Desktop.


Show 5 more
 Training
Learning path
Certification
Azure Virtual Desktop session host
statuses and health checks
The Azure Virtual Desktop Agent regularly runs health checks on the session host. The
agent assigns these health checks various statuses that include descriptions of how to
fix common issues. This article will tell you what each status means and how to act on
them during a health check.
Session host statuses

The following table lists all statuses for session hosts in the Azure portal each potential
status. Available is considered the ideal default status. Any other statuses represent
potential issues that you need to take care of to ensure the service works properly.
７ Note
If an issue is listed as "non-fatal," the service can still run with the issue active.
However, we recommend you resolve the issue as soon as possible to prevent
future issues. If an issue is listed as "fatal," then it will prevent the service from
running. You must resolve all fatal issues to make sure your users can access the
session host.
Session Description How to resolve related issues

host status
Available This status means that the session host passed N/A
all health checks and is available to accept user
connections. If a session host has reached its
maximum session limit but has passed health
checks, it will still be listed as “Available."
Needs The session host didn't pass one or more of the Follow the directions in Error:
Assistance following non-fatal health checks: the Geneva VMs are stuck in "Needs
Monitoring Agent health check, the Azure Assistance" state to resolve the
Instance Metadata Service (IMDS) health check, issue.
or the URL health check. You can find which
health checks have failed in the session hosts
detailed view in the Azure portal.
Session Description How to resolve related issues
host status
Shutdown The session host has been shut down. If the Turn on the session host.
agent enters a shutdown state before
connecting to the broker, its status will change
to Unavailable. If you've shut down your session
host and see an Unavailable status, that means
the session host shut down before it could
update the status, and doesn't indicate an issue.
You should use this status with the VM instance
view API to determine the power state of the
VM.
Unavailable The session host is either turned off or hasn't If the session host is off, turn it
passed fatal health checks, which prevents user back on. If the session host
sessions from connecting to this session host. didn't pass the domain join
check or side-by-side stack
listener health checks, refer to
the table in Health check for
ways to resolve the issue. If the
status is still "Unavailable" after
following those directions, open
a support case.
Upgrade This status means that the Azure Virtual Desktop Follow the instructions in the
Failed Agent couldn't update or upgrade. This doesn't Azure Virtual Desktop Agent
affect new nor existing user sessions. troubleshooting article.
Upgrading This status means that the agent upgrade is in If your session host has been
progress. This status will be updated to stuck in the "Upgrading" state,
“Available” once the upgrade is done and the then reinstall the agent.
session host can accept connections again.
Health check
The health check is a test run by the agent on the session host. The following table lists
each type of health check and describes what it does.
Health check Description What happens if the session host

name doesn't pass the check
Domain joined Verifies that the session host is If this check fails, users won't be able
joined to a domain controller. to connect to the session host. To
solve this issue, join your session host
to a domain.
Health check Description What happens if the session host
name doesn't pass the check
Geneva Monitoring Verifies that the session host has If this check fails, it's semi-fatal. There
Agent a healthy monitoring agent by may be successful connections, but
checking if the monitoring agent they'll contain no logging information.
is installed and running in the To resolve this, make sure a
expected registry location. monitoring agent is installed. If it's
already installed, contact Microsoft
support.
Integrated Verifies that the service can't If this check fails, it's semi-fatal. There
Maintenance Data access the IMDS endpoint. may be successful connections, but
System (IMDS) they won't contain logging
reachable information. To resolve this issue,
you'll need to reconfigure your
networking, firewall, or proxy settings.
Side-by-side (SxS) Verifies that the side-by-side If this check fails, it's fatal, and users
Stack Listener stack is up and running, listening, won't be able to connect to the
and ready to receive connections. session host. Try restarting your virtual
machine (VM). If this doesn't work,
contact Microsoft support.
UrlsAccessibleCheck Verifies that the required Azure If this check fails, it isn't always fatal.
Virtual Desktop service and Connections may succeed, but if
Geneva URLs are reachable from certain URLs are inaccessible, the
the session host, including the agent can't apply updates or log
RdTokenUri, RdBrokerURI, diagnostic information. To resolve this,
RdDiagnosticsUri, and storage follow the directions in Error: VMs are
blob URLs for Geneva agent stuck in the Needs Assistance state.
monitoring.
TURN (Traversal When using RDP Shortpath for If this check fails, it's not fatal.
Using Relay NAT) public networks with an indirect Connections will revert to the
Relay Access Health connection, TURN uses User websocket TCP and the session host
Check Datagram Protocol (UDP) to relay will enter the "Needs assistance" state.
traffic between the client and To resolve the issue, follow the
session host through an instructions in Disable RDP shortpath
intermediate server when direct on managed and unmanaged
connection isn't possible. windows clients using group policy.
Error: VMs are stuck in the "Needs Assistance"

state
If the session host doesn't pass the UrlsAccessibleCheck health check, you'll need to
identify which required URL your deployment is currently blocking. Once you know
which URL is blocked, identify which setting is blocking that URL and remove it.
There are two reasons why the service is blocking a required URL:
You have an active firewall that's blocking most outbound traffic and access to the
required URLs.
Your local hosts file is blocking the required websites.
To resolve a firewall-related issue, add a rule that allows outbound connections to the
TCP port 80/443 associated with the blocked URLs.
If your local hosts file is blocking the required URLs, make sure none of the required
URLs are in the Hosts file on your device. You can find the Hosts file location at the
following registry key and value:
Key: HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Type: REG_EXPAND_SZ
Name: DataBasePath
If the session host doesn't pass the MetaDataServiceCheck health check, then the service
can't access the IMDS endpoint. To resolve this issue, you'll need to do the following
things:
Reconfigure your networking, firewall, or proxy settings to unblock the IP address

169.254.169.254.
Make sure your HTTP clients bypass web proxies within the VM when querying
IMDS. We recommend that you allow the required IP address in any firewall
policies within the VM that deal with outbound network traffic direction.
If your issue is caused by a web proxy, add an exception for 169.254.169.254 in the web
proxy's configuration. To add this exception, open an elevated Command Prompt or
PowerShell session and run the following command:
netsh winhttp set proxy proxy-server="http=<customerwebproxyhere>" bypass-

list="169.254.169.254"
Next steps
To troubleshoot issues while creating an Azure Virtual Desktop environment and
host pool in an Azure Virtual Desktop environment, see Environment and host pool
creation.
Management issues
This article describes common management errors and gives suggestions for how to
solve them.
Common management errors

The following table lists error messages that appear due to management-related issues
and suggestions for how to solve them.
Error message Suggested solution
Failed to create Registration token couldn't be created. Try creating it again with a shorter
registration key expiry time (between 1 hour and 1 month).
Failed to delete Registration token couldn't be deleted. Try deleting it again. If it still doesn't
registration key work, use PowerShell to check if the token is still there. If it's there, delete it
with PowerShell.
Failed to change Couldn't change drain mode on the VM. Check the VM status. If the VM isn't
session host drain available, you can't change drain mode.
mode
Failed to Couldn't disconnect the user from the VM. Check the VM status. If the VM
disconnect user isn't available, you can't disconnect the user session. If the VM is available,
sessions check the user session status to see if it's disconnected.
Failed to log off Could not sign users out of the VM. Check the VM status. If unavailable, users
all user(s) within can't be signed out. Check user session status to see if they're already signed
the session host out. You can force sign out with PowerShell.
Failed to unassign Could not unpublish an app group for a user. Check to see if user is available
user from on Azure AD. Check to see if the user is part of a user group that the app
application group group is published to.
There was an Check location of VM used in the create host pool wizard. If image is not
error retrieving available in that location, add image in that location or choose a different VM
the available location.
locations
Error: Can't add user assignments to an app

group
After assigning a user to an app group, the Azure portal displays a warning that says
"Session Ending" or "Experiencing Authentication Issues - Extension
Microsoft_Azure_WVD." The assignment page then doesn't load, and after that, pages
stop loading throughout the Azure portal (for example, Azure Monitor, Log Analytics,
Service Health, and so on).
This issue usually appears because there's a problem with the conditional access policy.
The Azure portal is trying to obtain a token for Microsoft Graph, which is dependent on
SharePoint Online. The customer has a conditional access policy called "Microsoft Office
365 Data Storage Terms of Use" that requires users to accept the terms of use to access
data storage. However, they haven't signed in yet, so the Azure portal can't get the
token.
To solve this issue, before signing in to the Azure portal, the admin first needs to sign in
to SharePoint and accept the Terms of Use. After that, they should be able to sign in to
the Azure portal like normal.
Next steps
To review common error scenarios that the diagnostics feature can identify for you, see
Identify and diagnose issues.
Azure Virtual Desktop PowerShell
） Important
Use this article to resolve errors and issues when using PowerShell with Azure Virtual
Desktop. For more information on Remote Desktop Services PowerShell, see Azure
Virtual Desktop PowerShell.
Provide feedback
PowerShell commands used during Azure

Virtual Desktop setup
This section lists PowerShell commands that are typically used while setting up Azure
Virtual Desktop and provides ways to resolve issues that may occur while using them.
Error: New-AzRoleAssignment: The provided information

does not map to an AD object ID
PowerShell
New-AzRoleAssignment -SignInName "admins@contoso.com" -RoleDefinitionName

"Desktop Virtualization User" -ResourceName "0301HP-DAG" -ResourceGroupName
0301RG -ResourceType 'Microsoft.DesktopVirtualization/applicationGroups'
Cause: The user specified by the -SignInName parameter can't be found in the Azure
Active Directory tied to the Azure Virtual Desktop environment.
Fix: Make sure of the following things.
The user should be synced to Azure Active Directory.

The user shouldn't be tied to business-to-consumer (B2C) or business-to-business
(B2B) commerce.
The Azure Virtual Desktop environment should be tied to correct Azure Active
Directory.
Error: New-AzRoleAssignment: "The client with object id

does not have authorization to perform action over scope
(code: AuthorizationFailed)"
Cause 1: The account being used doesn't have Owner permissions on the subscription.
Fix 1: A user with Owner permissions needs to execute the role assignment.
Alternatively, the user needs to be assigned to the User Access Administrator role to
assign a user to an application group.
Cause 2: The account being used has Owner permissions but isn't part of the
environment's Azure Active Directory or doesn't have permissions to query the Azure
Active Directory where the user is located.
Fix 2: A user with Active Directory permissions needs to execute the role assignment.
Error: New-AzWvdHostPool -- the location is not

available for resource type
PowerShell
New-AzWvdHostPool_CreateExpanded: The provided location 'southeastasia' is

not available for resource type 'Microsoft.DesktopVirtualization/hostpools'.
List of available regions for the resource type is
'eastus,eastus2,westus,westus2,northcentralus,southcentralus,westcentralus,c
entralus'.
Cause: Azure Virtual Desktop supports selecting the location of host pools, application
groups, and workspaces to store service metadata in certain locations. Your options are
restricted to where this feature is available. This error means that the feature isn't
available in the location you chose.
Fix: In the error message, a list of supported regions will be published. Use one of the
supported regions instead.
Error: New-AzWvdApplicationGroup must be in same

location as host pool
PowerShell
New-AzWvdApplicationGroup_CreateExpanded: ActivityId: e5fe6c1d-5f2c-4db9-

817d-e423b8b7d168 Error: ApplicationGroup must be in same location as
associated HostPool
Cause: There's a location mismatch. All host pools, application groups, and workspaces
have a location to store service metadata. Any objects you create that are associated
with each other must be in the same location. For example, if a host pool is in eastus ,
then you also need to create the application groups in eastus . If you create a workspace
to register these application groups to, that workspace needs to be in eastus as well.
Fix: Retrieve the location the host pool was created in, then assign the application group
you're creating to that same location.
Next steps
To troubleshoot issues while setting up your Azure Virtual Desktop environment
and host pools, see Environment and host pool creation.
Desktop client
Troubleshoot common Azure Virtual Desktop
Agent issues
The Azure Virtual Desktop Agent can cause connection issues because of multiple factors:
An error on the broker that makes the agent stop the service.
Problems with updates.
Issues with installing during the agent installation, which disrupts connection to the session
host.
This article will guide you through solutions to these common scenarios and how to address
connection issues.
７ Note
For troubleshooting issues related to session connectivity and the Azure Virtual Desktop
agent, we recommend you review the event logs on your session host virtual machines (VMs)
by going to Event Viewer > Windows Logs > Application. Look for events that have one of
the following sources to identify your issue:
WVD-Agent
WVD-Agent-Updater
RDAgentBootLoader
MsiInstaller
Error: The RDAgentBootLoader and/or Remote

Desktop Agent Loader has stopped running
If you're seeing any of the following issues, this means that the boot loader, which loads the agent,
was unable to install the agent properly and the agent service isn't running on your session host
VM:
RDAgentBootLoader is either stopped or not running.

There's no status for Remote Desktop Agent Loader.
To resolve this issue, start the RDAgent boot loader:
1. In the Services window, right-click Remote Desktop Agent Loader.

2. Select Start. If this option is greyed out for you, you don't have administrator permissions
and will need to get them to start the service.
3. Wait 10 seconds, then right-click Remote Desktop Agent Loader.
4. Select Refresh.
5. If the service stops after you started and refreshed it, you may have a registration failure. For
more information, see INVALID_REGISTRATION_TOKEN.
Error: INVALID_REGISTRATION_TOKEN
On your session host VM, go to Event Viewer > Windows Logs > Application. If you see an event
with ID 3277 with INVALID_REGISTRATION_TOKEN in the description, the registration token that
has been used isn't recognized as valid.
To resolve this issue, create a valid registration token:
1. To create a new registration token, follow the steps in the Generate a new registration key for
the VM section.
2. Open Registry Editor.
3. Go to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\RDInfraAgent.
4. Select IsRegistered.
5. In the Value data: entry box, type 0 and select Ok.
6. Select RegistrationToken.
7. In the Value data: entry box, paste the registration token from step 1.
8. Open a PowerShell prompt as an administrator and run the following command to restart the
RDAgentBootLoader service:
PowerShell
Restart-Service RDAgentBootLoader
9. Go back to Registry Editor.
11. Verify that IsRegistered is set to 1 and there is nothing in the data column for
RegistrationToken.
Error: Agent cannot connect to broker with
INVALID_FORM
with ID 3277 with INVALID_FORM in the description, the agent can't connect to the broker or
reach a particular endpoint. This may be because of certain firewall or DNS settings.
To resolve this issue, check that you can reach the two endpoints referred to as BrokerURI and
BrokerURIGlobal:
1. Open Registry Editor.
3. Make note of the values for BrokerURI and BrokerURIGlobal.
4. Open a web browser and enter your value for BrokerURI in the address bar and add
/api/health to the end, for example https://rdbroker-g-us-r0.wvd.microsoft.com/api/health .
5. Open another tab in the browser and enter your value for BrokerURIGlobal in the address bar
and add /api/health to the end, for example https://rdbroker.wvd.microsoft.com/api/health .
6. If your network isn't blocking the connection to the broker, both pages will load successfully
and will show a message stating RD Broker is Healthy, as shown in the following screenshots:
7. If the network is blocking broker connection, the pages will not load, as shown in the
following screenshot.
You will need to unblock the required endpoints and then repeat steps 4 to 7. For more
information, see Required URL List.
8. If this does not resolve your issue, make sure that you do not have any group policies with
ciphers that block the agent to broker connection. Azure Virtual Desktop uses the same TLS
1.2 ciphers as Azure Front Door. For more information, see Connection Security.
Error: 3703
with ID 3703 with RD Gateway Url: is not accessible in the description, the agent is unable to
reach the gateway URLs. To successfully connect to your session host, you must allow network
traffic to the URLs from the Required URL List. Also, make sure your firewall or proxy settings don't
block these URLs. Unblocking these URLs is required to use Azure Virtual Desktop.
To resolve this issue, verify that your firewall and/or DNS settings are not blocking these URLs:
1. Use Azure Firewall to protect Azure Virtual Desktop deployments..

2. Configure your Azure Firewall DNS settings.
Error: 3019
with ID 3019, this means the agent can't reach the web socket transport URLs. To successfully
connect to your session host and allow network traffic to bypass these restrictions, you must
unblock the URLs listed in the Required URL list. Work with your networking team to make sure
your firewall, proxy, and DNS settings aren't blocking these URLs. You can also check your network
trace logs to identify where the Azure Virtual Desktop service is being blocked. If you open a
Microsoft Support case for this particular issue, make sure to attach your network trace logs to the
request.
Error: InstallationHealthCheckFailedException
with ID 3277 with InstallationHealthCheckFailedException in the description, this means the stack
listener isn't working because the terminal server has toggled the registry key for the stack listener.
1. Check to see if the stack listener is working

2. If the stack listener isn't working, manually uninstall and reinstall the stack component.
Error: ENDPOINT_NOT_FOUND
with ID 3277 with ENDPOINT_NOT_FOUND in the description, this means the broker couldn't find
an endpoint to establish a connection with. This connection issue can happen for one of the
following reasons:
There aren't any session host VMs in your host pool.

The session host VMs in your host pool aren't active.
All session host VMs in your host pool have exceeded the max session limit.
None of the VMs in your host pool have the agent service running on them.
1. Make sure the VM is powered on and hasn't been removed from the host pool.
2. Make sure that the VM hasn't exceeded the max session limit.
3. Make sure the agent service is running and the stack listener is working.
4. Make sure the agent can connect to the broker.
5. Make sure your VM has a valid registration token.
6. Make sure the VM registration token hasn't expired.
Error: InstallMsiException
with ID 3277 with InstallMsiException in the description, the installer is already running for
another application while you're trying to install the agent, or group policy is blocking msiexec.exe
from running.
To check whether group policy is blocking msiexec.exe from running:
1. Open Resultant Set of Policy by running rsop.msc from an elevated command prompt.
2. In the Resultant Set of Policy window that pops up, go to Computer Configuration >
Administrative Templates > Windows Components > Windows Installer > Turn off
Windows Installer. If the state is Enabled, work with your Active Directory team to allow
msiexec.exe to run.
７ Note
This isn't a comprehensive list of policies, just the one we're currently aware of.
Error: Win32Exception
with ID 3277 with InstallMsiException in the description, a policy is blocking cmd.exe from
launching. Blocking this program prevents you from running the console window, which is what
you need to use to restart the service whenever the agent updates.
1. Open Resultant Set of Policy by running rsop.msc from an elevated command prompt.
2. In the Resultant Set of Policy window that pops up, go to User Configuration >
Administrative Templates > System > Prevent access to the command prompt. If the state
is Enabled, work with your Active Directory team to allow cmd.exe to run.
Error: Stack listener isn't working on a Windows 10

2004 session host VM
On your session host VM, from a command prompt run qwinsta.exe and make note of the version
number that appears next to rdp-sxs in the SESSIONNAME column. If the STATE column for rdp-
tcp and rdp-sxs entries isn't Listen, or if rdp-tcp and rdp-sxs entries aren't listed at all, it means
that there's a stack issue. Stack updates get installed along with agent updates, but if this hasn't
been successful, the Azure Virtual Desktop Listener won't work.
1. Open the Registry Editor.
2. Go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal
Server\WinStations.
3. Under WinStations you may see several folders for different stack versions, select a folder
that matches the version information you saw when running qwinsta.exe in a command
prompt.
a. Find fReverseConnectMode and make sure its data value is 1. Also make sure that
fEnableWinStation is set to 1.
b. If fReverseConnectMode isn't set to 1, select fReverseConnectMode and enter 1 in its

value field.
c. If fEnableWinStation isn't set to 1, select fEnableWinStation and enter 1 into its value field.
4. Repeat the previous steps for each folder that matches the version information you saw when
running qwinsta.exe in a command prompt.
 Tip
To change the fReverseConnectMode or fEnableWinStation mode for multiple VMs at a

time, you can do one of the following two things:
Export the registry key from the machine that you already have working and import
it into all other machines that need this change.
Create a group policy object (GPO) that sets the registry key value for the machines
that need the change.
5. Restart your session host VM.
6. Open the Registry Editor.
7. Go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal
Server\ClusterSettings.
8. Under ClusterSettings, find SessionDirectoryListener and make sure its data value is rdp-
sxs<version number , where <version number matches the version information you saw when
running qwinsta.exe in a command prompt .
9. If SessionDirectoryListener isn't set to rdp-sxs<version number , you'll need to follow the

steps in the section Your issue isn't listed here or wasn't resolved below.
Error: DownloadMsiException
with ID 3277 with DownloadMsiException in the description, there isn't enough space on the disk
for the RDAgent.
To resolve this issue, make space on your disk by:
Deleting files that are no longer in user.

Increasing the storage capacity of your session host VM.
Error: Agent fails to update with

MissingMethodException
with ID 3389 with MissingMethodException: Method not found in the description, this means the
Azure Virtual Desktop agent didn't update successfully and reverted to an earlier version. This may
be because the version number of the .NET framework currently installed on your VMs is lower
than 4.7.2. To resolve this issue, you need to upgrade the .NET to version 4.7.2 or later by following
the installation instructions in the .NET Framework documentation .
Error: Session host VMs are stuck in Unavailable or

Upgrading state
If the status listed for session hosts in your host pool always says Unavailable or Upgrading, the
agent or stack didn't install successfully.
To resolve this issue, first reinstall the side-by-side stack:
1. Sign in to your session host VM as an administrator.
2. From an elevated PowerShell prompt run qwinsta.exe and make note of the version number
that appears next to rdp-sxs in the SESSIONNAME column. If the STATE column for rdp-tcp
and rdp-sxs entries isn't Listen, or if rdp-tcp and rdp-sxs entries aren't listed at all, it means
that there's a stack issue.
3. Run the following command to stop the RDAgentBootLoader service:
PowerShell
Stop-Service RDAgentBootLoader
4. Go to Control Panel > Programs > Programs and Features, or on Windows 11 go to the
Settings App > Apps.
5. Uninstall the latest version of the Remote Desktop Services SxS Network Stack or the
version listed in Registry Editor in
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations
under the value for ReverseConnectionListener.
6. Back at the PowerShell prompt, run the following commands to add the file path of the latest
installer available on your session host VM for the side-by-side stack to a variable and list its
name:
PowerShell
$sxsMsi = (Get-ChildItem "$env:SystemDrive\Program Files\Microsoft RDInfra\" | ?

Name -like SxSStack*.msi | Sort-Object CreationTime -Descending | Select-Object -
First 1).FullName
$sxsMsi
7. Install the latest installer available on your session host VM for the side-by-side stack by
running the following command:
PowerShell
msiexec /i $sxsMsi
8. Restart your session host VM.
9. From a command prompt run qwinsta.exe again and verify the STATE column for rdp-tcp
and rdp-sxs entries is Listen. If not, you will need to re-register your VM and reinstall the
agent component.
Error: Connection not found: RDAgent does not have

an active connection to the broker
Your session host VMs may be at their connection limit and can't accept new connections.
To resolve this issue, either:
Decrease the max session limit. This ensures that resources are more evenly distributed
across session hosts and will prevent resource depletion.
Increase the resource capacity of the session host VMs.
Error: Operating a Pro VM or other unsupported OS

The side-by-side stack is only supported by Windows Enterprise or Windows Server SKUs, which
means that operating systems like Pro VM aren't. If you don't have an Enterprise or Server SKU, the
stack will be installed on your VM but won't be activated, so you won't see it show up when you
run qwinsta in your command line.
To resolve this issue, create session host VMs using a supported operating system.
Error: NAME_ALREADY_REGISTERED
The name of your session host VM has already been registered and is probably a duplicate.
1. Follow the steps in the Remove the session host from the host pool section.
2. Create another VM. Make sure to choose a unique name for this VM.
3. Go to the Azure portal and open the Overview page for the host pool your VM was in.
4. Open the Session Hosts tab and check to make sure all session hosts are in that host pool.
5. Wait for 5-10 minutes for the session host status to say Available.
Your issue isn't listed here or wasn't resolved

If you can't find your issue in this article or the instructions didn't help you, we recommend you
uninstall, reinstall, and re-register the Azure Virtual Desktop Agent. The instructions in this section
will show you how to reregister your session host VM to the Azure Virtual Desktop service by:
1. Uninstalling all agent, boot loader, and stack components

2. Removing the session host from the host pool
3. Generating a new registration key for the VM
4. Reinstalling the Azure Virtual Desktop Agent and boot loader.
Follow these instructions in this section if one or more of the following scenarios apply to you:
The state of your session host VM is stuck as Upgrading or Unavailable.

Your stack listener isn't working and you're running on Windows 10 version 1809, 1903, or
1909.
You're receiving an EXPIRED_REGISTRATION_TOKEN error.
You're not seeing your session host VMs show up in the session hosts list.
You don't see the Remote Desktop Agent Loader service in the Services console.
You don't see the RdAgentBootLoader component as a running process in Task Manager.
You're receiving a Connection Broker couldn't validate the settings error on custom image
VMs.
Previous sections in this article didn't resolve your issue.
Step 1: Uninstall all agent, boot loader, and stack component
programs
Before reinstalling the agent, boot loader, and stack, you must uninstall any existing components
from your VM. To uninstall all agent, boot loader, and stack component programs:
1. Sign in to your session host VM as an administrator.
2. Go to Control Panel > Programs > Programs and Features, or on Windows 11 go to the
Settings App > Apps.
3. Uninstall the following programs, then restart your session host VM:
Ｕ Caution
When uninstalling Remote Desktop Services SxS Network Stack, you'll be prompted
that Remote Desktop Services and Remote Desktop Services UserMode Port Redirector
should be closed. If you're connected to the session host VM using RDP, select Do not
close applications then select OK, otherwise your RDP connection will be closed.
Remote Desktop Agent Boot Loader

Remote Desktop Services Infrastructure Agent
Remote Desktop Services Infrastructure Geneva Agent
Remote Desktop Services SxS Network Stack
７ Note
You may see multiple instances of these programs. Make sure to remove all of them.
Step 2: Remove the session host from the host pool
When you remove the session host from the host pool, the session host is no longer registered to
that host pool. This acts as a reset for the session host registration. To remove the session host
from the host pool:
3. Select Host pools and select the name of the host pool that your session host VM is in.
4. Select Session Hosts to see the list of all session hosts in that host pool.
5. Look at the list of session hosts and tick the box next to the session host that you want to
remove.
6. Select Remove.
Step 3: Generate a new registration key for the VM

You must generate a new registration key that is used to re-register your session VM to the host
pool and to the service. To generate a new registration key for the VM:
4. On the Overview blade, select Registration key.

5. Open the Registration key tab and select Generate new key.
6. Enter the expiration date and then select Ok.
７ Note
The expiration date can be no less than an hour and no longer than 27 days from its
generation time and date. Generate a registration key only for as long as you need.
1. Copy the newly generated key to your clipboard or download the file. You'll need this key
later.
Step 4: Reinstall the agent and boot loader

By reinstalling the most updated version of the agent and boot loader, the side-by-side stack and
Geneva monitoring agent automatically get installed as well. To reinstall the agent and boot
loader:
1. Sign in to your session host VM as an administrator and run the agent installer and
bootloader for your session host VM:
Azure Virtual Desktop Agent
Azure Virtual Desktop Agent Bootloader
 Tip
For each of the the agent and boot loader installers you downloaded, you may need to
unblock them. Right-click each file and select Properties, then select Unblock, and finally
select OK.
2. When the installer asks you for the registration token, paste the registration key from your
clipboard.
3. Run the boot loader installer.
4. Restart your session VM.
6. In the search bar, enter Azure Virtual Desktop and select the matching service entry.
8. Select Session Hosts to see the list of all session hosts in that host pool.
9. You should now see the session host registered in the host pool with the status Available.
Remove DisableRegistryTools registry key

If you've performed all four steps but the agent still doesn't work, that may be because the
DisableRegistryTools registry key is enabled in one of the following locations:
HKU:\DEFAULT\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\DisableRegistryTools
=1
HKU:\S-1-5-
18\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\DisableRegistryTools = 1
HKCU:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\DisableRegistryTools
=1
This registry key prevents the agent from installing the side-by-side stack, which results in an
installMSIException error. This error leads to the session hosts being stuck in an unavailable state.
To resolve this issue, you'll need to remove the key:
1. Remove the DisableRegistryTools key from the three previously listed locations.
2. Uninstall and remove the affected side-by-side stack installation from the Apps & Features
folder.
3. Remove the affected side-by-side stack's registry keys.
4. Restart your VM.
5. Start the agent and let it auto-install the side-by-side stack.
Next steps
If the issue continues, create a support case and include detailed information about the problem
you're having and any actions you've taken to try to resolve it. The following list includes other
resources you can use to troubleshoot issues in your Azure Virtual Desktop deployment.
For an overview on troubleshooting Azure Virtual Desktop and the escalation tracks, see
Troubleshooting overview, feedback, and support.
To troubleshoot issues while creating a host pool in a Azure Virtual Desktop environment, see
Environment and host pool creation.
To troubleshoot issues while configuring a virtual machine (VM) in Azure Virtual Desktop, see
Session host virtual machine configuration.
To troubleshoot issues with Azure Virtual Desktop client connections, see Azure Virtual
Desktop service connections.
To troubleshoot issues when using PowerShell with Azure Virtual Desktop, see Azure Virtual
Desktop PowerShell.
To go through a troubleshoot tutorial, see Tutorial: Troubleshoot Resource Manager template
deployments.
To learn about actions to determine the errors during deployment, see View deployment
operations.
 Documentation





How to use the Scheduled Agent Updates feature to choose a date and time to update your Azure Virtual
Desktop agent components.


How to configure automatic or direct assignment for an Azure Virtual Desktop personal desktop host pool.
Prepare and customize a VHD image of Azure Virtual Desktop - Azure

How to prepare, customize and upload a Azure Virtual Desktop image to Azure.
Show 5 more
 Training
Module
Create and configure host pools and session hosts for Azure Virtual Desktop - Training
Azure Virtual Desktop service
connections
） Important
Use this article to resolve issues with Azure Virtual Desktop client connections.
Provide feedback
You can give us feedback and discuss the Azure Virtual Desktop Service with the product
team and other active community members at the Azure Virtual Desktop Tech
Community .
User connects but nothing is displayed (no

feed)
A user can start Remote Desktop clients and is able to authenticate, however the user
doesn't see any icons in the web discovery feed.
1. Confirm that the user reporting the issues has been assigned to application groups
by using this command line:
PowerShell
Get-AzRoleAssignment -SignInName <userupn>
2. Confirm that the user is signing in with the correct credentials.
3. If the web client is being used, confirm that there are no cached credentials issues.
4. If the user is part of an Azure Active Directory user group, make sure the user
group is a security group instead of a distribution group. Azure Virtual Desktop
doesn't support Azure AD distribution groups.
User loses existing feed and no remote
resource is displayed (no feed)
This error usually appears after a user moved their subscription from one Azure Active
Directory tenant to another. As a result, the service loses track of their user assignments,
since those are still tied to the old Azure Active Directory tenant.
To resolve this, all you need to do is reassign the users to their app groups.
This could also happen if a CSP Provider created the subscription and then transferred
to the customer. To resolve this re-register the Resource Provider.

2. Go to Subscription, then select your subscription.
3. In the menu on the left side of the page, select Resource provider.
4. Find and select Microsoft.DesktopVirtualization, then select Re-register.
Next steps
To troubleshoot issues while creating a Azure Virtual Desktop environment and
host pool in a Azure Virtual Desktop environment, see Environment and host pool
creation.
 Documentation





Azure
Desktop.


Show 5 more
 Training
Learning path
Certification
Troubleshoot the Remote Desktop client
for Windows when connecting to Azure
Virtual Desktop
This article describes issues you may experience with the Remote Desktop client for
Windows when connecting to Azure Virtual Desktop and how to fix them.
General
In this section you'll find troubleshooting guidance for general issues with the Remote
Desktop client.
Remote Desktop Client doesn't show expected resources

If the Remote Desktop Client doesn't show the remote resources you're expecting to
see, check the account you're using. If you've already signed in with a different account
than the one you want to use for Azure Virtual Desktop, you should first sign out, then
sign in again with the correct account. If you're using the Remote Desktop Web client,
you can use an InPrivate browser window to try a different account.
If you're using the correct account, make sure your application group is associated with
a workspace.
Your account is configured to prevent you from using this

device
If you come across an error saying Your account is configured to prevent you from
using this device. For more information, contact your system administrator, ensure the
user account was given the Virtual Machine User Login role on the VMs.
The user name or password is incorrect

If you can't sign in and keep receiving an error message that says your credentials are
incorrect, first make sure you're using the right credentials. If you keep seeing error
messages, check to make sure you've fulfilled the following requirements:
Have you assigned the Virtual Machine User Login role-based access control
(RBAC) permission to the virtual machine (VM) or resource group for each user?
Does your Conditional Access policy exclude multi-factor authentication
requirements for the Azure Windows VM sign-in cloud application?
If you've answered "no" to either of those questions, you'll need to reconfigure your
multi-factor authentication. To reconfigure your multi-factor authentication, follow the
instructions in Enforce Azure Active Directory Multi-Factor Authentication for Azure
Virtual Desktop using Conditional Access.
） Important
VM sign-ins don't support per-user enabled or enforced Azure AD Multi-Factor

Authentication. If you try to sign in with multi-factor authentication on a VM, you
won't be able to sign in and will receive an error message.
If you can access your Azure AD sign-in logs through Log Analytics, you can see if
you've enabled multi-factor authentication and which Conditional Access policy is
triggering the event. The events shown are non-interactive user login events for the VM,
which means the IP address will appear to come from the external IP address that your
VM accesses Azure AD from.
You can access your sign-in logs by running the following Kusto query:
Kusto
let UPN = "userupn";
AADNonInteractiveUserSignInLogs
| where UserPrincipalName == UPN
| where AppId == "38aa3b87-a06d-4817-b275-7a316988d93b"
| project ['Time']=(TimeGenerated), UserPrincipalName,

AuthenticationRequirement, ['MFA Result']=ResultDescription, Status,
ConditionalAccessPolicies, DeviceDetail, ['Virtual Machine IP']=IPAddress,
['Cloud App']=ResourceDisplayName
| order by ['Time'] desc
Retrieve and open client logs

You might need the client logs when investigating a problem.
To retrieve the client logs:
1. Ensure no sessions are active and the client process isn't running in the
background by right-clicking on the Remote Desktop icon in the system tray and
selecting Disconnect all sessions.
2. Open File Explorer.
3. Navigate to the %temp%\DiagOutputDir\RdClientAutoTrace folder.
The logs are in the .ETL file format. You can convert these to .CSV or .XML to make them
easily readable by using the tracerpt command. Find the name of the file you want to
convert and make a note of it.
To convert the .ETL file to .CSV, open PowerShell and run the following, replacing
the value for $filename with the name of the file you want to convert (without the
extension) and $outputFolder with the directory in which to create the .CSV file.
PowerShell
$filename = "<filename>"
$outputFolder = "C:\Temp"
cd $env:TEMP\DiagOutputDir\RdClientAutoTrace
tracerpt "$filename.etl" -o "$outputFolder\$filename.csv" -of csv
To convert the .ETL file to .XML, open Command Prompt or PowerShell and run the
following, replacing <filename> with the name of the file you want to convert and
$outputFolder with the directory in which to create the .XML file.
PowerShell
$filename = "<filename>"
$outputFolder = "C:\Temp"
cd $env:TEMP\DiagOutputDir\RdClientAutoTrace
tracerpt "$filename.etl" -o "$outputFolder\$filename.xml"
Client stops responding or can't be opened

If the Remote Desktop client for Windows stops responding or can't be opened, you
may need to reset user data. If you can open the client, you can reset user data from the
About menu, or if you can't open the client, you can reset user data from the command
line. The default settings for the client will be restored and you'll be unsubscribed from
all workspaces.
To reset user data from the client:
2. Select the three dots at the top right-hand corner to show the menu, then select
About.
3. In the section Reset user data, select Reset. To confirm you want to reset your user
data, select Continue.
To reset user data from the command line:
1. Open PowerShell.
2. Change the directory to where the Remote Desktop client is installed, by default
this is C:\Program Files\Remote Desktop .
3. Run the following command to reset user data. You'll be prompted to confirm you
want to reset your user data.
PowerShell
.\msrdcw.exe /reset
You can also add the /f option, where your user data will be reset without
confirmation:
PowerShell
.\msrdcw.exe /reset /f
Authentication and identity

In this section you'll find troubleshooting guidance for authentication and identity issues
with the Remote Desktop client.
The logon attempt failed

If you come across an error saying The logon attempt failed on the Windows Security
credential prompt, verify the following:
You're using a device that is Azure AD-joined or hybrid Azure AD-joined to the
same Azure AD tenant as the session host.
The PKU2U protocol is enabled on both the local PC and the session host.
Per-user multi-factor authentication is disabled for the user account as it's not
supported for Azure AD-joined VMs.
The sign-in method you're trying to use isn't allowed

If you come across an error saying The sign-in method you're trying to use isn't
allowed. Try a different sign-in method or contact your system administrator, you
have Conditional Access policies restricting access. Follow the instructions in Enforce
Azure Active Directory Multi-Factor Authentication for Azure Virtual Desktop using
Conditional Access to enforce Azure Active Directory Multi-Factor Authentication for
your Azure AD-joined VMs.
A specified logon session does not exist. It may already

have been terminated.
If you come across an error that says, An authentication error occurred. A specified
logon session does not exist. It may already have been terminated, verify that you
properly created and configured the Kerberos server object when configuring single
sign-on.
Authentication issues while using an N SKU of Windows

Authentication issues can happen because you're using an N SKU of Windows on your
local device without the Media Feature Pack. For more information and to learn how to
install the Media Feature Pack, see Media Feature Pack list for Windows N editions .
Authentication issues when TLS 1.2 not enabled

Authentication issues can happen when your local Windows device doesn't have TLS 1.2
enabled. To enable TLS 1.2, you need to set the following registry values:
Key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL
\Protocols\TLS 1.2\Client
Value Name Type Value Data
DisabledByDefault DWORD 0
Enabled DWORD 1
Key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL
\Protocols\TLS 1.2\Server

DisabledByDefault DWORD 0
Enabled DWORD 1
Key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319
SystemDefaultTlsVersions DWORD 1
SchUseStrongCrypto DWORD 1
You can configure these registry values by opening PowerShell as an administrator and
running the following commands:
PowerShell
New-Item
'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols
\TLS 1.2\Server' -Force
\TLS 1.2\Server' -Name 'Enabled' -Value '1' -PropertyType 'DWORD' -Force
\TLS 1.2\Server' -Name 'DisabledByDefault' -Value '0' -PropertyType 'DWORD'
-Force
New-Item
\TLS 1.2\Client' -Force
\TLS 1.2\Client' -Name 'Enabled' -Value '1' -PropertyType 'DWORD' -Force
\TLS 1.2\Client' -Name 'DisabledByDefault' -Value '0' -PropertyType 'DWORD'
-Force
New-Item 'HKLM:\SOFTWARE\Microsoft\.NETFramework\v4.0.30319' -Force
New-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\.NETFramework\v4.0.30319' -

Name 'SystemDefaultTlsVersions' -Value '1' -PropertyType 'DWORD' -Force
New-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\.NETFramework\v4.0.30319' -

Name 'SchUseStrongCrypto' -Value '1' -PropertyType 'DWORD' -Force
Issue isn't listed here

If your issue isn't listed here, see Troubleshooting overview, feedback, and support for
Azure Virtual Desktop for information about how to open an Azure support case for
 Documentation
Set up email discovery to subscribe to your RDS feed

Learn how to set up email discovery in your RDS deployment.
Configure device redirection - Azure

How to configure device redirection for Azure Virtual Desktop.



Desktop.
Show 5 more
Troubleshoot the Remote Desktop Web
client when connecting to Azure Virtual
Desktop
This article describes issues you may experience with the Remote Desktop Web client
when connecting to Azure Virtual Desktop and how to fix them.
General
Desktop client.

a workspace.

device

） Important

Kusto

Web client stops responding or disconnects

If the Remote Desktop Web client stops responding or keeps disconnecting, try closing
and reopening the browser. If it continues, try connecting using another browser or a
one of the other Remote Desktop clients. You can also try clearing your browsing data.
For Microsoft Edge, see Microsoft Edge, browsing data, and privacy
.
Web client out of memory
If you see the error message "Oops, we couldn't connect to 'SessionDesktop'" (where
SessionDesktop is the name of the resource you're connecting to), then the web client
has run out of memory.
To resolve this issue, you'll need to either reduce the size of the browser window so a
smaller resolution will be used, or disconnect all existing connections and try connecting
again. If you still encounter this issue after doing these things, contact your admin for
help.
Network
In this section you'll find troubleshooting guidance for network issues with the Remote
Desktop client.
Web client won't open

The URL for the Remote Desktop Web client is
https://client.wvd.microsoft.com/arm/webclient/ . If this page doesn't open, try the
following:
1. Test your internet connection by opening another website in your browser, for
example https://www.bing.com .
2. From PowerShell or Command Prompt on Windows, or Terminal on macOS, you

can test if your DNS server can resolve the fully qualified domain name (FQDN) by
running the following command:
PowerShell
nslookup client.wvd.microsoft.com
If neither of these work you most likely have a problem with your network connection.
Contact your network admin for help.
 Tip
For the URLs of other Azure environments, such as Azure US Gov and Azure China
21Vianet, see Connect to Azure Virtual Desktop with the Remote Desktop Web
client.
Sign in failed. Please check your username and password

and try again
If you come across an error saying Oops, we couldn't connect to NAME. Sign in failed.
Please check your username and password and try again. when using the web client,
ensure that you enabled connections from other clients.
We couldn't connect to the remote PC because of a

security error
If you come across an error saying Oops, we couldn't connect to NAME. We couldn't
connect to the remote PC because of a security error. If this keeps happening, ask
your admin or tech support for help., you have Conditional Access policies restricting
access. Follow the instructions in Enforce Azure Active Directory Multi-Factor
Authentication for Azure Virtual Desktop using Conditional Access to enforce Azure
Active Directory Multi-Factor Authentication for your Azure AD-joined VMs.

for macOS when connecting to Azure
Virtual Desktop
macOS when connecting to Azure Virtual Desktop and how to fix them.
General
Desktop client.

a workspace.

device

） Important

Kusto


Account switch detected

If you see the error Account switch detected, you need to refresh the Azure AD token.
To refresh the Azure AD token, do the following:
1. Delete any workspaces from the Remote Desktop client. For more information, see
Edit, refresh, or delete a workspace.
2. Open the Keychain Access app on your device.
3. Under Default Keychains, select login, then select All Items.
4. In the search box, enter https://www.wvd.microsoft.com .
5. Double-click to open an entry with the name accesstoken.
6. Copy the first part of the value for Account, up to the first hyphen, for example
70f0a61f.
7. Enter the value you copied into the search box.
8. Right-click and delete each entry containing this value.
9. If you have multiple entries when searching for https://www.wvd.microsoft.com ,

repeat these steps for each entry.
10. Try to subscribe to a workspace again. For more information, see Connect to Azure
Virtual Desktop with the Remote Desktop client for macOS.
Display
In this section you'll find troubleshooting guidance for display issues with the Remote
Desktop client.
Blank screen or cursor skipping when using multiple

monitors
Using multiple monitors in certain topologies can cause issues such as blank screens or
the cursor skipping. Often this is a result of customized display configurations that
create edge cases for the client's graphics algorithm when Retina optimizations are
turned on, we're aware of these issues and plan to resolve them in future updates. For
now, if you encounter display issues such as these, use a different configuration or
disabling Retina optimization. To disable Retina optimization, see Display settings for
each remote desktop.
for iOS and iPadOS when connecting to
This article describes issues you may experience with the Remote Desktop client for iOS
and iPadOS when connecting to Azure Virtual Desktop and how to fix them.
General
Desktop client.

a workspace.

device

） Important

Kusto


Delete existing security tokens

If you're having issues signing in due to a cached token that has expired, do the
following:
1. Open the Settings app for iOS or iPadOS.
2. From the list of apps, select RD Client.
3. Under AVD Security Tokens, toggle Delete on App Launch to On.
4. Try to subscribe to a workspace again. For more information, see Connect to Azure
Virtual Desktop with the Remote Desktop client for iOS and iPadOS.
5. Toggle Delete on App Launch to Off once you can connect again.

for Android and Chrome OS when
Android and Chrome OS when connecting to Azure Virtual Desktop and how to fix
them.
General
Desktop client.

a workspace.

device

） Important

Kusto


Error code 2607 - We couldn't connect to the remote PC
because your credentials did not work
If you come across an error saying We couldn't connect to the remote PC because your
credentials did not work. The remote machine is AADJ joined. with error code 2607
when using the Android client, ensure that you enabled connections from other clients.

for Windows (Microsoft Store) when
Windows (Microsoft Store) when connecting to Azure Virtual Desktop and how to fix
them.
General
Desktop client.

a workspace.

device

） Important

Kusto


Diagnose graphics performance issues
in Remote Desktop
To diagnose experience quality issues with your remote sessions, counters have been
provided under the RemoteFX Graphics section of Performance Monitor. This article
helps you pinpoint and fix graphics-related performance bottlenecks during Remote
Desktop Protocol (RDP) sessions using these counters.
Find your remote session name

You'll need your remote session name to identify the graphics performance counters.
Follow the instructions in this section to identify your instance of each counter.
1. Open the Windows command prompt from your remote session.

2. Run the qwinsta command and find your session name.
If your session is hosted in a multi-session virtual machine (VM): Your

instance of each counter is suffixed by the same number that suffixes your
session name, such as "rdp-tcp 37."
If your session is hosted in a VM that supports virtual Graphics Processing
Units (vGPU): Your instance of each counter is stored on the server instead of
in your VM. Your counter instances include the VM name instead of the
number in the session name, such as "Win8 Enterprise VM."
７ Note
While counters have RemoteFX in their names, they include remote desktop
graphics in vGPU scenarios as well.
Access performance counters

After you've determined your remote session name, follow these instructions to collect
the RemoteFX Graphics performance counters for your remote session.
1. Select Start > Administrative Tools > Performance Monitor.

2. In the Performance Monitor dialog box, expand Monitoring Tools, select
Performance Monitor, and then select Add.
3. In the Add Counters dialog box, from the Available Counters list, expand the
section for RemoteFX Graphics.
4. Select the counters to be monitored.
5. In the Instances of selected object list, select the specific instances to be
monitored for the selected counters and then select Add. To select all available
counter instances, select All instances.
6. After adding the counters, select OK.
The selected performance counters will appear on the Performance Monitor screen.
７ Note
Each active session on a host has its own instance of each performance counter.
Diagnose issues
Graphics-related performance issues generally fall into four categories:
Low frame rate

Random stalls
High input latency
Poor frame quality
Addressing low frame rate, random stalls, and high input

latency
First check the Output Frames/Second counter. It measures the number of frames made
available to the client. If this value is less than the Input Frames/Second counter, frames
are being skipped. To identify the bottleneck, use the Frames Skipped/Second counters.
There are three types of Frames Skipped/Second counters:
Frames Skipped/Second (Insufficient Server Resources)

Frames Skipped/Second (Insufficient Network Resources)
Frames Skipped/Second (Insufficient Client Resources)
A high value for any of the Frames Skipped/Second counters implies that the problem is
related to the resource the counter tracks. For example, if the client doesn't decode and
present frames at the same rate the server provides the frames, the Frames
Skipped/Second (Insufficient Client Resources) counter will be high.
If the Output Frames/Second counter matches the Input Frames/Second counter, yet
you still notice unusual lag or stalling, Average Encoding Time may be the culprit.
Encoding is a synchronous process that occurs on the server in the single-session
(vGPU) scenario and on the VM in the multi-session scenario. Average Encoding Time
should be under 33 ms. If Average Encoding Time is under 33 ms but you still have
performance issues, there may be an issue with the app or operating system you are
using.
For more information about diagnosing app-related issues, see User Input Delay
Because RDP supports an Average Encoding Time of 33 ms, it supports an input frame
rate up to 30 frames/second. Note that 33 ms is the maximum supported frame rate. In
many cases, the frame rate experienced by the user will be lower, depending on how
often a frame is provided to RDP by the source. For example, tasks like watching a video
require a full input frame rate of 30 frames/second, but less computationally intensive
tasks like infrequently editing a document result in a much lower value for Input
Frames/Second with no degradation in the user's experience quality.
Addressing poor frame quality

Use the Frame Quality counter to diagnose frame quality issues. This counter expresses
the quality of the output frame as a percentage of the quality of the source frame. The
quality loss may be due to RemoteFX, or it may be inherent to the graphics source. If
RemoteFX caused the quality loss, the issue may be a lack of network or server
resources to send higher-fidelity content.
Mitigation
If server resources are causing the bottleneck, try one of the following approaches to
improve performance:
Reduce the number of sessions per host.

Increase the memory and compute resources on the server.
Drop the resolution of the connection.
If network resources are causing the bottleneck, try one of the following approaches to
improve network availability per session:
Reduce the number of sessions per host.

Use a higher-bandwidth network.
Drop the resolution of the connection.
If client resources are causing the bottleneck, try one of the following approaches to
improve performance:
Install the most recent Remote Desktop client.

Increase memory and compute resources on the client machine.
７ Note
We currently don't support the Source Frames/Second counter. For now, the Source
Frames/Second counter will always display 0.
Next steps
To create a GPU optimized Azure virtual machine, see Configure graphics
processing unit (GPU) acceleration for Azure Virtual Desktop environment.
For an overview of troubleshooting and escalation tracks, see Troubleshooting
overview, feedback, and support.
To learn more about the service, see Windows Desktop environment.
Troubleshoot connections to Azure AD-
joined VMs
） Important
Virtual Desktop objects.
Use this article to resolve issues with connections to Azure Active Directory (Azure AD)-
joined session host VMs in Azure Virtual Desktop.
All clients

device

） Important
Kusto

The logon attempt failed

If you come across an error saying The logon attempt failed on the Windows Security
credential prompt, verify the following:
You're using a device that is Azure AD-joined or hybrid Azure AD-joined to the
same Azure AD tenant as the session host.
The PKU2U protocol is enabled on both the local PC and the session host.
Per-user multi-factor authentication is disabled for the user account as it's not
supported for Azure AD-joined VMs.
The sign-in method you're trying to use isn't allowed

If you come across an error saying The sign-in method you're trying to use isn't
allowed. Try a different sign-in method or contact your system administrator, you
have Conditional Access policies restricting access. Follow the instructions in Enforce
Azure Active Directory Multi-Factor Authentication for Azure Virtual Desktop using
Conditional Access to enforce Azure Active Directory Multi-Factor Authentication for
your Azure AD-joined VMs.
A specified logon session does not exist. It may already

have been terminated.
If you come across an error that says, An authentication error occurred. A specified
logon session does not exist. It may already have been terminated, verify that you
properly created and configured the Kerberos server object when configuring single
sign-on.
Web client
Sign in failed. Please check your username and password

and try again
If you come across an error saying Oops, we couldn't connect to NAME. Sign in failed.
Please check your username and password and try again. when using the web client,
ensure that you enabled connections from other clients.
We couldn't connect to the remote PC because of a

security error
If you come across an error saying Oops, we couldn't connect to NAME. We couldn't
connect to the remote PC because of a security error. If this keeps happening, ask
your admin or tech support for help., you have Conditional Access policies restricting
access. Follow the instructions in Enforce Azure Active Directory Multi-Factor
Authentication for Azure Virtual Desktop using Conditional Access to enforce Azure
Active Directory Multi-Factor Authentication for your Azure AD-joined VMs.
Android and Chrome OS client
Error code 2607 - We couldn't connect to the remote PC

because your credentials did not work
If you come across an error saying We couldn't connect to the remote PC because your
credentials did not work. The remote machine is AADJ joined. with error code 2607
when using the Android client, ensure that you enabled connections from other clients.
Provide feedback
Next steps
creation.
Troubleshoot device redirections for
） Important
Virtual Desktop objects.
Use this article to resolve issues with device redirections in Azure Virtual Desktop.
WebAuthn redirection
If WebAuthn requests from the session aren't redirected to the local PC, check to make
sure you've fulfilled the following requirements:
Are you using supported operating systems for in-session passwordless

authentication on both the local PC and session host?
Have you enabled WebAuthn redirection as a device redirection?
If you've answered "yes" to both of the earlier questions but still don't see the option to
use Windows Hello for Business or security keys when accessing Azure AD resources,
make sure you've enabled the FIDO2 security key method for the user account in Azure
AD. To enable this method, follow the directions in Enable FIDO2 security key method.
If a user signs in to the session host with a single-factor credential like username and
password, then tries to access an Azure AD resource that requires MFA, they may not be
able to use Windows Hello for Business. The user should follow these instructions to
authenticate properly:
1. If the user isn't prompted for a user account, they should first sign out.
2. On the account selection page, select Use another account.
3. Next, choose Sign-in options at the bottom of the window.
4. After that, select Sign in with Windows Hello or a security key. They should see an
option to select Windows Hello or security authentication methods.
Provide feedback
Next steps
creation.
To go through a troubleshooting tutorial, see Tutorial: Troubleshoot Resource
Troubleshoot Azure Virtual Desktop
Insights
This article presents known issues and solutions for common problems in Azure Virtual
Desktop Insights.
） Important
The Log Analytics Agent is currently being deprecated . While Azure Virtual
Desktop Insights currently uses the Log Analytics Agent for Azure Virtual Desktop
support, you'll eventually need to migrate to the Azure Monitor Agent by August
31, 2024. We'll provide instructions for how to migrate when we release the update
that allows Azure Virtual Desktop Insights to support the Azure Monitor Agent.
Until then, continue to use the Log Analytics Agent.
Issues with configuration and setup

If the configuration workbook isn't working properly to automate setup, you can use
these resources to set up your environment manually:
To manually enable diagnostics or access the Log Analytics workspace, see Send
Azure Virtual Desktop diagnostics to Log Analytics.
To install the Log Analytics extension on a session host manually, see Log Analytics
virtual machine extension for Windows.
To set up a new Log Analytics workspace, see Create a Log Analytics workspace in
the Azure portal.
To add, remove, or edit performance counters, see Configuring performance
counters.
To configure Windows Event Logs for a Log Analytics workspace, see Collect
Windows event log data sources with Log Analytics agent.
My data isn't displaying properly

If your data isn't displaying properly, check the following common solutions:
First, make sure you've set up correctly with the configuration workbook as
described in Use Azure Virtual Desktop Insights to monitor your deployment. If
you're missing any counters or events, the data associated with them won't appear
in the Azure portal.
Check your access permissions & contact the resource owners to request missing
permissions; anyone monitoring Azure Virtual Desktop requires the following
permissions:
Read-access to the Azure resource groups that hold your Azure Virtual Desktop
resources
Read-access to the subscription's resource groups that hold your Azure Virtual
Desktop session hosts
Read-access to whichever Log Analytics workspaces you're using
You may need to open outgoing ports in your server's firewall to allow Azure
Monitor and Log Analytics to send data to the portal. To learn how to do this, see
the following articles:
- Azure Monitor Outgoing ports
- Log Analytics Firewall
Requirements.
Not seeing data from recent activity? You may want to wait for 15 minutes and
refresh the feed. Azure Monitor has a 15-minute latency period for populating log
data. To learn more, see Log data ingestion time in Azure Monitor.
If you're not missing any information but your data still isn't displaying properly, there
may be an issue in the query or the data sources. Review known issues and limitations.
I want to customize Azure Virtual Desktop

Insights
Azure Virtual Desktop Insights uses Azure Monitor Workbooks. Workbooks lets you save
a copy of the Azure Virtual Desktop workbook template and make your own
customizations.
By design, custom Workbook templates will not automatically adopt updates from the
products group. For more information, see Troubleshooting workbook-based insights
and the Workbooks overview.
I can't interpret the data

Learn more about data terms at the Azure Virtual Desktop Insights glossary.
The data I need isn't available

If you want to monitor more Performance counters or Windows Event Logs, you can
enable them to send diagnostics info to your Log Analytics workspace and monitor
them in Host Diagnostics: Host browser.
To add performance counters, see Configuring performance counters

To add Windows Events, see Configuring Windows Event Logs
Can't find a data point to help diagnose an issue? Send us feedback!
To learn how to leave feedback, see Troubleshooting overview, feedback, and

feedback hub .

The following are issues and limitations we're aware of and working to fix:
You can only monitor one host pool at a time unless you select Insights (Preview)
where you can you select multiple subscriptions, resource groups, and host pools
at a time.
To save favorite settings, you have to save a custom template of the workbook.
Custom templates won't automatically adopt updates from the product group.
The configuration workbook will sometimes show "query failed" errors when
loading your selections. Refresh the query, reenter your selection if needed, and
the error should resolve itself.
Some error messages aren't phrased in a user-friendly way, and not all error
messages are described in documentation.
The total sessions performance counter can over-count sessions by a small number
and your total sessions may appear to go above your Max Sessions limit.
Available sessions count doesn't reflect scaling policies on the host pool.
Do you see contradicting or unexpected connection times? While rare, a
connection's completion event can go missing and can impact some visuals and
metrics.
Time to connect includes the time it takes users to enter their credentials; this
correlates to the experience but in some cases can show false peaks.
Next steps
To get started, see Use Azure Virtual Desktop Insights to monitor your deployment.
Monitor costs.
Check out our glossary to learn more about terms and concepts related to Azure
 Documentation

Azure Virtual Desktop diagnostics log analytics - Azure

How to use log analytics with the Azure Virtual Desktop diagnostics feature.


Azure Virtual Desktop management issues - Azure

Common management issues in Azure Virtual Desktop and how to solve them.
How to monitor with Azure Virtual Desktop Insights - Azure

How to use Azure Virtual Desktop Insights.

environment.

Show 5 more
 Training

Monitor the usage, performance, and availability of resources with Azure Monitor -
Training
Learn how to monitor the usage, performance, and availability of resources using Azure Monitor.
Troubleshoot Azure Files authentication
with Active Directory
This article describes common issues related to Azure Files authentication with an Active
Directory Domain Services (AD DS) domain or Azure Active Directory Domain Services
(Azure AD DS) managed domain, and suggestions for how to fix them.
My group membership isn't working

When you add a virtual machine (VM) to an AD DS group, you must restart that VM to
activate its membership within the service.
I can't add my storage account to my AD DS

domain
First, check Unable to mount Azure file shares with AD credentials to see if your problem
is listed there.
Here are the most common reasons users may come across issues:
Ignoring any warning messages that appear when creating the account in
PowerShell. Ignoring warnings may cause the new account to have incorrectly
configured settings. To fix this issue, you should delete the domain account that
represents the storage account and try again.
The account is using an incorrect organizational unit (OU). To fix this issue, reenter
the OU information with the following syntax:
PowerShell
DC=ouname,DC=domainprefix,DC=topleveldomain
For example:
PowerShell
DC=storageAccounts,DC=wvdcontoso,DC=com
If the storage account doesn't instantly appear in your Azure AD, don't worry. It
usually takes 30 minutes for a new storage account to sync with Azure AD, so be
patient. If the sync doesn't happen after 30 minutes, see the next section.
My AD DS group won't sync to Azure AD

If your storage account doesn't automatically sync with Azure AD after 30 minutes, you'll
need to force the sync by using this script .
My storage account says it needs additional

permissions
If your storage account needs additional permissions, you may not have assigned the
required Azure role-based access control (RBAC) role to users or NTFS permissions. To
fix this issue, make sure you've assigned one of these permissions to users who need to
access the share:
The Storage File Data SMB Share Contributor RBAC permission.
The Read & Execute and List folder content NTFS permissions.
Next steps
If you need to refresh your memory about the Azure Files setup process, see Set up
FSLogix Profile Container with Azure Files and Active Directory Domain Services or Azure
Active Directory Domain Services.
 Documentation


Manage app groups for Azure Virtual Desktop (classic) - Azure

Learn how to set up Azure Virtual Desktop (classic) tenants in Azure Active Directory (Azure AD).


Azure
Desktop.

environment.

Show 5 more
 Training

Deploy and manage identity infrastructure - Training
Deploy and manage identity infrastructure
Troubleshooting connection quality in
If you experience issues with graphical quality in your Azure Virtual Desktop connection,
you can use the Network Data diagnostic table to figure out what's going on. Graphical
quality during a connection is affected by many factors, such as network configuration,
network load, or virtual machine (VM) load. The Connection Network Data table can
help you figure out which factor is causing the issue.
Addressing round trip time

In Azure Virtual Desktop, latency up to 150 ms shouldn’t impact user experience that
doesn't involve rendering or video. Latencies between 150 ms and 200 ms should be
fine for text processing. Latency above 200 ms may impact user experience.
In addition, the Azure Virtual Desktop connection depends on the internet connection
of the machine the user is using the service from. Users may lose connection or
experience input delay in one of the following situations:
The user doesn't have a stable local internet connection and the latency is over 200
ms.
The network is saturated or rate-limited.
To reduce round trip time:
Reduce the physical distance between end-users and the server. When possible,
your end-users should connect to VMs in the Azure region closest to them.
Check your network configuration. Firewalls, ExpressRoutes, and other network

configuration features can affect round trip time.
Check if something is interfering with your network bandwidth. If your network's

available bandwidth is too low, you may need to change your network settings to
improve connection quality. Make sure your configured settings follow our
network guidelines.
Check your compute resources by looking at CPU utilization and available memory
on your VM. You can view your compute resources by following the instructions in
Configuring performance counters to set up a performance counter to track
certain information. For example, you can use the Processor Information(_Total)\%
Processor Time counter to track CPU utilization, or the Memory(*)\Available
Mbytes counter for available memory. Both of these counters are enabled by
default in Azure Virtual Desktop Insights. If both counters show that CPU usage is
too high or available memory is too low, your VM size or storage may be too small
to support your users' workloads, and you'll need to upgrade to a larger size.
Optimize VM latency with the Azure Virtual

Desktop Experience Estimator tool
The Azure Virtual Desktop Experience Estimator tool can help you determine the best
location to optimize the latency of your VMs. We recommend you use the tool every
two to three months to make sure the optimal location hasn't changed as Azure Virtual
Desktop rolls out to new areas.
My connection data isn't going to Azure Log

Analytics
If your Connection Network Data Logs aren't going to Azure Log Analytics every two
minutes, you'll need to check the following things:
Make sure you've configured the diagnostic settings correctly.

Make sure you've configured the VM correctly.
Make sure you're actively using the session. Sessions that aren't actively used won't
send data to Azure Log Analytics as frequently.
Next steps
For more information about how to diagnose connection quality, see Connection quality
in Azure Virtual Desktop.
 Documentation

Limit the port range when using RDP Shortpath for public networks - Azure Virtual
Desktop
Learn how to limit the port range used by clients when using RDP Shortpath for public networks for
Azure Virtual Desktop, which establishes a UDP-based transport between a Remote Desktop client
and session host.



environment.

Azure Virtual Desktop management issues - Azure

Common management issues in Azure Virtual Desktop and how to solve them.
Show 5 more
 Training
Troubleshoot RDP Shortpath for public
networks
） Important
If you're having issues when using RDP Shortpath for public networks, use the
information in this article to help troubleshoot.
Verifying STUN/TURN server connectivity and

NAT type
You can validate connectivity to the STUN/TURN endpoints and verify that basic UDP
functionality works by running the executable avdnettest.exe . Here's a download link to
the latest version of avdnettest.exe .
You can run avdnettest.exe by double-clicking the file, or running it from the command
line. The output will look similar to this if connectivity is successful:
Checking DNS service ... OK
Checking TURN support ... OK
Checking ACS server 20.202.68.109:3478 ... OK
Checking ACS server 20.202.21.66:3478 ... OK
You have access to TURN servers and your NAT type appears to be 'cone
shaped'.
Shortpath for public networks is very likely to work on this host.
） Important
During the preview, TURN is only available for connections to session hosts in a
validation host pool. To configure your host pool as a validation environment, see
Define your host pool as a validation environment.
Error information logged in Log Analytics
Here are some error titles you may see logged in Log Analytics and what they mean.
ShortpathTransportNetworkDrop
For TCP we differentiate two different paths - the session host to the gateway, and the
gateway to client - but that doesn’t make sense for UDP since there isn't a gateway. The
other distinction for TCP is that in many cases one of the endpoints, or maybe some
infrastructure in the middle, generates a TCP Reset packet (RST control bit), which causes
a hard shutdown of the TCP connection. This works because TCP RST (and also TCP FIN
for graceful shutdown) is handled by the operating system and also some routers, but
not the application. This means that if an application crashes, Windows will notify the
peer that the TCP connection is gone, but no such mechanism exists for UDP.
Most connection errors, such as ConnectionFailedClientDisconnect and

ConnectionFailedServerDisconnect, are caused by TCP Reset packets, not a timeout.
There's no way for the operating system or a router to signal anything with UDP, so the
only way to know the peer is gone is by a timeout message.
ShortpathTransportReliabilityThresholdFailure
This error gets triggered if a specific packet doesn’t get through, even though the
connection isn't dead. The packet is resent up to 50 times, so it's unlikely but can
happen in the following scenarios:
1. The connection was very fast and stable before it suddenly stops working. The
timeout required until a packet is declared lost depends on the round-trip time
(RTT) between the client and session host. If the RTT is very low, one side can try to
resend a packet very frequently, so the time it takes to reach 50 tries can be less
than the usual timeout value of 17 seconds.
2. The packet is very large. The maximum packet size that can be transmitted is
limited. The size of the packet is probed, but it can fluctuate and sometimes shrink.
If that happens, it's possible that the packet being sent is too large and will
consistently fail.
ConnectionBrokenMissedHeartbeatThresholdExceeded
This is an RDP-level timeout. Due to misconfiguration, the RDP level timeout would
sometimes trigger before the UDP-level timeout.
 Documentation
What’s new in Azure Monitor for Azure Virtual Desktop?

New features and product updates for the Azure Virtual Desktop agent.

Azure Virtual Desktop sign-in screen is blank
Azure Virtual Desktop users might encounter sign-in issues that result in a black screen. There are multiple
possible causes for black screens, but users can be impacted from issues synchronizing with
AppReadiness, and multiple sessions signing in or out.
７ Note
These sign-in issues may also occur in the RDS environment, where user profiles are created every
sign-in and deleted every sign-out.
Causes
The following list contains known scenarios causing black screens, and the non-security fixes which
address them. This list does not cover every possible reason a black screen can occur. Verify that you have
the latest updates, as blank screen updates are being released on a near-monthly basis.
Issue Version Article #

of
Windows
The AppReadiness service sometimes fails to shut down waiting for Windows October 1, 2020—KB4577063 (OS
some COM objects to disconnect. Resulting in failed user sign-in or 2004 Build 19041.546) Preview
black screen in WVD scenario. (microsoft.com)
Windows September 16, 2020—KB4577062

1909 & (OS Builds 18362.1110 and
1903 18363.1110) Preview
(microsoft.com)
Windows September 16, 2020—KB4577069

1809 (OS Build 17763.1490) Preview
(microsoft.com)
Addresses an issue where the WVD user might experience a blank Windows November 30, 2020—KB4586853
screen during sign-in. 2004 (OS Builds 19041.662 and
19042.662) Preview
(microsoft.com)
Windows November 19, 2020—KB4586819

1909 & (OS Builds 18362.1237 and
1903 18363.1237) Preview
(microsoft.com)
Windows November 19, 2020—KB4586839

1809 (OS Build 17763.1613) Preview
(microsoft.com)
Addresses an issue that displays a black screen to Azure Virtual 1909 October 20, 2020—KB4580386 (OS
Desktop users when they attempt to sign in. &1903 Builds 18362.1171 and
18363.1171) Preview
(microsoft.com)
Issue Version Article #
of
Windows
Windows October 20, 2020—KB4580390 (OS

1809 Build 17763.1554) Preview
(microsoft.com)
Desktop gets a black screen due to shell not starting AppXSvc Windows September 3, 2020—KB4571744
deadlock. Addresses an issue that displays a black screen to Azure 2004 (OS Build 19041.488) Preview
Virtual Desktop users when they attempt to sign in. (microsoft.com)
Windows April 21, 2020—KB4550945 (OS

1909 & Builds 18362.815 and 18363.815)
1903 (microsoft.com)
Windows April 21, 2020—KB4550969 (OS

1809 Build 17763.1192)
(microsoft.com)
Resolution
７ Note
Workarounds should not be considered long-term solutions. Back up your registry keys anytime that
you test changes.
If the black screen is tied with AppReadiness issues, set the following registry
entries for the AppReadiness pre-shell task, and then change the first sign-in’s timeout window to 30
seconds to avoid the black screen for the first user’s sign-in.
Registry Location Data Value New

Type timeout
duration
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\AppReadinessPreShellTimeoutMs Data Value: 30000

Type: 0x7530 ms = 30s
DWORD
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\FirstLogonTimeout Data Value: 30000

Type: 0x1e ms = 30s
DWORD
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\DelayedDesktopSwitchTimeout Data Value: 30000

Type: 0x1e ms = 30s
DWORD
More Information
If you continue to see black screens after you confirm that you have the latest updates, perform a full
memory dump and include it in a support case.
Find the steps to enable and collect a dump file at Collect an OS memory dump
Contact us for help
If you have questions or need help, create a support request , or ask Azure community support. You can
also submit product feedback to Azure community support.
Feedback
Was this page helpful? ﾂ Yes ﾄ No
Provide product feedback

| Get help at Microsoft Q&A
Troubleshoot multimedia redirection for
７ Note
Azure Virtual Desktop doesn't currently support multimedia redirection on Azure

Virtual Desktop for Microsoft 365 Government (GCC), GCC-High environments, and
Microsoft 365 DoD.
Desktop client, version 1.2.3916 or later. on Windows 11, Windows 10, or Windows
10 IoT Enterprise devices.
This article describes known issues and troubleshooting instructions for multimedia
redirection (MMR) for Azure Virtual Desktop.

The following issues are ones we're already aware of, so you won't need to report them:
In the first browser tab a user opens, the extension pop-up might show a message
that says, "The extension is not loaded", or a message that says video playback or
calling redirection isn't supported while redirection is working correctly in the tab.
You can resolve this issue by opening a second tab.
Multimedia redirection only works on the Windows Desktop client.
Multimedia redirection doesn't currently support protected content, so videos

from Netflix, for example, won't work.
When you resize the video window, the window's size will adjust faster than the
video itself. You'll also see this issue when minimizing and maximizing the window.
You might run into issue where you are stuck in the loading state on every video
site. This is a known issue that we're currently investigating. To temporarily
mitigate this issue, sign out of Azure Virtual Desktop and restart your session.
The MSI installer doesn't work

There's a small chance that the MSI installer won't be able to install the extension
during internal testing. If you run into this issue, you'll need to install the
multimedia redirection extension from the Microsoft Edge Store or Google Chrome
Store.
Multimedia redirection browser extension (Microsoft Edge)
Multimedia browser extension (Google Chrome)
Installing the extension on host machines with the MSI installer will either prompt
users to accept the extension the first time they open the browser or display a
warning or error message. If users deny this prompt, it can cause the extension to
not load. To avoid this issue, install the extensions by editing the group policy.
Sometimes the host and client version number disappears from the extension
status message, which prevents the extension from loading on websites that
support it. If you've installed the extension correctly, this issue is because your host
machine doesn't have the latest C++ Redistributable installed. To fix this issue,
install the latest supported Visual C++ Redistributable downloads.
Video playback redirection

Video playback redirection only works on the Windows Desktop client, not the web
client or other platforms such as macOS, Linux, and so on.
Video playback redirection doesn't currently support protected content, so videos

from Pluralsight and Netflix won't work.
When you resize the video window, the window's size will adjust faster than the
video itself. You'll also see this issue when minimizing and maximizing the window.
Log collection
If you encounter any issues, you can collect logs from the extension and provide them
to your IT admin or support.
To enable log collection:
1. Select the multimedia redirection extension icon in your browser.
3. For Collect logs, select Start.

Next steps
For more information about this feature and how it works, see What is multimedia
redirection for Azure Virtual Desktop?.
To learn how to use this feature, see Multimedia redirection for Azure Virtual Desktop.
 Documentation




How to use multimedia redirection on Azure Virtual Desktop.



environment.
Collect and query Azure Virtual Desktop connection quality data (preview) - Azure
How to set up and query the connection quality data table for Azure Virtual Desktop to diagnose
connection issues.
Show 5 more
Troubleshoot Microsoft Teams for Azure
Virtual Desktop
This article describes known issues and limitations for Teams on Azure Virtual Desktop,
as well as how to log issues and contact support.

Using Teams in a virtualized environment is different from using Teams in a non-
virtualized environment. For more information about the limitations of Teams in
virtualized environments, check out Teams for Virtualized Desktop Infrastructure.
Client deployment, installation, and setup

With per-machine installation, Teams on VDI isn't automatically updated the same
way non-VDI Teams clients are. To update the client, you'll need to update the VM
image by installing a new MSI.
Media optimization for Teams is only supported for the Remote Desktop client on
machines running Windows 10 or later or macOS 10.14 or later.
Use of explicit HTTP proxies defined on the client endpoint device isn't supported.
Zoom in/zoom out of chat windows isn't supported.
Calls and meetings

Due to WebRTC limitations, incoming and outgoing video stream resolution is
limited to 720p.
The Teams app doesn't support HID buttons or LED controls with other devices.
This feature doesn't support uploading custom background images.
This feature doesn’t support taking screenshots for incoming videos from the
virtual machine (VM). As a workaround, we recommend you minimize the session
desktop window and screenshot from the client machine instead.
This feature doesn't support content sharing for redirected videos during screen
sharing and application window sharing.
The following issues occur during application window sharing:
You currently can't select minimized windows. In order to select windows, you'll
need to maximize them first.
If you've opened a window overlapping the window you're currently sharing
during a meeting, the contents of the shared window that are covered by the
overlapping window won't update for meeting users.
If you're sharing admin windows for programs like Windows Task Manager,
meeting participants may see a black area where the presenter toolbar or call
monitor is located.
Switching tenants can result in call-related issues such as screen sharing not
rendering correctly. You can mitigate these issues by restarting your Teams client.
For Teams known issues that aren't related to virtualized environments, see Support
Teams in your organization.
Collect Teams logs

If you encounter issues with the Teams desktop app in your Azure Virtual Desktop
environment, collect client logs under %appdata%\Microsoft\Teams\logs.txt on the
host VM.
If you encounter issues with calls and meetings, you can start collecting Teams
diagnostic logs with the key combination Ctrl + Alt + Shift + 1. Logs will be written to
%userprofile%\Downloads\MSTeams Diagnostics Log DATE_TIME.txt on the host VM.
Contact Microsoft Teams support

To contact Microsoft Teams support, go to the Microsoft 365 admin center.
Next steps
Learn more about how to set up Teams on Azure Virtual Desktop at Use Microsoft
Learn more about the WebSocket Services for Teams on Azure Virtual Desktop at What's
new in the WebSocket Service.
az desktopvirtualization
Reference
７ Note
This reference is part of the desktopvirtualization extension for the Azure CLI
(version 2.15.0 or higher). The extension will automatically install the first time you
run an az desktopvirtualization command. Learn more about extensions.
Manage desktop virtualization.
Commands
az desktopvirtualization Desktopvirtualization applicationgroup.
applicationgroup
az desktopvirtualization Create an applicationGroup.

applicationgroup create
az desktopvirtualization Remove an applicationGroup.

applicationgroup delete
az desktopvirtualization List applicationGroups in subscription.

applicationgroup list
az desktopvirtualization Get an application group.

applicationgroup show
az desktopvirtualization Update an applicationGroup.

applicationgroup update
az desktopvirtualization Desktopvirtualization hostpool.

hostpool
az desktopvirtualization Create a host pool.

hostpool create
az desktopvirtualization Remove a host pool.

hostpool delete
az desktopvirtualization List hostPools in subscription.

hostpool list
az desktopvirtualization Registration token of the host pool.

hostpool retrieve-registration-
token
az desktopvirtualization Get a host pool.

hostpool show
az desktopvirtualization Update a host pool.

hostpool update
az desktopvirtualization Desktopvirtualization workspace.

workspace
az desktopvirtualization Create a workspace.

workspace create
az desktopvirtualization Remove a workspace.

workspace delete
az desktopvirtualization List workspaces in subscription.

workspace list
az desktopvirtualization Get a workspace.

workspace show
az desktopvirtualization Update a workspace.

workspace update
Reference
DesktopVirtualization
Disconnect-AzWvdUserSession Disconnect a userSession.
Expand-AzWvdMsixImage Expands and Lists MSIX packages in an Image, given the

Image Path.
Get-AzWvdApplication Get an application.
Get-AzWvdApplicationGroup Get an application group.
Get-AzWvdDesktop Get a desktop.
Get-AzWvdHostPool Get a host pool.
Get- Registration token of the host pool.

AzWvdHostPoolRegistrationToken
Get-AzWvdMsixPackage Get a msixpackage.
Get-AzWvdRegistrationInfo Get the Windows virtual desktop registration info.
Get-AzWvdScalingPlan Get a scaling plan.
Get-AzWvdSessionHost Get a session host.
Get-AzWvdStartMenuItem List start menu items in the given application group.
Get-AzWvdUserSession Get a userSession.
Get-AzWvdWorkspace Get a workspace.
New-AzWvdApplication Create or update an application.
New-AzWvdApplicationGroup Create or update an applicationGroup.
New-AzWvdHostPool Create or update a host pool.
New-AzWvdMsixPackage Create or update a MSIX package.
New-AzWvdRegistrationInfo Create Windows virtual desktop registration info.
New-AzWvdScalingPlan Create or update a scaling plan.
New-AzWvdWorkspace Create or update a workspace.

Register-AzWvdApplicationGroup Register a Windows virtual desktop application group.
Remove-AzWvdApplication Remove an application.
Remove-AzWvdApplicationGroup Remove an applicationGroup.
Remove-AzWvdHostPool Remove a host pool.
Remove-AzWvdMsixPackage Remove an MSIX Package.
Remove-AzWvdRegistrationInfo Remove the Windows virtual desktop registration info.
Remove-AzWvdScalingPlan Remove a scaling plan.
Remove-AzWvdSessionHost Remove a SessionHost.
Remove-AzWvdUserSession Remove a userSession.
Remove-AzWvdWorkspace Remove a workspace.
Send-AzWvdUserSessionMessage Send a message to a user.
Unregister- Unregister the Windows virtual desktop application group.

AzWvdApplicationGroup
Update-AzWvdApplication Update an application.
Update-AzWvdApplicationGroup Update an applicationGroup.
Update-AzWvdDesktop Update a desktop.
Update-AzWvdHostPool Update a host pool.
Update-AzWvdMsixPackage Update an MSIX Package.
Update-AzWvdScalingPlan Update a scaling plan.
Update-AzWvdSessionHost Update a session host.
Update-AzWvdWorkspace Update a workspace.

Azure Virtual Desktop is a comprehensive desktop and app virtualization service running
in the cloud. It is the only virtual desktop infrastructure (VDI) that delivers simplified
management, multi-session Windows 10, optimizations for Microsoft 365 Apps for
enterprise. Deploy and scale your Windows desktops and apps on Azure in minutes, and
get built-in security and compliance features. The Desktop Virtualization APIs allow you
to create and manage your Azure Virtual Desktop environment programmatically. For
more information about Azure Virtual Desktop, see documentation.
REST Operation Groups

Operation Description
Group
Application Operations to create, update, delete, list application groups.

Groups
Applications Operations to create, update, delete, list applications.
Desktops Operations to get, update, list desktops.
Host Pools Operations to create, update, delete, list host pools.
MSIX Packages Operations to create, update, delete, list MSIX Package.
Msix Images Operations to expand MSIX Images.
Operations Operations to list available operations the Desktop virtualization resource

provider supports.
Scaling Plans Operations to create, update, delete, get, and list scaling plans.
Session Hosts Operations to update, delete, list session hosts.
Start Menu Retrieve list of start menu items.

Items
User Sessions Operations to disconnect, send message, get, delete, list user sessions.
Workspaces Operations to create, update, delete, list workspaces.

Migrate or deploy Azure Virtual
Desktop instances to Azure
Migrating an organization's end-user desktops to the cloud is a common scenario in

cloud migrations. Doing so helps improve employee productivity and accelerate the
migration of various workloads to support the organization's user experience.
Components of the scenario

This scenario is designed to guide the end-to-end customer journey, throughout the
cloud adoption lifecycle. Completing the journey requires a few key guidance sets:
Cloud Adoption Framework: These articles walk through the considerations and
recommendations of each CAF methodology. Use these articles to prepare
decision makers, central IT, and the cloud center of excellence for adoption of
Azure Virtual Desktop as a central part of your technology strategy.
Reference architectures: These reference solutions aid in accelerating deployment
of Azure Virtual Desktop.
Featured Azure products: Learn more about the products that support your virtual
desktop strategy in Azure.
Learn modules: Gain the hands-on skills required to implement, maintain, and
support a virtual desktop environment.
Common customer journeys

Azure Virtual Desktop reference architecture: The reference architecture
demonstrates how to deploy a proven architecture for Azure Virtual Desktop in
your environment. This architecture is a suggested starting point for Azure Virtual
Desktop.
Migrate existing virtual desktops to Azure: A common use case for Azure Virtual
Desktop is to modernize an existing virtual desktop environment. While the
process can vary, there are several components to a successful migration, like
session hosts, user profiles, images, and applications. If you're migrating existing
VMs, you can review articles on migration to learn how tools like Movere and
Azure Migrate can speed up your migration as part of a standard migration
process. However, your migration might consist of bringing your golden image
into Azure and provisioning a new Azure Virtual Desktop host pool with new
session hosts. You can migrate your existing user profiles into Azure and build new
host pools and session hosts as well. A final migration scenario might include
migrating your applications into MSIX app attach format. For all of these migration
scenarios, you need to provision a new host pool because there's currently no
direct migration of other virtual desktop infrastructure (VDI) solutions into Azure
Virtual Desktop.
Prepare for governance and operations at scale: Enterprise-scale support for

Azure Virtual Desktop demonstrates how you can use enterprise-scale landing
zones to ensure consistent governance, security, and operations across multiple
landing zones for centralized management of virtual desktop environments.
Implement specific Azure products: Accelerate and improve virtual desktop

capabilities using different kinds of Azure products outlined in the featured
products section.
Next steps
The following list of articles will take you to guidance at specific points in the cloud
adoption journey to help you be successful in the cloud adoption scenario.
Strategy for Azure Virtual Desktop

Plan for Azure Virtual Desktop
Migrate to Azure Virtual Desktop
Manage an Azure Virtual Desktop environment
Govern an Azure Virtual Desktop environment
Configure Azure Virtual Desktop with
Terraform
Article tested with the following Terraform and Terraform provider versions:
Terraform v1.1.7
AzureRM Provider v.2.99.0
Terraform enables the definition, preview, and deployment of cloud infrastructure.

Using Terraform, you create configuration files using HCL syntax . The HCL syntax
allows you to specify the cloud provider - such as Azure - and the elements that make
up your cloud infrastructure. After you create your configuration files, you create an
execution plan that allows you to preview your infrastructure changes before they're
deployed. Once you verify the changes, you apply the execution plan to deploy the
infrastructure.
This article provides an overview of how to use Terraform to deploy an ARM Azure
Virtual Desktop environment, not AVD Classic.
There are several pre-requisites requirements for Azure Virtual Desktop
New to Azure Virtual Desktop? Start with What is Azure Virtual Desktop?
It is assumed that an appropriate platform foundation is already setup which may or

may not be the Enterprise Scale Landing Zone platform foundation.
In this article, you learn how to:
＂ Use Terraform to create an Azure Virtual Desktop workspace

＂ Use Terraform to create an Azure Virtual Desktop host pool
＂ Use Terraform to create an Azure Desktop Application Group
＂ Associate a Workspace and a Desktop Application Group
1. Configure your environment

Azure subscription: If you don't have an Azure subscription, create a free
account before you begin.
Configure Terraform: If you haven't already done so, configure Terraform using
one of the following options:
Configure Terraform in Azure Cloud Shell with Bash
Configure Terraform in Azure Cloud Shell with PowerShell
Configure Terraform in Windows with Bash
Configure Terraform in Windows with PowerShell
2. Implement the Terraform code

1. Create a directory in which to test the sample Terraform code and make it the
current directory.
2. Create a file named providers.tf and insert the following code:
Terraform
terraform {
required_providers {
azurerm = {
source = "hashicorp/azurerm"
version = "~>2.0"
azuread = {
source = "hashicorp/azuread"
provider "azurerm" {
features {}
3. Create a file named main.tf and insert the following code:
Terraform
# Resource group name is output when execution plan is applied.
resource "azurerm_resource_group" "sh" {
name = var.rg_name
location = var.resource_group_location
# Create AVD workspace
resource "azurerm_virtual_desktop_workspace" "workspace" {
name = var.workspace
resource_group_name = azurerm_resource_group.sh.name
location = azurerm_resource_group.sh.location
friendly_name = "${var.prefix} Workspace"
description = "${var.prefix} Workspace"
# Create AVD host pool
resource "azurerm_virtual_desktop_host_pool" "hostpool" {
name = var.hostpool
friendly_name = var.hostpool
validate_environment = true
custom_rdp_properties = "audiocapturemode:i:1;audiomode:i:0;"
description = "${var.prefix} Terraform HostPool"
type = "Pooled"
maximum_sessions_allowed = 16
load_balancer_type = "DepthFirst" #[BreadthFirst DepthFirst]
resource "azurerm_virtual_desktop_host_pool_registration_info"
"registrationinfo" {
hostpool_id = azurerm_virtual_desktop_host_pool.hostpool.id
expiration_date = var.rfc3339
# Create AVD DAG
resource "azurerm_virtual_desktop_application_group" "dag" {
host_pool_id = azurerm_virtual_desktop_host_pool.hostpool.id
type = "Desktop"
name = "${var.prefix}-dag"
friendly_name = "Desktop AppGroup"
description = "AVD application group"
depends_on = [azurerm_virtual_desktop_host_pool.hostpool,
azurerm_virtual_desktop_workspace.workspace]
# Associate Workspace and DAG
resource
"azurerm_virtual_desktop_workspace_application_group_association" "ws-
dag" {
application_group_id =
azurerm_virtual_desktop_application_group.dag.id
workspace_id = azurerm_virtual_desktop_workspace.workspace.id
4. Create a file named variables.tf and insert the following code:
variable "resource_group_location" {
default = "eastus"
description = "Location of the resource group."
variable "rg_name" {
type = string
default = "rg-avd-resources"
description = "Name of the Resource group in which to deploy service

objects"
variable "workspace" {
type = string
description = "Name of the Azure Virtual Desktop workspace"
default = "AVD TF Workspace"
variable "hostpool" {
type = string
description = "Name of the Azure Virtual Desktop host pool"
default = "AVD-TF-HP"
variable "rfc3339" {
type = string
default = "2022-03-30T12:43:13Z"
description = "Registration token expiration"
variable "prefix" {
type = string
default = "avdtf"
description = "Prefix of the name of the AVD machine(s)"
5. Create a file named output.tf and insert the following code:
output "azure_virtual_desktop_compute_resource_group" {
description = "Name of the Resource group in which to deploy session

host"
value = azurerm_resource_group.sh.name
output "azure_virtual_desktop_host_pool" {
description = "Name of the Azure Virtual Desktop host pool"
value = azurerm_virtual_desktop_host_pool.hostpool.name
output "azurerm_virtual_desktop_application_group" {
description = "Name of the Azure Virtual Desktop DAG"
value = azurerm_virtual_desktop_application_group.dag.name
output "azurerm_virtual_desktop_workspace" {
description = "Name of the Azure Virtual Desktop workspace"
value = azurerm_virtual_desktop_workspace.workspace.name
output "location" {
description = "The Azure region"
value = azurerm_resource_group.sh.location
output "AVD_user_groupname" {
description = "Azure Active Directory Group for AVD users"
value = azuread_group.aad_group.display_name
3. Initialize Terraform
Run terraform init to initialize the Terraform deployment. This command downloads
the Azure provider required to manage your Azure resources.
Console
terraform init
4. Create a Terraform execution plan

Run terraform plan to create an execution plan.
Console
terraform plan -out main.tfplan
Key points:
The terraform plan command creates an execution plan, but doesn't execute it.
Instead, it determines what actions are necessary to create the configuration
specified in your configuration files. This pattern allows you to verify whether the
execution plan matches your expectations before making any changes to actual
resources.
The optional -out parameter allows you to specify an output file for the plan.
Using the -out parameter ensures that the plan you reviewed is exactly what is
applied.
To read more about persisting execution plans and security, see the security
warning section .
5. Apply a Terraform execution plan

Run terraform apply to apply the execution plan to your cloud infrastructure.
Console
terraform apply main.tfplan
Key points:
The terraform apply command above assumes you previously ran terraform plan
-out main.tfplan .
If you specified a different filename for the -out parameter, use that same
filename in the call to terraform apply .
If you didn't use the -out parameter, call terraform apply without any parameters.
6. Verify the results

1. On the Azure portal, Select Azure Virtual Desktop.
2. Select Host pools and then the Name of the pool created resource.
3. Select Session hosts and then verify the session host is listed.
7. Clean up resources
When you no longer need the resources created via Terraform, do the following steps:
1. Run terraform plan and specify the destroy flag.
Console
terraform plan -destroy -out main.destroy.tfplan
Key points:
The terraform plan command creates an execution plan, but doesn't execute
it. Instead, it determines what actions are necessary to create the
configuration specified in your configuration files. This pattern allows you to
verify whether the execution plan matches your expectations before making
any changes to actual resources.
The optional -out parameter allows you to specify an output file for the plan.
Using the -out parameter ensures that the plan you reviewed is exactly what
is applied.
To read more about persisting execution plans and security, see the security
warning section .
2. Run terraform apply to apply the execution plan.
Console
terraform apply main.destroy.tfplan
Troubleshoot Terraform on Azure

Troubleshoot common problems when using Terraform on Azure
Next steps
Learn more about using Terraform in Azure

About Azure Virtual Desktop

Uploaded by

Copyright:

Available Formats

About Azure Virtual Desktop

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

About Azure Virtual Desktop

Uploaded by

Copyright:

Available Formats

Tell us about your PDF experience.

Azure Virtual Desktop documentation

About Azure Virtual Desktop

What is Azure Virtual Desktop?

What's new in Azure Virtual Desktop?

Get started with Azure Virtual Desktop

Create and connect to a Windows 11 desktop with Azure Virtual Desktop

Create a host pool

Create an application group, a workspace, and assign users

Add session hosts to a host pool

Azure Virtual Desktop for users

Azure Virtual Desktop for users

Connect with the Windows Desktop client

Connect with the web client

Connect with macOS

Connect with iOS/iPadOS

Connect with Android/Chrome OS

Connect with thin clients

Introduction to Azure Virtual Desktop

More Azure Virtual Desktop learning paths

User experience estimator

Remote app streaming with Azure Virtual Desktop

Stream apps to your customers

Set up a multi-session Windows 11 or Windows 10 deployment that delivers a full

Create a full desktop virtualization environment in your Azure subscription without

You can deploy and manage virtual desktops:

Prerequisites for Azure Virtual Desktop

Deploy Azure Virtual Desktop with the getting started feature

Understanding total Azure Virtual Desktop deployment costs - Azure

Create a tenant in Azure Virtual Desktop (classic) - Azure

Azure Virtual Desktop host pool Azure portal - Azure

What's new in Azure Virtual Desktop? - Azure

What is Azure Virtual Desktop remote app streaming? - Azure

Azure Virtual Desktop terminology - Azure

Learning paths and modules

At a high level, you'll need:

＂ An Azure account with an active subscription

Azure account with an active subscription

You also need to make sure you've registered the Microsoft.DesktopVirtualization

1. Sign in to the Azure portal .

Supported identity scenarios

Identity scenario Session hosts User accounts

Azure AD + AD DS Joined to AD DS In Azure AD and AD DS, synchronized

Azure AD + AD DS Joined to Azure AD In Azure AD and AD DS, synchronized

Azure AD + Azure AD DS Joined to Azure AD In Azure AD and Azure AD DS,

Azure AD + Azure AD DS + AD Joined to Azure AD In Azure AD and AD DS, synchronized

Azure AD + Azure AD DS Joined to Azure AD In Azure AD and Azure AD DS,

Azure AD only Joined to Azure AD In Azure AD

Domain name, if using AD DS or Azure AD DS.

Operating systems and licenses

Operating system User access rights

Windows 11 License entitlement:

Windows License entitlement:

Support for Windows 7 ended on January 10, 2023.

Ephemeral OS disks for Azure VMs are not supported.

Store and share images in an Azure Compute Gallery.

Automatically, as part of the host pool setup process.

Operating Azure Manual VM Azure Resource Deploy host pools

Windows 11 Yes Yes Yes Yes