Azure Virtual Desktop autoscale FAQ

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).

Yes. The minimum host pool size will override the number of session hosts you defined in the host pool.

No. You only need to define the session host limit with the minimum host pool size, the maximum host pool size, and the minimum percentage of active hosts (%). When the actual number of session hosts needed isn't larger than the minimum host pool size, autoscale will turn on session hosts if the used host pool capacity exceeds your defined capacity threshold. When the actual number of session hosts needed is larger than the minimum host pool size, autoscale will turn on the stopped session hosts and create additional session hosts. The total number of active session hosts won’t exceed the maximum host pool size defined in the scaling plan if the used host pool capacity exceeds your defined capacity threshold.

Autoscale creates session hosts with the latest valid/stable image version defined in the default session host configuration, if you don’t already have an active session host configuration.

You can either choose power management autoscaling as the scaling method when you create your scaling plan, or with dynamic autoscaling you can set the same value for Minimum host pool size and Maximum host pool size.

You can set the Minimum percentage of active hosts (%) to 100. Autoscale only creates or delete session hosts if the used host pool capacity exceeds or drops below your defined capacity threshold.

This might happen if the Maximum host pool size is configured differently in each phase. Autoscale deletes the active deallocated session hosts with no sessions to honor the Maximum host pool size setting in the current phase, and then continue to delete/deallocate session hosts based on the schedule and capacity threshold except in the ramp-up phase. No delete/deallocate action is taken as long as the number of session hosts in the host pool doesn't exceed the maximum host pool size. This behavior is consistent with the power management autoscaling scaling method, where session hosts aren't deallocated in the ramp-up phase for pooled host pools.

Yes, but when autoscale deletes a session host that you manually created, it will honor the settings you set whether to automatically delete the NIC and/or disk.