Azure Virtual Desktop

Azure Virtual Desktop (AVD) is a PaaS offering managed by Microsoft that allows administrators to configure, deploy, and manage, scalable flexible solutions. AVD enables administrators to publish full desktops or remote apps from a single host pool or create individual app groupings for different sets of users.

Using the Windows 10 Enterprise multi-session capability exclusively available to Azure Virtual Desktop on Azure services, corporations and departments are able to reduce the number of virtual machines and OS overhead while providing the same resources to users.

AVD provides the following benefits over a traditional Desktop-as-a-Service platform:

  • Deliver fully feature-rich and scalable AVDs with Azure Windows 10 multi-session OS.
  • Deliver a virtualised and optimised Office 365 experience.
  • Bring Your Own Device (BYOD) options to allow for ease of transition.
  • An easy path to modernisation and reduction in data centre expenditure.
  • Provide extended support for legacy desktop operating systems or hosting of legacy applications.

The following sections of this document outline design defaults and guidance when deploying an AVD platform and is to be treated as an addendum to the client devices design.

Typical AVD Architecture

This diagram shows a typical architectural overview for AVD.

  • The user endpoints reside either within an agency’s on-premises network (hybrid) or on the public internet (cloud native). For hybrid deployments, ExpressRoute or a site-to-site VPN extends the on-premises network into Azure. Azure AD Connect integrates the agency’s hybrid identity (Active Directory Domain Services (AD DS)) with Azure Active Directory (Azure AD). Cloud native deployments that do not have a hybrid identity (AD DS) can leverage cloud-native Azure AD Domain Services.
  • The AVD control plane handles Web Access, Gateway, Broker, Diagnostics, and extensibility components like REST APIs.
  • The agency manages AD DS and Azure AD, Azure subscriptions, virtual networks, Azure Storage, and the AVD host pools and workspaces.
  • The agency uses multiple Azure subscriptions in an enterprise-scale landing zone architecture as per Microsoft’s Cloud Adoption Framework for Azure.

Assumptions

The following represent the assumptions when considering to deploy Azure Virtual Desktop.

  • The agency already has a suitable Azure deployment or is planning an Azure deployment within the Australian Azure regions, with appropriate controls implemented up to Protected.
  • Licensing is available for Windows 10 Enterprise multi-session, Windows 10 Enterprise and FSLogix.
    • Microsoft 365 E3, E5
    • Windows E3, E5
  • Adequate storage is provisioned for the expected number of users. Recommendation of a minimum of 30GB per-user for the Windows profile hosted with the FSLogix solution.
  • The agency has read the client devices blueprint and ensures the ACSC Windows 10 hardening guidelines are being adhered to in relation to the AVD Windows 10 session hosts.

Prerequisites

The following represent the prerequisites before deploying Azure Virtual Desktop.

  • Infrastructure with a configured Azure AD tenant and an Active Directory Domain Services (AD DS) that can sync with Azure AD. Currently, AVD requires session host virtual machines to be domain-joined to an AD DS domain to manage the machines computer object and provide policy and authentication. Depending on the Active Directory architecture chosen – hybrid or cloud native, AVD can be configured to domain-join an existing on-premises AD DS domain (over VPN or ExpressRoute), or a cloud-only Azure AD Domain Services (PaaS) hosted in Azure.

Cloud native:

  • Azure AD Connect synced to a cloud-only AD DS IaaS (Infrastructure as a Service) within the Azure deployment, or
  • Azure AD DS PaaS configured within the Azure deployment (automatically synchronised to Azure AD)

Hybrid:

  • Azure AD Connect connected to AD DS (on-premises or hosted in Azure)
  • An Azure subscription that contains a virtual network that can connect to the AD DS domain.

Platform components

Active Directory

Microsoft Windows Server Active Directory Domain Services (AD DS) and Azure Active Directory (AAD) maintain records of information required to identify services, users and other resources on the network. A domain is a security boundary that exists within AD, and all user accounts are based on domain membership.

Currently, AVD requires session host virtual machines to be domain-joined to an AD DS domain to manage the machines computer object and provide policy and authentication. Depending on the Active Directory architecture chosen – hybrid or cloud native, AVD can be configured to domain-join an existing on-premises AD DS domain (over VPN or ExpressRoute), or a cloud-only Azure AD Domain Services (PaaS) hosted in Azure.

The following table outlines the environment specific infrastructure configurations and considerations for Active Directory services for the solution.

Active Directory Design Decisions for the solution

Decision Point Design Decision Justification
Active Directory Domain Type Hybrid: AD Connect synced to AD DS domain

Cloud Native: AD Connect synced to cloud-only AD DS IaaS hosted on Azure OR Azure AD DS PaaS configured on the Azure Platform (automatically synced to Azure AD)
AVD requires session host virtual machines to be joined to an AD DS domain.

This is to support AVD domain join and to manage the machines computer object and provide policy and authentication. Depending on the Active Directory architecture – hybrid or cloud native AVD can be configured to sync with an existing on-premises AD DS domain, or a cloud-only AD DS IaaS or Azure AD DS PaaS service hosted in Azure.

Currently, Virtual machines cannot be natively Azure AD-joined only.
Active Directory Domain [Domain Name] A new or current AD DS domain will be leveraged for the AVD solution.
Active Directory Domain Functional Level (Hybrid Only) Windows Server 2016 functional level Latest support AD Functional level and supported by the AVD service.
Single Sign On Optional – AD FS is required and supported with Web Client and Windows Client only. Active Directory Federation Services (AD FS) is required to support Single Sign On (SSO) from the RD Gateway logon point through to the AVD desktop.
AD Organisation Units OU=[Agency] Workstations,OU=Windows 10 Virtual,DC=[Domain], DC=GOV, DC=AU AVD session host computer accounts will reside within a dedicated Windows 10 virtual desktop OU.
DNS Type Hybrid: AD DS integrated DNS infrastructure

Cloud Native: AD DS / AAD DS integrated DNS infrastructure
The agency will utilise AD DS integrated DNS infrastructure for name resolution. Communication for hybrid will occur inside the Azure VPN. Communication for Cloud native will be configured within Azure subnets.
NTLM Requirements (Hybrid Only) Add AVD hostnames to security groups For hybrid environment, the AVD session host names will be added to group policy which is applied to the domain controllers:

* Network security: Restrict NTLM: Add remote server exceptions for NTLM authentication: <avd hostnames>
* Network security: Restrict NTLM: Add server exceptions in this domain: <avd hostnames>

The following figure outlines a suggested AD DS OU Structure with proposed OUs to accommodate the Virtual Desktop and hybrid joined devices.

Suggested AD DS OU Structure

Group policies

