Blog Post

Azure Virtual Desktop Blog
3 MIN READ

Preferred app group type settings enhance user feed display

Seneca_Friend's avatar
Seneca_Friend
Icon for Microsoft rankMicrosoft
Jun 26, 2024

In line with our commitment to provide seamless and efficient experiences for Azure Virtual Desktop users, we've recently implemented Preferred app group type—an enhancement that improves how resources are displayed in the feed for users assigned to both RemoteApp and Desktop applications. Previously, people could be assigned both types of resources in their feed, but this could cause session connectivity issues. To address this, users are now required to specify the preferred application group type. With this update, only the preferred application group type resource will show in the feed to users that have been assigned both RemoteApp and Desktop. This prevents users from connecting to two different sessions simultaneously.

What does this mean for you?

The Preferred app group type setting is a mandatory configuration that determines whether users will see Desktop or RemoteApp in their feed if both have been published to them. If a user is assigned to both a Desktop and a RemoteApp application group, only the application group type specified in the Preferred app group type setting will be displayed in their feed. We urge all organizations using Azure Virtual Desktop to proactively set the Preferred app group type to either Desktop or RemoteApp.

Note: This update is being deployed progressively. Some have already received the update, while others will receive it over the coming weeks. You will be alerted via an Azure Service Health notification prior to this update. Currently, no host pools in the US have been updated.

How do I update the settings?

To determine the current setting and to update the Preferred app group type, you can use Azure Portal, PowerShell, or Azure REST API. It's important to note that you can only change the group type to Desktop or RemoteApp. Reverting it to “Not Set” is not an option.

In Azure Portal

When this setting has not been set Azure Portal will display:

In PowerShell

To view the setting run:

 

get-AzWvdHostPool -Name <host pool name> -ResourceGroupName ResourceGroupName <resource group name> | ft name, preferredAppGroupType

 

If the value has not yet been set, you will see “None” listed:

Via the Azure REST API

If the value has not yet been set, you will see “None” listed:

How do I set the Preferred app group type?

To set the Preferred app group type, you can use Azure Portal, PowerShell, or Azure REST API.

In the Azure Portal

You will need to select either Desktop or RemoteApp in the dropdown menu:

In PowerShell

To set this value run:

 

Update-AzWvdHostPool -Name <host pool name> -ResourceGroupName <resource group name> -PreferredAppGroupType <RailApplications or Desktop>

 

Via the Azure REST API

In the body of your Azure REST API PUT request, you will need to include:

 

"preferredAppGroupType": "<RailApplications or Desktop> ",

 

Benefits of updating Preferred app group type

This update is part of our ongoing efforts to optimize Azure Virtual Desktop and ensure it meets the evolving needs of organizations and their users. By enforcing the Preferred app group type, we aim to streamline the user experience and reduce the likelihood of session connectivity issues. We appreciate your cooperation in making these adjustments, and we’re here to support you through this transition. If you have any questions or need assistance, please refer to our documentation or contact Azure support.


Continue the conversation. Find best practices. Bookmark the Azure Virtual Desktop Tech Community.

Updated Jun 26, 2024
Version 1.0
  • MarekS's avatar
    MarekS
    Copper Contributor

    SGerrishMSTech If you are AVD admin, then you delegate managing group membership providing access to Desktop and RemoteApp. Then this 5% becomes much more, and people open both at the same time. If you need it for troubleshoot you can always RDP to full desktop (from any safe place you configured before for AVD admins).

    • SGerrishMSTech's avatar
      SGerrishMSTech
      Brass Contributor

      It seems you are missing the point. Sure, you can delegate group management or RDP into the server directly for troubleshooting, but the issue here is not the inability to do those things. The issue is the removal of an important option that has been there since day 1. It's great this change improves your environment, but for most, it does not. Plus, your struggle of people logging into both at once could have been resolved with simple group changes at the app group level...

  • MarekS That's great, but the majority of people (I assume) are not trying to run Desktop and RemoteApps at the same time. They are simply using RemoteApps 95% of the time, but 5% of the time, need to log into Desktop (not at the same time as RemoteApps) to do some tasks, troubleshoot, test things, etc. The inability to have the option for both is the main issue here, not that we can't use both at once.

  • MarekS's avatar
    MarekS
    Copper Contributor

    Finally, over one year ago we found having users connecting to Desktop and Remote Apps was corrupting fslogix user profile, and OneDrive configuration states that multi access to single fslogix profile is not supported. From that time we are using separate hostpool for Desktop and RemoteApps if such config is a must. Users can use both at the same time, with less issues in the environment.

  • It seems like all other comments have arrived at the same conclusion - This is a downgrade. This is not a new "feature" to streamline anything; this is a retroactive limitation. If users are trying to open Desktop and RemoteApps at the same time causing issues, this is a training and/or administration issue, not an issue Microsoft needs to solve. For years, Microsoft products have succeeded or failed depending on how SysAdmins configure things, and after all this time, now you guys try and put some guardrails to stop from issues happening? Come on...

     

    This needs some serious reconsideration. More environments than not, users need to be in the same host pool but have the option to choose Desktop or RemoteApps. There are times where even the same user may bounce between one and the other (by properly logging off, preventing duplicate sessions) depending on which app they need.

    As a real-world example, an improvement that is actually an improvement was the recently added support for OneDrive with RemoteApps (thank you for this!). I have multiple environments where the users only use Desktop because they need OneDrive with their other application for SharePoint integration. If I want to test the new OneDrive RemoteApp support with some users, rather than giving them access to RemoteApps alongside Desktop so they can use both for testing, I now need to restrict them to just RemoteApps, and if they run into issues with testing, they can't just switch back on their own. They instead have to call me, explain the test is not working, and I need to switch their App Groups so they can get back to work. This is a royal waste of time for the test users and me.

     

    Give us our freedom back.

  • larryw340's avatar
    larryw340
    Copper Contributor

    This is a step backwards. I have some users that need access to a desktop and some that need access to remote apps from the same session host in the same pool. I also have users that would like to login to the full desktop on occasion, but more often want to just run a single RApp application. 

  • OSuperfly's avatar
    OSuperfly
    Copper Contributor

    Tim,

    I totally agree with you. We also have environments where users are given to choice.

    Doesn't this change force us to create additional host pools to meet both requirements?

    Is it perhaps a marketing move?

  • TimPHT's avatar
    TimPHT
    Brass Contributor

    Hi,

    this seems like a huge feature downgrade to me.

    Now I cant give my users the option to choose if they prefer remote apps or the full desktop experience. 

    Also it makes testing in environments where we have both full desktops and remote apps on the same host pool more tedious.

    For me this change will not help streamline the experience for end users but degrade them.

    This will also lead to the need to recreate existing environments once the change is fully done to still be able to offer both remote apps and full desktop to a user.

     

    This unfortunately seems like a very short sighted decision and I would love to have a discussion about this.

  • This was an issue?
    If an admin can't maintain security groups to maintain control users to 1 option then I feel this is an admin issue NOT AVD problem to solve. 

    To me and my team the old way is actually a feature for us. I have folks assigned to both but I WANT them assigned to both by design as it is our end users choice to make.  My concern is your forcing 1 option VS the ability to have both options moving forward. 

    I feel this is going to cause a lot of turn for AVD Admins and not fully considered how it is used.