Users may easily and securely access their virtualized desktops and RemoteApps using the Azure Virtual Desktop service. You will learn a little more about the concept and foundational architecture of Azure Virtual Desktop in this topic.
When you run the Azure Virtual Desktop agent, a host pool of Azure virtual machines registers to Azure Virtual Desktop as session hosts. For a consistent user experience, all session host virtual machines in a host pool should come from the same image. Resources that are distributed to users via app groups are under your control.
There are two different kinds of host pools:
Personal: where each user is given a unique session host. End users can access dedicated desktops through personal host pools, which enhance environments for performance and data isolation.
Pooled: User sessions can be load balanced among any host in the host pool when they are pooled. On a single session host, various users can be present simultaneously. End users receive a shared remote experience via pooled host pools, which guarantees cheaper costs and more efficiency.
The capabilities that each kind of host pool provides are detailed in the following table:
|Feature||Personal host pools||Pooled host pools|
|Load balancing||User sessions are always load balanced to the session host the user is assigned to. If the user isn’t currently assigned to a session host, the user session is load balanced to the next available session host in the host pool.||User sessions are load balanced to session hosts in the host pool based on user session count. You can choose which load balancing algorithm to use: breadth-first or depth-first.|
|Maximum session limit||One.||As configured by the Max session limit value of the properties of a host pool.|
|User assignment process||Users can either be directly assigned to session hosts or be automatically assigned to the first available session host. Users always have sessions on the session hosts they are assigned to.||Users aren’t assigned to session hosts. After a user signs out and signs back in, their user session might get load balanced to a 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 Updates||Updated with Windows Updates, System Center Configuration Manager (SCCM), or other software distribution configuration tools.||Updated by redeploying session hosts from updated images instead of traditional updates.|
|User data||Each user only ever uses one session host, so they can store their user profile data on the operating system (OS) disk of the VM.||Users can connect to different session hosts every time they connect, so they should store their user profile data in FSLogix.|
A logical grouping of applications deployed on session hosts in the host pool is called as an app group.
There are two different sorts of app groups:
- RemoteApp, through which users can access the RemoteApps that you have personally chosen and made public to the app group. only accessible with pooled host pools.
- Desktop, from which users can access the complete desktop. accessible with shared or individual host pools.
If two resources have been published to the same user, pooled host pools have a preferred app group type that determines whether users view RemoteApp or Desktop apps in their feed. When you build a host pool, Azure Virtual Desktop automatically creates a Desktop app group with the friendly name Default Desktop and sets the preferred app group type for the host pool to Desktop. The Desktop app group is always removable. Set the Application group type value to RemoteApp if you only want your users to view RemoteApps in their feed. When a Desktop app group already exists in a host pool, another one cannot be created.
You must assign users to app groups before you can publish resources to them. Take into account the following factors when assigning users to app groups:
We oppose giving a user access to both the RemoteApp and desktop app groups in a single host pool. A single user will have two user sessions in a single host pool if this is done. Users shouldn’t have two active user sessions open at once because it may result in the following:
- The hosts of the sessions grow overburdened
- Users experience difficulties logging in, connections fail, and the screen goes blank.
- The application freezes
- Other deleterious consequences on end-user satisfaction and session effectiveness
- Within the same host pool, a user can be assigned to several app groups, and the feed for both app groups will be combined.
- Only Desktop app groups are supported and permitted by personal host pools.
The application group type for your host pool should be set to Undefined if it isn’t already. To avoid issues with app compatibility and session host overload, you must finish creating your host pool by setting its application group type before you begin utilising it.
In Azure Virtual Desktop, a workspace is a logical collection of application groups. Users cannot access distant apps and desktops that have been published to them until each Azure Virtual Desktop application group is linked to a workspace.
Users can connect to an Azure Virtual Desktop deployment using any of the Azure Virtual Desktop clients after being assigned to their app groups.
We’ll discuss each of the three sorts of user sessions that end users can have in this section.
Active user session
When a user logs in and connects to their remote app or desktop resource, the user session is considered “active.”
Disconnected user session
An inactive session that the user hasn’t yet signed out of is known as a disconnected user session. The session is terminated when a user closes the remote session window without signing out. A user will be directed to their disconnected session on the session host they were using when they re-connect to their distant resources. The disconnected session now resumes operation as an active session.
Pending user session
An empty seat on the load-balanced virtual computer is reserved for the user by a pending user session. This placeholder session ensures that the user won’t be thrown out of their session if another user completes their sign-in process before them because the sign-in process can take anywhere from 30 seconds to five minutes depending on the user profile.
For more information, contact Professional Labs, the Best Cloud Managed Services Provider UAE
Contact Us | Professional labs (prolabsit.com)