Group policies provide a user experience tailored to the needs and security requirements of an organisation. Policies are created and managed using the Group Policy Management Console (GPMC). Group policy is still required for session hosts when using pooled-random session hosts, which is currently not supported with Intune.

The following tables describe the Group Policy design decisions for the solution.

Decision Point Design Decision Justification
Group Policy template versions (ADMX) Windows: Windows 10 Enterprise (1909 / 20H2 / 21H1)
Microsoft Office: Microsoft 365 Apps for enterprise / Office 2016 / 2019 / June 2020

Design Decisions for OS and Office versions, refer to client devices design.
ADMXs required to support the current SAC release of Windows 10, Microsoft 365 and Microsoft Defender for Endpoint.
Group Policy Inheritance Enabled The session host desktop policies will be linked to a new OU structure. No existing policies will be used.
Group Policy Loopback Mode Replace Mode Loopback processing in Replace Mode will be configured to allow finer grained user policies to be linked at the computers OU level.
ACSC Hardening Guidelines – Hardening Windows 10, Microsoft Office Macro Security and MS Office. Deployed Ensures the ACSC Windows 10 and Office Macro Security hardening recommendations have been assessed and appropriately applied to devices via custom group policies.

The Client Devices Design Blueprint advice will be followed to harden the AVD VM’s except where it does not apply (I.e., Any recommendations that only apply to physical desktop machines and not VM’s). For example, the following outlined hardening recommendations from the guide will not be applied:

* Early Launch Antimalware
* Measured Boot
* Secure Boot
* BIOS and UEFI passwords
* Boot devices
* CD burner access

Exact configurations per the ACSC guidelines will be included in the ‘As-Built As-Configured’ documentation.
ACSC Group Policy – Override As required A set of custom group policy settings to override the ACSC group policies can be applied as needed to meet the agencies requirements (i.e., legacy applications configurations, custom organisational settings, etc).
Group Policies Configuration To be outlined in As Built Configuration As required to allow system to function correctly and as per the agencies requirements.

Personalisation and profile management

User profiles and personalisation enable users to configure an application or desktop setting and have that setting retained the next time they login or roam to another computer. This is extremely important when using a virtual desktop, as the local Windows profile is generally always not present for each new virtual desktop login, this can impede the user performance as it can increase user login times and cause issues with applications missing configuration on virtual desktop sessions.

Each user group, regardless of the required level of personalisation, should have a profile that determines how the user’s settings will or will not persist across sessions. Part of the profile configuration includes folder redirection to better optimise the profile.

Microsoft includes several standard options for user profiles, or personalisation. Alternatively, technologies such as Microsoft UE-V and FSLogix, can be used to address user profile and personalisation requirements. If no user profile is configured, a desktop local profile is used, which is seldom optimal.

Microsoft provide the following profile management solutions:

  • Local Profiles – Are created and stored on each workstation the user logs on to.
  • Mandatory Profiles – A profile that does not save profile changes.
  • Roaming Profiles – A network-based profile that allows user settings to be saved.
  • Microsoft UE-V – Provides personalisation that operates at the application layer delivering a user’s personal Windows experience across many devices, regardless of Windows or the applications are deployed physically or virtually. UE-V templates are created to specify which application settings and files are captured and roamed between sessions.
  • FSLogix – Provides a full profile solution in addition to addressing issues when deploying Office 365 in a non-persistent VDI/RDS environment. Using the Profile Container and/or Office 365 Container data is cached locally helping avoid disruptions or application instability during brief storage interruptions like network switch resets or storage controller failovers. This cache sits between the user’s desktop and the remote container storage and is configured either to persist between logons or start fresh each time the user logs in.
  • Folder Redirection – Enables certain folders, such as Documents and AppData, to be redirected. This enables user data such as documents and email configuration, to not be loaded at login, which can improve performance when loading profiles. However, some applications communicate with the AppData frequently, making the application appear slow when this folder is redirected.

The following table describes the Profile Management design decisions for the solution.

Decision Point Design Decision Justification
Personalisation and Profile Management FSLogix FSLogix provides the best performance for AVD and supports file shares within Azure.
FSLogix License Entitlement Microsoft 365 E3/E5
Windows 10 Enterprise E3/E5
Remote Desktop Services (RDS) Client Access License (CAL)
Remote Desktop Services (RDS) Subscriber Access License (SAL)
Any of these licensing entitlements will provide access to FSLogix Profile Container, Office 365 Container, Application Masking, and Java Redirection tools.
Folder Redirection Not required OneDrive redirection of known folders will be used in preference to Folder Redirection
Profile Management Configuration Refer to Personalisation and Profile Management Configuration and FSLogix Office 365 Container Configuration tables below  

The following table describes Personalisation and Profile Management design decisions for the solution. These settings will be configured via ADMX Group Policy.

Decision Point Design Decision Justification
Profile Management Version FSLogix Apps 2.9.7654.46150 The latest version at the time of writing. The latest version should be assessed and utilised where appropriate.
Profile Container Enabled FSLogix will be used to manage profiles for the solution.
Profile Container Logging Enabled (All logs enabled) Logging is to be enabled for FSLogix.
Profile Type Read write with fallback to read only Required for multi-session concurrent deployment type.
Enable Search Roaming Enabled: Multi-User Search Required to support Office 365 Search Database roaming.
Search Database Configuration Multi-User Search Required to support Office 365 Search Database roaming.
Outlook Cached Mode Enabled FSLogix Outlook Cached mode will be configured to provide the best user experience.
Dynamic VHD(X) Allocation Enabled Dynamic VHD(X) will be configured to provide storage cost savings where possible.
Profile Virtual Disk Location Agency Decision Point: Azure Files or Azure NetApp Files for Storage Account.

Storage Account Name/s: TBD - Share that will be used for profiles
Each user will have a FSLogix virtual disk stored to an Azure location in Australia with data geo-replicated to a secondary location for DR purposes.

Depending on required usage, performance and disaster recovery requirements, the agency must decide between Azure Files and Azure NetApp files depending on their requirements.

For further information, see Azure Files and Azure NetApp Files comparison.
Virtual Disk Type VHDX VHDX is the latest available disk type and suitable for this solution.
Concurrent Users Sessions Allowed Concurrent user sessions must be enabled to allow Citrix hosted shared desktop scenarios.
Local Cache Persistence Enabled Local cache folders will be kept on user logout providing a faster experience for re-logons.
Redirections File Path Azure Storage account The redirections configuration XML will be hosted on a common share, to be determined by the agency.
Redirection Exclusions [TBD-DOMAIN]\NETLOGON\FsLogix\Redirections.xml

See section Appendix 1 – FSLogix Profile Redirections
Base configurations recommended initially. This configuration will be updated as required during the build and test of the solution.
Directory Naming Configuration Swapped: Username_SIDs This configuration allows for easier navigation of the user VHDX when troubleshooting and during maintenance.

