Host Pools, Application Groups and Workspaces: The Rules That Connect Them

A user opens Windows App and sees nothing. The session hosts are healthy and nothing is wrong with the network. The cause is often one of the rules that connect the four AVD objects: a missing assignment, an application group that is not in a workspace, or a setting that hides what you published.

This article explains those objects and the rules between them, shows which choices cannot be changed after creation, and gives a short order of checks for an empty feed. The architecture article introduced the objects. This one goes deeper into how they fit together.

Key terms

The four objects in one picture

Read it from the bottom up. Session hosts live in a host pool. An application group publishes something from one host pool. A workspace lists application groups. Users are assigned to application groups, not to host pools and not to workspaces.

The rules

These rules are documented. Several of them decide whether a design works.

Notice the wording on location. For the application group and host pool it says "should", which makes it a design rule. For the workspace it says the service "requires" it, which makes it a hard constraint. A consequence, which follows from the rule and is not stated in these words: a design that spans several locations needs more than one workspace, and users who need resources from several locations subscribe to more than one workspace.

What can be changed later

Three choices are fixed when you create the object. Plan them before the first deployment.

The management approach decides who looks after session hosts. With a session host configuration, AVD creates, updates and scales the hosts using a stored configuration. It works with pooled host pools only, and you cannot create, update or scale hosts outside the service with tools built for standard management. With standard management you create, update and scale the hosts yourself, which suits existing pipelines and scripts. Later articles in this series cover host management in more depth.

Where assignment happens

AVD publishes an application group to users by assigning the Desktop Virtualization User role to the user or group, with the application group as the scope. The documentation shows this with the New-AzRoleAssignment PowerShell command (cmdlet), and the same assignment can be made in the portal. The person who makes the assignment needs the User Access Administrator role on the application group. Creating host pools and other objects needs the Contributor role on the subscription or resource group.

Two points to remember.

• Use security groups. AVD does not support Microsoft Entra distribution groups. If a user is in the group only through a distribution list, they will see nothing.
• Assignments belong to the tenant. If a subscription moves from one Microsoft Entra tenant to another, the service loses track of the assignments, because they are tied to the old tenant. Assign the users to their application groups again.

Desktop and RemoteApp on the same host pool

A pooled host pool can have both a desktop application group and RemoteApp application groups. That can give one user two sessions on the same pool: one for the desktop and one for an application. The documentation warns that two sessions to the same host pool can overload session hosts, leave users stuck at sign-in, make connections fail, turn the remote session black and crash applications.

The preferred application group type setting reduces this. If a user is assigned to both types on one pool, the client shows only the preferred type.

Four details from the documentation.

• The setting affects only users who are assigned to both types on the same pool. A user can still see a desktop from one pool and RemoteApp applications from another.
• In the Azure portal, the default is Desktop. The portal also creates a desktop application group named after the host pool with the suffix -DAG, for example hp01-DAG, whichever preferred type you choose. You can delete it afterward if you want only RemoteApp. These two portal behaviors do not happen when you create the pool with PowerShell or the Azure CLI.
• Older pools with no preferred type now show only the desktop to users assigned to both types. The documentation says this enforcement is still rolling out to all Azure regions.
• The setting controls what the client shows, not what the service allows. The ms-avd:connect URI scheme can still open both, and the documentation does not recommend this.

A recommendation, not a documented rule: if the same users need both a full desktop and RemoteApp applications, consider separate host pools. It costs more compute, but it removes the two-sessions problem instead of hiding it.

Plan the objects for your design

This section is a recommendation, because the documentation gives the rules but not a design.

• Create a host pool for each group of users whose compute, image or security needs differ. Do not create one just because a department asked. The host pool planning article shows how to group users.
• Create an application group for each distinct set of resources and each distinct audience. Assign security groups to application groups so that adding a person is a group membership change.
• Create a workspace for each audience and location that should see a set of application groups together. Name them so users can tell them apart.
• Write down the settings that cannot change before the first host pool is created: pool type, management approach and deployment scope.

When a user sees nothing

The documentation's no-feed troubleshooting steps cover the first four rows and the tenant move row: the assignment, the account, cached credentials in the web client, the security group, and a moved or transferred subscription. The workspace, scope, location and preferred type rows come from the rules above, not from that page, and the Conditional Access row comes from a separate section of the same page. The order is how quickly each is to rule out, which is a judgement.

If the desktop appears but will not open, the object model is working and the problem is in the connection or the session host. The failure article separates those cases, and the connection article walks through a connection step by step.

Common mistakes

• Assigning users to a host pool. The assignment belongs on the application group.
• Building a host pool for each department. Pools exist to group hosts with the same needs.
• Deleting the -DAG application group without knowing why it exists. That is fine for a RemoteApp-only pool. It surprises people who later want to publish a desktop.
• Expecting one workspace to hold everything. Location and deployment scope rules limit what one workspace can hold.
• Assigning both desktop and RemoteApp groups on one pool without thinking about sessions. The preferred type hides one of them, which may not be what you intended.
• Choosing pool type, management approach or deployment scope casually. None of these can be changed later.

How to validate your object model

These are recommended checks. Run them before you add users.

1. For each application group, note its host pool and workspace, and confirm both are in the same location and deployment scope.
2. Assign a test user through a security group and sign in with Windows App. Confirm the expected resources appear and nothing extra.
3. Test a user who is in two groups, one for each application group type, on a pool with each setting of the preferred type. Confirm the client shows what the table says.
4. Remove the test user from the group and confirm the resources disappear after the client refreshes.

Related book chapter, labs and project

Chapter 3 of the book covers the object model. Lab 2 builds the Terraform foundation (Terraform is a tool that describes Azure resources as code), Lab 7 creates the host pool, workspace and desktop application group, and Lab 9 publishes a RemoteApp. The labs walk through those steps. None has been run end to end in Azure. Project 10 is a fictional case study.

Next: Follow a Connection Step by Step: Reverse Connect, RDP Shortpath and Where It Breaks.

Sources

Azure Virtual Desktop terminology, preferred application group type and FAQ.