Part 5 | Step-by-Step Guide to Windows Virtual Desktop Fall 2019 Release

Share this post:
This content applies to the Fall 2019 release of Windows Virtual Desktop from Microsoft.

Part 5 | Manage App Groups

In Part 4, you created a host pool and session host VMs. You also added a user to the Desktop Application Group, which gave the user access to a full Windows 10 desktop experience. In this tutorial, you will learn how to add additional users to the Desktop Application Group, and create additional RemoteApp groups, where you can publish individual Start menu apps.

To create and manage RemoteApp groups, you will be using the Windows Virtual Desktop PowerShell module. Go back to Part 2 if you need to install and import the module. Then, sign into your account with the following cmdlet:

Add-RdsAccount  -DeploymentUrl   “”

Manage the Desktop Application Group

In the cmdlets used to create, manage, the Desktop Application Group and RemoteApp groups, you will find yourself typing your tenant name, host pool name, and app group names repeatedly. To make life a little easier, you can store this information in variables. If you choose not to use variables to store the names, skip to step 4, and type the full names in place of the variables.

  1. Get the name of your tenant you created in Part 2, and store the name in a variable:

$t = “TenantName”

  1. Get the name of your host pool you created in Part 4, and store the name in a variable:

Get-RdsHostPool $t
$h = “HostPoolName”

  1. Get the name of your app group and store the name in a variable. At this point, you should just have the default app group created when you created your hostpool, called “Desktop Application Group”:

Get-RdsAppGroup $t $h
$dag = “Desktop Application Group”

Aren’t these commands easier using variables?

You added a single user to the Desktop Application Group when you created the hostpool, and verified the user had access. Next, you will learn how to add additional users to the Desktop Application Group.

  1. The following cmdlet is used to retrieve the members of an app group:

Get-RdsAppGroupUser $t $h $dag

  1. To add additional users to an app group and verify membership:

Add-RdsAppGroupUser $t $h $dag -UserPrincipalName “userUPN”
Get-RdsAppGroupUser $t $h $dag

Unfortunately, you can only add users one at a time, and not groups. If you are feeling creative, you can use a script to automate adding multiple users.

Create a RemoteApp group

So now you know how to give users access to the full desktop experience, but what if they do not need the full desktop? You can create one or more additional app groups to publish individual or groups of applications as well.

The first RemoteApp group you create will be used to publish Microsoft Excel, Microsoft Word, and Microsoft PowerPoint. These are available if you used the Windows 10 multi-user with Office 365 image from the gallery when you created your hostpool. If you chose a different image, simply choose different applications to publish. You will see how to list the available applications to publish coming up.

  1. To create a new RemoteApp group, use the following cmdlet:

New-RdsAppGroup $t $h -AppGroupName “newName” -ResourceType “RemoteApp”

  1. To verify you created the RemoteApp group:

Get-RdsAppGroup $t $h

You should see the new RemoteApp group listed, along with the default Desktop Application Group.

Publish applications to a RemoteApp group

The new RemoteApp group is empty. You now need to publish applications to the RemoteApp group. To publish applications you will need to list what applications are available and add them to the RemoteApp group.

  1. To list the available applications:

Get-RdsStartMenuApp $t $h -AppGroupName “OfficeBasic”

Depending on your image, this list can be long. You only need the FriendlyName and AppAlias to publish an application. You can also store the new RemoteApp group name in a variable to make future cmdlets easier, otherwise use the full RemoteApp group name.

$ob = “OfficeBasic”
Get-RdsStartMenuApp $t $h $ob | ft FriendlyName, AppAlias

  1. Use the following cmdlet to publish an application to a RemoteApp group, repeating for each application you want to publish:

New-RdsRemoteApp $t $h $ob -Name “FriendlyName” -AppAlias “AppAlias”

  1. Verify all the applications were successfully published with the following cmdlet:

Get-RdsRemoteApp $t $h $ob | ft FriendlyName

Add users to a RemoteApp group

Now that you have created a RemoteApp group, you will need to grant users access. Users can be granted access to multiple RemoteApp groups. This allows you to control what apps a user has access to simply by granting or removing access to the RemoteApp groups.

You can create as many RemoteApp groups as necessary to support the various roles and needs of your environment. Maybe you have a basic app group that many users access, and specialty app groups for certain users that need a particular app or set of apps. When their access needs change, you can change what RemoteApp groups they have access to.

The exception is the Desktop Application Group. If a user has access to the Desktop Application Group, they already have access to all the available apps in the hostpool. Therefore, you cannot add them to any additional RemoteApp groups from that hostpool. If you want to limit what apps they have access to by adding them to RemoteApp groups, you will need to remove them from the Desktop Application Group first.

Try to add your test user that you gave access to the Desktop Application Group in Part 4 to the RemoteApp group you just created.

  1. To grant access to the RemoteApp group:

Add-RdsAppGroupUser $t $h $ob -UserPrincipalName “userUPN”

This will fail because “The specified UserPrincipalName(s) is already assigned to a Desktop AppGroup in the specified HostPool”

  1. You must first remove the user from the Desktop Application Group, then you can add the user to the RemoteApp group you created. Use the third cmdlet to verify the user has been granted access to the RemoteApp group:

Remove-RdsAppGroupUser $t $h $dag -UserPrincipalName “userUPN”
Add-RdsAppGroupUser $t $h $ob – UserPrincipalName “userUPN”
Get-RdsAppGroupUser $t $h $ob


  1. Now open a browser and navigate to Authenticate as the user you granted access to. You should see they no longer have access to the full desktop, only the applications you published.

  1. To test adding a user to multiple RemoteApp groups, first create another RemoteApp group and publish an application using the following cmdlets:

New-RdsAppGroup $t $h -AppGroupName “Publisher” -ResourceType “RemoteApp”
New-RdsRemoteApp $t $h -AppGroupName “Publisher” -Name “Publisher” -AppAlias “publisher”


  1. Add the same user to the second RemoteApp group:

Add-RdsAppGroupUser $t $h -AppGroupName

    1. Refresh the Remote Desktop Web Client, and the new app should appear.

What’s Next?

You have successfully deployed Windows Virtual Desktop. You have given users access to a full Windows 10 desktop, and to specific apps through RemoteApp groups. Now you need to get your users connected. In Part 6, we will look at the various methods they can use to connect from any device. See you there!

Interested in learning IT online? Here’s everything you need to know about the modern way of learning.

2 thoughts on “Part 5 | Step-by-Step Guide to Windows Virtual Desktop Fall 2019 Release”

  1. Thanks Mike, Very good explanation.
    Just have few questions.
    As WVD 2020 spring version released & its an Azure ARM based solution. is all the steps still valid? if yes, where we need to change? I was reading other article its saying now its more to GUI based and I think Term Tenant changed to workspace?
    I’m new to WVD , your guidance will be really appreciate. Thanks mate

    1. Hello Manoj,

      Glad you enjoyed the posts.

      As of July 27th, Windows Virtual Desktop Spring 2020 update is now generally available. Since you are just getting started with WVD, I would recommend making the switch to the new ARM-based model. Unfortunately, it is quite different from the 2019 version. The good news is that it is all created and managed from the Azure portal.

      There are some terminology changes, as you mentioned. We don’t have tenants, it is all done under your Azure tenant, and there are now workspaces that users connect to.

      Make sure to check out my hands-on series on the WVD Spring 2020 update.

Comments are closed.