The following table includes FSLogix Office 365 Container Configuration.

Decision Point Design Decision Justification
O365 Virtual Disk Location Network Share: [TBD - Network Share to be used for Virtual Disks] Each user will have a FSLogix virtual disk stored to an Azure location in Australia with data geo-replicated to a secondary location for DR purposes.
Virtual Disk Access Unique disk per session Required for this deployment type.
Virtual Disk Type VHDX VHDX is the latest available disk type and suitable for this solution.
O365 Container Logging Enabled Logging is to be enabled for FSLogix.
Concurrent Users Sessions Allowed Concurrent user sessions must be enabled to allow hosted shared desktop scenarios.
Office 365 Activation Data Enabled Office 365 activation data will be stored in the O365 container.
Office Cache Data Enabled Office 365 cache data will be stored in the O365 container.
OneDrive Data Enabled OneDrive data will be stored in the O365 container.
OneNote Data Enabled OneNote data will be stored in the O365 container.
Outlook Data Enabled Outlook data will be stored in the O365 container.  
Outlook Personalisation Data Enabled Outlook personalisation data will be stored in the O365 container.
SharePoint Data Enabled SharePoint data will be stored in the O365 container.
Teams Data Enabled Teams data will be stored in the O365 container.
Outlook Folder Path Configured %userprofile%\AppData\Local\Microsoft\Outlook
Outlook Container Mode Cached Outlook cached mode will be enabled on successfully container attach.
Dynamic VHD(x) Enabled Dynamic VHD(x) will be utilised to save on required space. Disks will grow only as space is required.
Search Roaming Enabled Search roaming will be enabled to support the solution and provide a consistent user experience.
Search Database Stored in O365 Container The Search Database will be stored in the O365 container.
Sync OST to VHD Enabled: Move OST to VHD OST’s will be stored in the O365 container.
Clear Cloud Cache on Logoff Enabled Users locally stored Cloud Cache will be persisted on logoff.
Directory Naming Configuration Swapped: Username_SID This configuration allows for easier navigation of the user VHDX when troubleshooting and during maintenance.

Resource tags

Resource Tags can be applied to objects within Azure to organise them into categories. Using Tags, resources can be retrieved from multiple Resource Groups. Tags enable simplified management and Azure billing capability.

A Resource Tag is comprised of a Key and a Value. Both are defined by an administrator.

The following tables describe the Azure Resource Tags design decisions for the solution.

Decision Point Design Decision Justification
Tags Configured Tagging of resources provides a consistent way to view subscription costs by type.
Tags Configured Tags configured for:

Category
Environment Type
Description
Owner
Resource tags will be configured for each host pool to provide details for category, environment type, description, and owner.

Azure Virtual Desktop components

Control plane

Azure AVD is a PaaS offering managed by Microsoft that allows administrators to configure, deploy, and manage, scalable flexible solutions. AVD enables administrators to publish either full desktops or distinct remote apps from a single host pool or create individual app groupings for different sets of users.

Using the Windows 10 Enterprise multi-session capability exclusively available to Azure Virtual Desktop on Azure services, corporations and departments are able to reduce the number of virtual machines and OS overhead while providing the same resources to users.

The table below describes the AVD Control Plane design decisions for the solution.

Decision Point Design Decision Justification
AVD Control Plane West US Metadata will be stored in Azure geography associated with West US.

AVD Control Planes are not currently available in Australia, and therefore a US region has been selected.

Note: This is not the location where virtual desktops are hosted, this will be within the Azure spoke in the Australia Central regions.

The stored information is encrypted at rest, and geo-redundant mirrors are maintained within the geography. Customer data, such as app settings and user data, resides in the location the customer chooses and isn’t managed by the service. For further information, see Data locations for Azure Virtual Desktop - Azure Microsoft Docs.
Azure License Entitlement Microsoft 365 E3/E5
Windows 10 Enterprise E3/E5
Any of these licensing entitlements will provide access to AVD.

Note: AVD can be accessed from non-Windows Pro endpoints if a Microsoft 365 E3/E5 or Windows 10 VDA per user license is available.
Windows 10 Enterprise and Windows 10 Enterprise Multi Session License Entitlements Microsoft 365 E3/E5
Windows E3/E5
Any of these licensing entitlements will provide access to Windows 10 and Windows 10 Multisession on Azure.
Encryption TLS 1.2 TLS 1.2 is used for all connections initiated from the clients and session hosts to the Azure Virtual Desktop infrastructure components.
Identity and Access Configuration Refer to AVD Control Plane Configuration table To meet the requirements of this design
Connectivity Optimised through SIG public internet AVD does not currently support ExpressRoute optimisation, it is recommended that outgoing connections from within the agency to AVD desktops are optimised by bypassing the agency web proxy, but still egressing the agency’s SIG (direct route). Connections outside of the environment will connect using the public internet.

Note: at time of writing, Azure RDP Shortpath is a preview feature which supports direct connection to session hosts in with hybrid connectivity configurations.

AVD Control Plane Configuration table:

Decision Point Design Decision Justification
Administrator Access Azure Active Directory This provides native AD auditing, password policies and account control.
User Access Azure hosted Web URL Users will access the solution via the Microsoft hosted Remote Desktop Web URL: https://rdweb.wvd.microsoft.com/arm/webclient/

Host pool

A host pool is a collection of Azure virtual machines that register to AVD as session hosts. All session host virtual machines in a host pool are sourced from the same image providing a consistent user experience.

A host pool can be one of two types:

  • Personal – Where each session host is assigned to individual users.
  • Pooled – Where session hosts can accept connections from any user in an authorised app group within the host pool.

Host Pool configuration allows the setting of properties to change load-balancing behaviour, how many sessions each session host can take, and what a user can do to session hosts in the host pool while signed into an AVD session.

Azure Virtual Desktop supports two load-balancing methods. Each method determines which session host will host a user’s session when connected to a resource in a host pool.

The following load-balancing methods are available:

  • Breadth-first – Allows user sessions to be distributed evenly across the session hosts in a host pool.
  • Depth-first – Allows user sessions to completely fill a session host in the host pool. Once the first session 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.

The table below describes the Host Pool design decisions for the solution.

Decision Point Design Decision Justification
Metadata West US Metadata will be stored in Azure geography associated with (US) West US. For further information, see Control plane section.
Host Pool Types Pooled Pooled is the preferred selection to ensure consistency.
Load Balancing Method Breadth-First User sessions to be distributed evenly across the session hosts in a host pool.
Number of Host Pools Dependant on User Personas The number of host pools will be aligned to the number and size of the user personas, and the VM-types assigned.
Host Pool Configuration Refer to Host Pool Configuration table To meet the requirements of this design.

