Azure Virtual Desktop autoscale FAQ

No.

No.

No. Autoscale doesn't currently support ramping down on specific dates.

No. For more information on rates, see our pricing page.

Autoscale monitors for when users sign in or out of their session hosts and categorizes this activity as session change events. Session change events trigger a scaling evaluation that creates logs. If there aren't any session change events or the event service has an outage, autoscale then checks to see if it missed any events. When several session change events happen within a short time period, then the feature will batch the scaling evaluations. This batching allows autoscale to process large numbers of events quickly without overloading the system.

At least one.

No, currently autoscale doesn't offer the option to configure settings with Azure CLI.

Scaling plan configuration data must be stored in the same region as the host pool configuration, however, deploying session host VMs is supported in all Azure regions. VMs can be deployed in a different region than where the host pool and scaling plan configuration data is stored.

No. Customers need to set up their own disaster recovery strategy to manage outages. Autoscale only handles scaling existing VMs within the region they're created in.

No. Autoscale doesn't track which availability zone you create VMs in, so it may not perform scaling operations across all zones equally.

Ramp-down mode always uses the lowest possible number of session hosts. However, if there are existing user sessions, the lowest number of usable session hosts won't be zero. To configure the time limit policy to sign out all disconnected users to avoid having usable session hosts after hours, go to Local Computer Policy > Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Session Time Limits > Set time limit for disconnected sessions.

Nothing. Autoscale only reacts when the host pool capacity is greater than or less than the capacity threshold. The feature won't do anything when the host pool capacity is the same as the capacity threshold.

Yes, autoscale still turns VMs in drain mode on or off, no matter who put it in drain mode. Autoscale overrides drain mode on all VMs included in scaling, so if you want to exclude a VM from scaling actions, you must use exclusion tags.

Autoscale monitors for when users sign in or out of their session hosts and categorizes this activity as session change events. Session change events trigger a scaling evaluation that creates logs. If there aren't any session change events or the event service has an outage, autoscale then checks to see if it missed any events. When several session change events happen within a short time period, the feature batches the scaling evaluations. This batching allows autoscale to process large numbers of events quickly without overloading the system.

No. If you've enabled autoscale, you can only force users to sign out during the ramp-down phase. If you put a session host in drain mode during ramp-down to prepare it to be shut down but not all users sign out before the phase changes to off-peak, the remaining user sessions won't be forced to sign out from their session. The reason users aren't signed out is because autoscale doesn't force users to sign out of their sessions during off-peak hours. Instead, autoscale waits until all users have signed out before deallocating the VM. For example, if the ramp-down phase is 15 minutes long, and the wait time before signing out users and shutting down VMs is 20 minutes long, the schedule shifts to the off-peak phase and the user sessions won't be forced to sign out.

Yes. Idle, disconnected, and active sessions are forced to sign out if the users don't sign out during the ramp-down phase wait time.

After autoscale selects a session host to be shut down, it puts the session host in drain mode. Once all the user sessions have been signed out, autoscale deallocates the VM. After autoscale deallocates the VM, it sets the AllowNewSessions setting to true, which turns off drain mode. Because autoscale puts the sessions hosts that it's about to shut down in drain mode, a user who's forced to sign out of their session won't be able to connect to a session host that's about to be shut down if they try to reconnect after being signed out.

Autoscale can turn off all VMs in a host pool if the minimum percentage of hosts is set to 0% and there are no user sessions on the session hosts in the host pool.

When you set up your scaling plan schedule, you can specify different load balancing algorithms for different phases of the day. For example, during the ramp-up and peak phases, you can use the breadth-first load balancing algorithm. This algorithm ensures you have an even distribution of user sessions during the first two phases of the day, which optimizes performance. Likewise, during the ramp-down and off-peak phases, you can use the depth-first load balancing algorithm to help the autoscale feature consolidate user sessions until it reaches the minimal possible number of session hosts in the host pool.

If a session host is turned on (either by autoscale, Start VM on Connect, or by the admin) and a user never signs into it, autoscale will deallocate that session host after a period of inactivity to prevent from incurring unnecessary compute costs.

If you choose not to have personal desktops started by autoscale during the ramp-up phase, autoscale won't start your personal desktops. Instead you must either enable Start VM on Connect to ensure that personal desktops start up when users sign into them or manually start up the personal desktops yourself.

No. Autoscale for personal desktops only deallocates session hosts if the user has signed out of their user session.

For more information, see User session definitions.

No. When autoscale is ready to deallocate a personal desktop due to the user session being signed out or disconnected, autoscale doesn't put the session host in drain mode. If the user tries to connect while autoscale is deallocating the session host, they'll receive an error message that says "No resources available."

If you opt to have personal desktops hibernated in your personal scaling plan schedule, but the personal desktops don't have hibernate enabled, autoscale won't do anything to your session hosts (won't hibernate them and won't deallocate them).