Host Pool Configuration table:

Decision Point Design Decision Justification
Host Pool Name <agn>-<hp>-<os>-<pooltype> Host Pool naming will be configured as follows:

<agn> = Agency Name
<hp> = Host Pool
<os> = Windows Version
<pooltype> = Pool Name

e.g. agency-hp-win10-fin
Friendly Name Aligned to Host Pool name Descriptive text that aligns to the host pool name.

e.g. Agency Windows 10
Access Aligned to user groups The AVD Session Hosts will accept any user connection with access to the host pool.
Azure Resource Group <rg>-<agn>-<avd> Host Pool naming will be configured as follows:

<rg> = Resource Group
<agn> = Agency Name
<avd> = Azure Virtual Desktop
App Groups <agn>-<hp>-<os>-<pooltype>-<appgroup> Host Pool naming will be configured as follows:

<agn> = Agency Name
<hp> = Host Pool
<os> = Windows Version
<pooltype> = Pool Name
<appgroup> = Application Group

e.g. agency-hp-win10-fin-accapps
Max Session Limit Dependant on user-types To ensure no more than a defined number of users can connect to a single Windows 10 session. Can restrict number of users to a maximum limit per session host. For best performance and density estimates, see section Session Host Sizing in the next section for further information.
Session Host Members View Client Devices guidelines As per the Client device’s blueprint guidelines.
Validation Environment Enabled Allows to monitor service updates before rolling them out to the Production host pool.
Assignment Method Automatic Users will be automatically assigned to a session host.
RDP Properties The following to be configured via ADMX Group Policies:

Multi-monitor mode: Enabled
Drive redirections: Disabled
Remote audio mode: Play Locally
RDP Properties Configuration: audiocapturemode:i:1;drivestoredirect:s:;redirectcomports:i:0;camerastoredirect:s:*;devicestoredirect:s:*;redirectclipboard:i:0;redirectprinters:i:0;redirectsmartcards:i:0
To restrict data leaving the environment and to optimise performance and workability.

Session host

Each user group will utilise a desktop (Session Host) or RemoteApp based on an underlying image. Most organisations try to consolidate images into as few as possible while still providing a desktop environment that is not bloated with applications most users do not use.

Users are provided access to RemoteApps or desktops based on group memberships permissions and business function.

The Azure VM generation (version) can limit what operating system features are available such as UEFI (Unified Extensible Firmware Interface) support. Generation 2 is now available within Australian regions and should be used for Azure Virtual Desktops. Note the following Windows 10 features are not yet supported as it requires Trusted Launch to be available in Australian Azure regions:

  • Secure boot
  • vTPM
  • Virtualization-based security (VBS).

An AVD session host consists of the following core components:

  • Operating System – The correct OS is critical to the success of a hosted desktop environment. It forms the foundation of the SOE and provides the launchpad for the applications deployed to it.
  • Applications – The applications deployed to an AVD image and how each are deployed will affect the end user experience. Choosing the right applications and their configuration is critical to solution success. Applications are able to be delivered to an AVD image in the following ways:
    • Installed – The application is part of the base desktop image. Every user receiving the image also receives the application. Typically, common applications are installed into the base image. FSLogix application masking can be utilised to prevent the user from seeing a particular application within the image, allowing the administrator to maintain a small number of session pools
    • App-V – The application is delivered via the network, to the desktop just-in-time or pre-cached. The application is not traditionally installed within the OS, though executes within a temporary runtime environment. Applications are only visible to users who are granted access or are published globally
    • RemoteApp – The application is hosted on a set of session host servers. Technically challenging applications are often delivered via the RemoteApp model
    • MSIX App Attach – The application is delivered via the network, to the desktop. App Attach enables packaged applications to be stored outside the AVD sessions hosts to be maintained and updated separately to the image. This reduces the need to maintain multiple master images for different applications and/or the ability to package all virtualised apps into a single image.

The table below describes the Session Host design decisions for the solution.

Decision Point Design Decision Justification
Azure Region Any Azure Australian region In-line with government requirements and existing Azure Tenant / Subscription regions for this blueprint.
Number of Session Hosts Dependant on user persona types and the size of the group. General guidance for Light, Medium, Heavy and Power user configuration is provided below.

See Session Host Sizing table.

For further information, see virtual machine sizing.
Number of Images One per User Persona type It is recommended that one image will be deployed per User Persona type to allow easier image management.
Operating System Windows 10 Enterprise Multi-Session, with Microsoft 365 Apps from the Azure Marketplace Latest stable version of Windows 10 available from the Azure Marketplace.
Supported Language Packs EN-AU The default language is English.
Time Zone Australian Eastern Standard Time (AEST) The default time zone AEST.
Image Source Azure Marketplace The Windows 10 Enterprise Multi-Session with Microsoft 365 Apps SOE available from the Azure Marketplace will be utilised for the AVD image deployment.
Image Deployment Method Azure Resource Manager AVD using Azure Resource Manager will be used to deploy pooled random virtual machines.
Deployed Image Update Process Azure Resource Manager (ARM) Redeploy and auto updates ARM Redeploy capability with auto updates will be leveraged to provide ‘Security and Feature’ updates to the AVD images.
Encryption Azure Disk Encryption Session host disks to be encrypted at rest using Azure Disk encryption. Using the Bitlocker feature of Windows, volume encryption for the OS and data disks of Azure virtual machines (VMs) will be configured. Will also be integrated with Azure Key Vault to help control and manage disk encryption keys and secrets.
Graphical Application Support GPU Capable VMs available in selected Australian Regions Windows 10 VMs with higher GPU capability are available from Azure if there is a need to run graphical applications.
Session Host Power Management Azure Automation Azure Automation will be utilised to scale session host power management. This will enable shutting down and deallocating session host VMs during off-peak usage hours, and powering on and reallocating as required (during peak hours).
Session Host Configuration Refer to Session Host Configuration table Session Host configuration.
Deployed Applications Agency defined Applications to be deployed post platform deployment.
OS Optimisations Virtual Desktop Optimization Tool Microsoft recommend some optimisation to the OS image to increase performance and scalability and enhance the overall end user experience.
Antivirus Microsoft Defender of Endpoint Microsoft Defender for Endpoint will be configured for the AVD platform.

For configuration items that apply specifically to an AVD environment, such as a dedicated VDI file share and specific exclusions, refer to Deployment guide for Microsoft Defender Antivirus in a virtual desktop infrastructure (VDI) environment and for common client device configuration settings, refer to client devices design.

Session Host Sizing table:

Workload type Maximum users per vCPU vCPU/RAM/OS storage minimum Example Azure instances Profile container storage minimum
Light 6 8 vCPUs, 16 GB RAM, 16 GB storage D8s_v4, F8s_v2, D8as_v4, D16s_v4, F16s_v2, D16as_v4 30 GB
Medium 4 8 vCPUs, 16 GB RAM, 32 GB storage D8s_v4, F8s_v2, D8as_v4, D16s_v4, F16s_v2, D16as_v4 30 GB
Heavy 2 8 vCPUs, 16 GB RAM, 32 GB storage D8s_v4, F8s_v2, D8as_v4, D16s_v4, F16s_v2, D16as_v4 30 GB
Power 1 8 vCPUs, 16 GB RAM, 340 GB storage D8s_v4, F8s_v2, D8as_v4, D16s_v4, F16s_v2, D16as_v4, NV12, NVv4 30 GB

Session Host Configuration table:

Decision Point Design Decision Justification
VM Size Dependant on user persona type selected Dependant on user persona type selected.
Azure VM Generation Generation 2 Generation 2 should be selected to support security features such as UEFI
Trusted Launch Not configured At time of writing, the trusted launch feature is in Public preview and restricted to regions outside of Australia.
Name Prefix <agn><os><shg><nnn> To meet the requirements of this design. App Group naming will be configured as follows:

<agn> = Agency Name
<os> = Windows Version
<shg> = Session Host Group
<nnn> = Numerical Iteration

e.g. agnwin10acc001
Domain [Agency Domain] As per agencies domain name.
AAD DS / AD DS Domain Join Account svc_domjoin@[Agency Domain] Service account in the agencies domain.
Domain Joined type Hybrid-Joined (depending on Agency Active Directory selection) AVD Session-hosts will be managed through AAD DS / AD DS.
Organisational Unit OU=[Agency] Workstations,OU=Windows 10 Virtual,DC=[Domain], DC=GOV, DC=AU The guidance is to deploy the session hosts to a dedicated organisation unit for the session hosts. The agency can determine where that location best fits with the deployment.
IP Subnet Customer design decision based on networking standards Adequately sized and number of subnets to be configured as required to host the number of session hosts.
Network Security Group <agn>-<env>-<loc>-<vnet>-<host>-<nsg> Azure Virtual Desktop Subnet Network Security Gateway (NSG) with a default deny rule for all traffic, which can be modified as required for specific workloads. Naming convention as follows:

<agn> = Agency
<env> = Environment (e.g. Prod)
<loc> = Location (e.g. auc1)
<vnet> = Virtual Network
<host> = Workloads the vnet is hosting (I.e. Desktops)
<nsg> = Network Security Group
Public Inbound Ports Disabled A default deny rule for all traffic, which can be modified as required for specific workloads. AVD control plane traffic will ingress regardless of the NSG configuration.
Minimum Outbound Ports Allowed 135/TCP (RPC Endpoint Mapper)
1024-65535/TCP (RPC)
636/TCP (LDAP SSL)
3268/TCP (LDAP GC)
3269/TCP (LDAP GC SSL)
53/TCP/UDP (DNS)
88/TCP/UDP (Kerberos)
445/TCP (SMB)
1688/TCP (KMS)
80 & 443 TCP (internet)
To meet the minimum requirements of this blueprint for the Virtual Desktop to communicate with Active Directory. Agency to assess additional egress ports based on requirements. More information around network port requirements are outlined in the Access and connectivity section.

Note 1: AVD control plane outbound ports are not explicitly configured on the NSG and are controlled per URL on the Azure Firewall egress point.

Note 2: An internet filtering solution for user traffic is in place outside of the Azure Firewall.
Associated Host Pool Aligned to Host Pools required Session Hosts will align to the host pools created.
Built-In Applications As required Enterprise applications installed in the image as required.

App groups

App groups are logical grouping of applications installed on session hosts in the host pool. An app group can be one of two types:

  • RemoteApp - Enables a user to access the RemoteApps individually selected and published to the app group. Multiple RemoteApp app groups can be created to accommodate different worker scenarios. Distinct RemoteApp app groups can also contain overlapping RemoteApps.
  • Desktop – Allows a user to access the full desktop session host. By default, a desktop app group (named “Desktop Application Group”) is automatically created whenever a host pool is deployed.

To access published resources, users must be assigned to an app group. When assigning users to app groups, consider the following things:

  • A user can be assigned to both a desktop app group and a RemoteApp app group in the same host pool. However, users can only launch one type of app group per session.
  • A user can be assigned to multiple app groups within the same host pool allowing the app feed to be an accumulation of both app groups.

The table below describes the App Group design decisions for the solution.

Decision Point Design Decision Justification
Azure Region West US Metadata will be stored in Azure geography associated with (US) West US. For further information, see Control plane section.
Number of App Groups Aligned to unique images required App groups will be created as per unique images required.
App Group Type Desktop (one per host pool)
RemoteApp (multiple as required per host pool)
Desktop provides the full desktop experience, only one created per host pool. RemoteApp provides published apps, multiple can be created per host pool.
App Group Configuration Refer to App Group Configuration table To meet the requirements of this design.

App Group Configuration table:

Decision Point Design Decision Justification
App Group Name <agn>-<hp>-<os>-<loc>-<agn> To meet the requirements of this design. App Group naming will be configured as follows:

<agn> = Agency Name
<hp> = Host Pool
<os> = Windows Version
<loc> = Location
<agn> = App Group Name

e.g. agency-hp-win10-auc-dag
Friendly Name Aligned to App Group Name Descriptive text that aligns to the host pool name.

e.g. Agency Windows 10 Desktop App Group
Azure Resource Group <rg>-<agn>-<avd> Host Pool naming will be configured as follows:

<rg> = Resource Group
<agn> = Agency Name
<avd> = Azure Virtual Desktop
App Group Type Desktop / RemoteApp Desktop or RemoteApp selected depending on the requirement of a full desktop experience or applications only.
Description Aligned to App Group Name Descriptive text that aligns to the app group name.
Assignments Aligned to User Persona User assignment will be aligned to groupings aligned to the persona image type required.
Published Applications As required List published applications required to be launch separately from the desktop.
Host Pool Aligned to the host pool Each App Group will be aligned to a host pool.
Workspace Aligned to the host pool Each Workspace will be aligned to a host pool.

Workspaces

Workspaces are logical grouping of App Groups in Azure Virtual Desktop. Each AVD App Group must be associated with a Workspace for users to see the remote apps and desktops published to them.

The table below describes the Workspace design decisions for the solution.

Decision Point Design Decision Justification
Number of Workspaces Aligned to logical grouping of App Groups Workspaces will be created for each logical grouping of App Groups.
Workspace Name I.e. ‘Accounting Workspace’ The workspace name will be descriptive for the App Group collection.
Workspace Configuration Refer to Workspace Configuration table Refer to Workspace Configuration table.

Workspace Configuration table:

Decision Point Design Decision Justification
Workspace Name I.e. ‘Accounting Workspace’ The workspace name will be descriptive for the App Group collection.
Friendly Name Aligned to Workspace Name Descriptive text that aligns to the Workspace name.

e.g. Agency Windows 10 Desktop Workspace
Azure Resource Group <rg>-<agn>-<avd> Host Pool naming will be configured as follows:

<rg> = Resource Group
<agn> = Agency Name
<avd> = Azure Virtual Desktop
Description Aligned to Workspace Name Descriptive text that aligns to the workspace name.
Host Pool Aligned to Host Pool Each Workspace will be aligned to a host pool.
App Groups List of App Groups List of App Groups that will form this Workspace.

Session and idle timeouts

Session and Idle timeouts can be configured to assist with security and resource availability. The following types of session timeouts can be configured:

  • Disconnected Session Timeout – Defines the period that a disconnected session remains disconnected before automatically being logged off.
  • Idle Session Timeout – Defines the number of minutes that a continuously idle session remains active before being disconnected.

The table below describes the key Session and Idle Timeout design decisions for the solution.

Decision Point Design Decision Justification
Disconnected Session Timeout 8 hours To let users reconnect to their session during a standard workday.
Idle Session Timeout 15 minutes Short idle timeout (or Machine inactivity limit) to ensure unattended virtual desktops are disconnected. This is defined as per ACSC Windows 10 Hardening guide.

Access and connectivity

Gateway firewall

AVD utilises a number of URLs for its associated services. It is important that firewall rules are configured to enable access to these services to ensure communication flow and that these communication paths are optimised, ideally outside of the chosen Edge Firewall within Azure.

The blocking of these URLs is unsupported and will affect service functionality. These URLs only correspond to Azure Virtual Desktop sites and resources, and do not include URLs for other services like Azure Active Directory.

The table below describes the key Gateway Firewall design decisions for the solution.

Decision Point Design Decision Justification
Gateway Firewall Azure Firewall Azure Firewall is the recommended firewall solution and does not require a third-party solution.
  • Required Session Host Allow List
    • These URLs are required to provide minimum AVD functionality.
    • Note: AVD currently does not have a list of IP address ranges that can be unblocked to allow network traffic. Only the support of unblocking specific URLs is supported at this time.
    • If using a Next Generation Firewall (NGFW), you will need to use a dynamic list specifically made for Azure IPs to make sure you can connect.
      *.wvd.microsoft.com 443
      gcs.prod.monitoring.core.windows.net 443
      production.diagnostics.monitoring.core.windows.net 443
      *xt.blob.core.windows.net 443
      *eh.servicebus.windows.net 443
      *xt.table.core.windows.net 443
      *xt.queue.core.windows.net 443
      catalogartifact.azureedge.net 443
      kms.core.windows.net 1688
      mrsglobalsteus2prod.blob.core.windows.net 443
      wvdportalstorageblob.blob.core.windows.net 443
      169.254.169.254 80 (Azure Instance Metadata service endpoint)
      168.63.129.16 80 (Session host health monitoring)  
      
  • Recommended Session Host Allow List
    • These URLs are recommended to provide best user experience and functionality.
      *.microsoftonline.com 443
      *.events.data.microsoft.com 443
      www.msftconnecttest.com 443
      *.prod.do.dsp.mp.microsoft.com 443
      login.windows.net 443
      *.sfx.ms 443
      *.digicert.com 443
      *.azure-dns.com 443
      *.azure-dns.net 443
      
  • Required Remote Desktop Client Allow List
    • These URLs are required to provide minimum Remote Desktop client functionality.
      *.wvd.microsoft.com 443
      *.servicebus.windows.net 443
      go.microsoft.com 443
      aka.ms 443
      docs.microsoft.com 443
      privacy.microsoft.com 443
      query.prod.cms.rt.microsoft.com 443
      

Client access

The following client access methods are available to clients:

  • Windows Remote Desktop Client – Installed on user devices and provides users with secure, self-service access to company resources including, applications, and desktops from any of the user’s Windows devices.
  • Web Client (HTML5) – Allows access to Azure Virtual Desktop resources from any HTML5 compatible web browser, without the lengthy installation process on the Windows Desktop client.
  • Android Remote Desktop Client – Allows users to access Azure Virtual Desktop resources directly from an Android device or a Chromebook that supports the Google Play Store.
  • MacOS Remote Desktop Client –Allows users to access Azure Virtual Desktop resources from an Apple computer.
  • iOS Remote Desktop Client – Allows users to access Azure Virtual Desktop resources directly from an iOS device (iPhones and iPads).
  • RDP Shortpath – Is an Azure Virtual Desktop optimisation feature that allows the client device to establish a direct UDP-based connection between the Remote Desktop Client and the Session host. The feature requires that the client has routing capability into the Azure VNet where the Session hosts reside.

The table below describes the Client Access design decisions for the solution.

Decision Point Design Decision Justification
Primary Client Access Web Client (HTML5)
Windows Desktop Client
User will primarily access AVD resources using the Web Client (HTML5) and the Windows Desktop Client.
Browser Support Microsoft Edge
Apple Safari
Mozilla Firefox
Google Chrome
All current browsers advised by Microsoft which have HTML5 compatibility will be supported.
Conditional Access App Exclusions Exclude from blocking policies:
Windows Virtual Desktop
Windows Virtual Desktop Client
Include in MFA grant policy:
Windows Virtual Desktop
Windows Virtual Desktop Client
Exclusion of any “All Cloud Apps” policies that prevent the use of Azure Virtual Desktop should be implemented to allow connectivity from non-agency endpoints.
Conditional Access Session Control Set to 14 hours (when KMSI enabled) Session Control policy should be implemented to enforce MFA after long periods when KMSI (Keep me Signed In) is implemented.
RDP Shortpath Not configured At time of writing, this feature is in Public Preview.

Users and devices

User personas

Personas identify the user types, their requirements and represent the typical user-type for the solution.

In order to identify how many distinct personas will be required to support all of the users, the following criteria will need to be considered.

  • Personal pools - Do specific groups of users require dedicated virtual desktops, instead of pools? For example, security, compliance, high-performance, or noisy-neighbour requirements might lead to some users running on dedicated desktops that aren’t part of a pooling strategy. You’ll enter this information by specifying a host pool type of personal during the Azure Virtual Desktop host pool deployment.
  • Density - Do specific groups of users require a lower-density desktop experience? For example, heavier density might require two users per virtual central processing unit (vCPU) instead of the light-user assumption of six users per vCPU. You’ll enter density information in the pool settings of the Azure Virtual Desktop host pool deployment.
  • Performance - Do specific groups of users require a higher-performance desktop experience? For example, some users require more memory per vCPU than the assumed 4 gigabytes (GB) of RAM per vCPU. You’ll enter the VM sizing in the virtual machine details of the Azure Virtual Desktop host pool deployment.
  • Graphical processing (GPU) - Do specific groups of users have greater graphical requirements? For example, some users require GPU-based VMs in Azure, as demonstrated in the Configure GPU for Azure Virtual Desktop - Azure guide for configuring GPU VMs.
  • Azure region: Do specific groups of OS users operate from various geographic regions? . For example, before you configure the host pool, a user from each region should test latency to Azure by using Azure Virtual Desktop Experience Estimator tool. The test user should share the lowest-latency Azure region and the latency in milliseconds for the top three Azure regions.
  • Business functions - Can the specific groupings of users be bucketed by business unit, charge code, or their business function? This type of grouping will help align corporate costs in later stages of operations.
  • User count - How many users will be in each distinct persona?
  • Max session counts - Based on geography and hours of operation, how many concurrent users are expected for each persona during maximum load?

Distinctions in each of the preceding questions will start to illustrate user personas by business function, cost centre, geographic region, and technical requirements. The following table can aid in recording responses to populate a completed assessment or design document:

Criteria Persona Group 1 Persona Group 2 Persona Group 3
Pools Pooled Pooled Dedicated (security concerns)
Density Light (6 users/vCPU) Heavy (2 users/vCPU) Dedicated (1 user/vCPU)
Performance Low High memory Low
GPU N/A Required N/A
Azure region Australian Central Australian Central Australian Central
User count 1,000 50 20
Session count 200 50 10

The table below describes the User Personas design decisions for the solution.

Decision Point Design Decision Justification
Number of User Personas The considerations above will define the number of unique user personas. The number of user personas needs to be outlined early in the design process as this will align the group distribution and Windows 10 image alignment for each persona.
Personal and Pooled Images Pooled, where appropriate To ensure images are managed centrally, all will be configured as pooled images unless otherwise required.
Authentication Requirements Username, password and Azure MFA All remote users will be configured to utilise Multi-Factor Authentication as per ISM guidelines. Azure MFA will be implemented for this purpose.
User Personas The considerations above will define the user persona types Primary persona types that will be accessing the environment.
User Permissions Active Directory Group membership aligned to User Persona The groups used to provide users access to the AVD production host pool resources.
User Assignments Aligned to User Persona User assignment will be aligned to groupings aligned to the persona image type required.

Client devices

This section provides guidance for the client device-types that may access the environment and the peripherals that may be connected to the virtual desktops for the solution.

Consideration must be taken to determine the policy and features available to end users when accessing virtual desktops:

  • Device Types – Define what type of device users will access these AVD app and desktop resources from. These may include Windows PC, Apple MacOS, and various mobile devices such as iPads, Android tablets and smart phones.
  • Device Ownership – Dictates the policies that are applied to a session. For example, a BYOD device may receive a restricted set of policies that block copy and paste between their device and the virtual desktop.

The table below describes the Client Devices design decisions for the solution.

Decision Point Design Decision Justification
Device Ownership Corporate Devices (Intune Managed)
BYOD Device (External AVD Access)
Both corporate and BYOD devices may access the AVD solution.
Device Types Corporate Devices (Windows)
BYOD Devices (Any Supported AVD Platform)
Government agencies primarily utilise PCs to access the environments and BYOD will need to access via a support platform or a HTML5 capable browser.
Supported Client Devices and Web Clients See Supported Client Devices and Web Clients Any of the supported client devices or web clients can be used to access the AVD platform.
Client Device Configuration Refer to Client Device Considerations table To meet the requirements of this solution.

Client Device Considerations table:

Decision Point Design Decision Justification
Windows Desktop Client Version Latest version To ensure all security enhancements and feature availability. Corporate devices will be managed centrally.

For BYOD, users will be expected to install the client manually or use HTML5 client.
Base Installation Switches, if required RemoteDesktop.msi /qn Silent install for Remote Desktop client when using Device Management / AD Software Deployment.
Auto Discovery Corporate Email Set up DNS TXT Record for Email Address Discovery.
User Restrictions Corporate Devices - Intune Managed
Not Applicable

BYOD Device – User Managed
Drive redirection or mapping prohibited
Local printing prohibited
Clipboard prohibited
USB redirection prohibited
To enforce security requirements for data loss prevention.

To copy data to environment it is recommend using USB file transfer from Intune PROTECTED devices using approved USB devices.

Appendices

Appendix 1 – FSLogix profile redirections

The redirections.xml file is used to control what folders are redirected out of the profile container to the C: drive. It can also, optionally, sync the contents of these folders to and from the profile container at user sign-out and sign in respectively.

The location of the redirections.xml file resides in the profile container in the <ProfileRoot>\AppData\Local\FSLogix folder. The redirections.xml file is not pre-created in this directory path. You must create the file if it does not exist.

The admin can use the built-in distribution capabilities of the FSLogix agent, or any other mechanism, to place the file into the profile container. To use the built-in copy mechanism, use the RedirXMLSourceFolder setting. At user sign-in, the FSLogix agent will copy the redirections.xml file from the specified location (if it exists) and process it immediately. The user must have Read permissions to the file.

Redirections.xml

The below outlines the recommended base configuration for the FSLogix redirections.xml file for the solution. It provides base recommendations on what to include and exclude as part of the FXLogix profile redirection.

<FrxProfileFolderRedirection ExcludeCommonFolders="0">
    <Excludes>
        <Exclude Copy="0">Citrix</Exclude>
        <Exclude Copy="0">Videos</Exclude>
        <Exclude Copy="0">Saved Games</Exclude>
        <Exclude Copy="0">Contacts</Exclude>
        <Exclude Copy="0">Tracing</Exclude>
        <Exclude Copy="0">Music</Exclude>
        <Exclude Copy="0">Downloads</Exclude>
        <Exclude Copy="0">$Recycle.Bin</Exclude>
        <Exclude Copy="0">AppData\Local\assembly</Exclude>
        <Exclude Copy="0">AppData\Local\Sun</Exclude>
        <Exclude Copy="0">AppData\Local\VirtualStore</Exclude>
        <Exclude Copy="0">AppData\Local\CrashDumps</Exclude>
        <Exclude Copy="0">AppData\Local\Package Cache</Exclude>
        <Exclude Copy="0">AppData\Local\D3DSCache</Exclude>
        <Exclude Copy="0">AppData\Local\Google\Chrome\Software Reporter Tool</Exclude>
        <Exclude Copy="0">AppData\Local\Google\Chrome\User Data\BrowserMetrics</Exclude>
        <Exclude Copy="0">AppData\Local\Google\Chrome\User Data\CertificateRevocation</Exclude>
        <Exclude Copy="0">AppData\Local\Google\Chrome\User Data\CertificateTransparency</Exclude>
        <Exclude Copy="0">AppData\Local\Google\Chrome\User Data\Crashpad</Exclude>
        <Exclude Copy="0">AppData\Local\Google\Chrome\User Data\FileTypePolicies</Exclude>
        <Exclude Copy="0">AppData\Local\Google\Chrome\User Data\InterventionPolicyDatabase</Exclude>
        <Exclude Copy="0">AppData\Local\Google\Chrome\User Data\MEIPreload</Exclude>
        <Exclude Copy="0">AppData\Local\Google\Chrome\User Data\PepperFlash</Exclude>
        <Exclude Copy="0">AppData\Local\Google\Chrome\User Data\pnacl</Exclude>     
        <Exclude Copy="0">AppData\Local\Google\Chrome\User Data\Safe Browsing</Exclude>
        <Exclude Copy="0">AppData\Local\Google\Chrome\User Data\ShaderCache</Exclude>
        <Exclude Copy="0">AppData\Local\Google\Chrome\User Data\SSLErrorAssistant</Exclude>
        <Exclude Copy="0">AppData\Local\Google\Chrome\User Data\Subresource Filter</Exclude>
        <Exclude Copy="0">AppData\Local\Google\Chrome\User Data\SwReporter</Exclude>
        <Exclude Copy="0">AppData\Local\Google\Chrome\User Data\Default\Cached Theme Images</Exclude>
        <Exclude Copy="0">AppData\Local\Google\Chrome\User Data\Default\Cache</Exclude>
        <Exclude Copy="0">AppData\Local\Google\Chrome\User Data\Default\Code Cache\js</Exclude>
        <Exclude Copy="0">AppData\Local\Google\Chrome\User Data\Default\JumpListIcons</Exclude>
        <Exclude Copy="0">AppData\Local\Google\Chrome\User Data\Default\JumpListIconsOld</Exclude>
        <Exclude Copy="0">AppData\Local\Google\Chrome\User Data\Default\Media Cache</Exclude>
        <Exclude Copy="0">AppData\Local\Google\Chrome\User Data\Default\Service Worker\CacheStorage</Exclude>
        <Exclude Copy="0">AppData\Local\Microsoft\Internet Explorer\DOMStore</Exclude>
        <Exclude Copy="0">AppData\Local\Microsoft\Internet Explorer\Recovery</Exclude>
        <Exclude Copy="0">AppData\Local\Microsoft\Messenger</Exclude>
        <Exclude Copy="0">AppData\Local\Microsoft\MSOIdentityCRL\Tracing</Exclude>
        <Exclude Copy="0">AppData\Local\Microsoft\Notifications</Exclude>
        <Exclude Copy="0">AppData\Local\Microsoft\Office\16.0\Lync\Tracing</Exclude>
        <Exclude Copy="0">AppData\Local\Microsoft\Terminal Server Client</Exclude>
        <Exclude Copy="0">AppData\Local\Microsoft\UEV</Exclude>
        <Exclude Copy="0">AppData\Local\Microsoft\OneNote\16.0\cache</Exclude>
        <Exclude Copy="0">AppData\Local\Microsoft\Teams\Packages\SquirrelTemp</Exclude>
        <Exclude Copy="0">AppData\Local\Microsoft\Windows\Application Shortcuts</Exclude>
        <Exclude Copy="0">AppData\Local\Microsoft\Windows\AppCache</Exclude>
        <Exclude Copy="0">AppData\Local\Microsoft\Windows\DNTException</Exclude>
        <Exclude Copy="0">AppData\Local\Microsoft\Windows\GameExplorer</Exclude>
        <Exclude Copy="0">AppData\Local\Microsoft\Windows\IECompatCache</Exclude>
        <Exclude Copy="0">AppData\Local\Microsoft\Windows\iecompatuaCache</Exclude>
        <Exclude Copy="0">AppData\Local\Microsoft\Windows\Mail</Exclude>
        <Exclude Copy="0">AppData\Local\Microsoft\Windows\Notifications</Exclude>
        <Exclude Copy="0">AppData\Local\Microsoft\Windows\PRICache</Exclude>
        <Exclude Copy="0">AppData\Local\Microsoft\Windows\PrivacIE</Exclude>
        <Exclude Copy="0">AppData\Local\Microsoft\Windows\SchCache</Exclude>
        <Exclude Copy="0">AppData\Local\Microsoft\Windows\Temporary Internet Files</Exclude>
        <Exclude Copy="0">AppData\Local\Microsoft\Windows\WebCache</Exclude>
        <Exclude Copy="0">AppData\Local\Microsoft\Windows\WebCache.old</Exclude>
        <Exclude Copy="0">AppData\Local\Microsoft\Windows\WER</Exclude>
        <Exclude Copy="0">AppData\Local\Microsoft\Windows\1031</Exclude>
        <Exclude Copy="0">AppData\Local\OneDrive\cache</Exclude>
        <Exclude Copy="0">AppData\Local\Microsoft\Teams\Packages\SquirrelTemp</Exclude>
        <Exclude Copy="0">AppData\Roaming\Microsoft\Teams\Service Worker\CacheStorage</Exclude>
        <Exclude Copy="0">AppData\Roaming\Microsoft\Teams\Application Cache</Exclude>
        <Exclude Copy="0">AppData\Roaming\Microsoft\Teams\Cache</Exclude>  
        <Exclude Copy="0">AppData\Roaming\Microsoft Teams\Logs</Exclude>
        <Exclude Copy="0">AppData\Roaming\Microsoft\Teams\media-stack</Exclude>
        <Exclude Copy="0">AppData\Roaming\Sun\Java\Deployment\cache</Exclude>
        <Exclude Copy="0">AppData\Roaming\Sun\Java\Deployment\log</Exclude>
        <Exclude Copy="0">AppData\Roaming\Sun\Java\Deployment\tmp</Exclude>
        <Exclude Copy="0">AppData\Roaming\Macromedia\Flash Player\macromedia.com\support\flashplayer\sys</Exclude>
        <Exclude Copy="0">AppData\Roaming\Macromedia\Flash Player\macromedia.com\support\flashplayer\flashplayer\#SharedObjects</Exclude>
    </Excludes>
    <Includes>
        <Include Copy="3">AppData\LocalLow\Sun\Java\Deployment\security</Include>	
    </Includes>
</FrxProfileFolderRedirection>

Found an issue with the material above or have general feedback? Let us know over on Github.