Shared (Multi-User)

This is the last post in a series of 3 where we look into the different auto-scale profiles that are available Within Nerdio Manager for Enterprise.
This time we will cover the individual settings for a Shared (Multi-User) Auto-scale profile.

Nerdio Manager for Enterprise offer 3 different autoscale profiles for Azure Virtual Desktop VM´s based on your specific needs, filling the gap from native functionality available in Azure.

These are:

• User-driven (Personal desktops)
• Schedule-based  (Personal desktops)
• Shared        (Multi-User desktops)

For information regarding the other profiles, click the corresponding links above.

Lets dive in to the different options we have and what they do! (To go straight to a specific section, click the corresponding link below:

HOST POOL PROPERTIES
HOST POOL SIZING
SCALING LOGIC
ROLLING DRAIN MODE
PRE-STAGE HOSTS
MESSAGING
AUTO-HEAL BROKEN HOSTS

Host Pool Properties

The properties below override the values set in the AVD section of the host pool properties.

• Session limits per host – Specify maximum number of sessions per host.
  Once this session limit is reached and there are no more available hosts, a new host will be started automatically, if it exists.
  
• Load balancing –
  • Breadth first – This spreads users evenly across available session hosts.
  • Depth first – This places users on a single host until the session limit is reached at which point users start being placed on the next host until the session limit is reached again.
    
• Start VM on connect -When enabled, stopped VMs will be automatically started when users attempt to connect
  

Host Pool Sizing

In this section we define what’s considered an “active” host, host pool sizing, auto-scale boundaries, and set parameters for minimum available and maximum possible capacity.

• Active host defines as:
  
  • AVD agent available – the system will identify a session host VM as “active” only when AVD back-end is receiving heartbeats and sees the session host as “Available”.
    
  • VM Running – the system will identify a session host VM as “active” as long as the VM is running in Azure.
    
• Base host pool capacity – The number of session host VMs to always be part of this host pool. These session hosts may be stopped or running.
  
• Min active host capacity – A minimum number of running session hosts to be available at all times. The system will ensure that at least this many hosts are always running. When this value is set to 0, the system will stop all running hosts during scale in period specified below.
  Be sure to configure scale in period (it cannot be set to <any time>) and enable PRE-STAGE HOSTS to turn VMs on.
  
• Burst beyond base capacity – Defines a set number of VM´s to “burst” above the standard number of session host VMs when there is user demand. The system will automatically create up to this number of new session host VMs above the “host pool capacity”, when needed.
  These session hosts will be the first ones to be removed when system scales in after business hours.

Scaling Logic

Define scaling logic for growing the size of the host pool (scale out) or shrinking it (scale in).

• Use multiple auto-scale triggers (advanced) – With this option enabled, multiple usage triggers can be used to scale out and scale in.
  
• Start or create (scale out) in groups of up to (X) host(s)
  
• Stop or remove (scale in) in groups of up to (X) host(s)

Triggers (scale out on ANY condition, scale in on ALL conditions)
Auto-scale will add capacity when ANY of the scale out conditions are met.
Capacity will be removed only when ALL scale in conditions are met.

• Select autoscale trigger
  • CPU – Increase number of hosts (scale out) when average CPU utilization across active session hosts in the pool exceeds the specified threshold. Decrease number of hosts (scale in) when average CPU utilization across active session hosts in the pool drops below the specified threshold.
    
  • RAM – Increase number of hosts (scale out) when average RAM utilization across active session hosts in the pool exceeds the specified threshold. Decrease number of hosts (scale in) when average RAM utilization across active session hosts in the pool drops below the specified threshold.
    
  • Avg Active Sessions – Increase number of hosts (scale out) when average number of ACTIVE user sessions across active session hosts in the pool exceeds the specified threshold. Decrease number of hosts (scale in) when average number of ACTIVE user sessions across active session hosts in the pool drops below the specified threshold.

• Scale in restrictions
  • Stop or remove (scale in) hosts only from – Perform scale in operation anytime or after specified hour of the day (usually end of business hours).
    
  • Scale in aggressiveness – Let you configure one of three modes on how to scale in VMs.
    • High – Auto-scale process will first look for hosts without any sessions and scale those in. Once only hosts with session remain, those with the smallest number of active sessions will be scaled in first after notifying users and waiting per configuration below.
      
    • Medium – Auto-scale process will first look for hosts without any sessions and scale those in. If hosts do not have active sessions (only disconnected) those will be scaled in too. Once only hosts with active sessions remain, the scale in process will not scale them in.
      
    • Low – Auto-scale process will first look for hosts without any sessions and scale those in. Once only hosts with sessions (both active and/or disconnected) remain, the scale in process will not scale them in.

Rolling Drain Mode

Create multiple drain windows and target a specific percentage of your hosts to drain mode.
The percent value includes ALL VMs in the host pool, both running and deallocated.
The last window will remain in effect until 11:59PM
This feature will respect the minimum trigger value for all configured auto-scale actions. These include:
Minimum active hosts
Minimum available resources (CPU, RAM)
Minimum available sessions
Only hosts which do not conflict with the minimum value will be considered for drain mode.

• Start time – Set the desired start time when this window will come into effect.
  
• % hosts in drain mode – Specify the target percentage of hosts in to be set in drain mode during this window.
  
• Load balancing
  • Breadth first algorithm spreads users evenly across available session hosts.
    
  • Depth first algorithm places users on a single host until the session limit is reached at which point users start being placed on the next host until the session limit is reached again.
    
• Scale in aggresiveness
  • Low (default) auto-scale process will first look for hosts without any sessions and scale those in. Once only hosts with sessions (both active and/or disconnected) remain, the scale in process will not scale them in.
    
  • Medium auto-scale process will first look for hosts without any sessions and scale those in. If hosts do not have active sessions (only disconnected) those will be scaled in too. Once only hosts with active sessions remain, the scale in process will not scale them in.
    
  • High auto-scale process will first look for hosts without any sessions and scale those in. Once only hosts with session remain, those with the smallest number of active sessions will be scaled in first after notifying users and waiting per configuration below.
    

Pre-Stage Hosts

Pre-stage host pool capacity by powering on or creating session hosts before the start of business hours to avoid a “logon storm.”

• Use multiple schedules – When enabled, multiple, non-overlapping pre-staging schedules can be used.
  
• Work days – Specify the workdays when large numbers of users log into their virtual desktops or applications at the same time.
  
• Start of work hours – Specify the time in the morning when users start logging into their virtual desktops or applications.
  
• Hosts to be active by start of work hours – Specify how many session hosts should be ready to accept user connection by this time.
  
• Scale in delay – Select a delay to restrict scale in operations after the start of work hours. Pre-staged hosts will not be scaled in during this time even if they are unused.

Messaging

During a scale in operation after business hours, the system will find session hosts with no active session or with the smallest number of active sessions.
If there are still users connected to a session host that has been selected for scale in, a message will be sent to the user, the session host will be placed in drain mode to prevent new connections and it will be stopped or removed after a pre-defined delay.

• Send a warning message to users on the host (X) before scaling in the host – Choose between 5, 10, 15, 30, 45 or 60 minutes)
  
• The message should say – Message to send to the users before disconnecting them during a scale in operation.

Auto-Heal Broken Hosts

Auto-scale can automatically attempt to repair “broken” session hosts by restarting them or running scripted actions (e.g. re-install AVD agent).

The AVD status is reported to the AVD service by the agent installed on the session host VM. If something is wrong, the status will be something other than “Available”. Not every status other than “Available” means that there is a problem.
The auto-heal operations will run when all scale out activity is complete and the system is in otherwise steady-state.

Hosts with active sessions may still be somewhat functional and such hosts will not be treated as broken. You have the choice to include these as well when triggering an attempt to repair.

• Host is broken if AVD agent status is (You can choose one or more triggers of)
  • Unavailible
  • Shutdown
  • Disconnected
  • Upgrading
  • Upgrade failed
  • No heartbeat
  • Not joined to domain
  • Domain trust relationship lost
  • SxS stack listener not ready
  • FSLogix not healthy
  • Needs assistance
  • Stale heartbeat (>2hrs)
    
    AND
  • Has no active sessions
  • Even has active sessions

• Minutes before first action
  Minutes to wait after host is detected to be broken before running first recovery action
  
• Recovery actions
  Select one or more recovery actions to run if a host is detected to be broken. The first recovery action will run after the number of minutes specified above and the system will wait the number of minutes specified below between recovery actions. Once the host exists the broken state (as defined above) subsequent recovery actions will not be executed. Recovery actions that are visible here are Powershell scripts and runbooks provided by Nerdio and scripts you have added to Nerdio Manager by linking a GitHub- or Azure Devops repository
  
• Minutes between recovery actions
  Number of minutes to wait after each recovery action before running the next one. Once host leaves its broken state (i.e it´s fixed) subsequent recovery actions will not run.

Final thoughts:
Wrapping up this three-part series, it’s clear that Nerdio Manager for Enterprise delivers a robust, adaptive approach to auto-scaling Azure Virtual Desktop environments.
The Shared (Multi-User) profile in particular showcases a deep level of customization—from session limits and load balancing, to proactive healing and pre-stage host preparation.

Auto-scale isn’t just about saving costs—it’s about delivering responsive performance while maintaining control and flexibility. By fine-tuning scaling logic, messaging, and recovery actions, IT admins can ensure optimal resource usage without compromising user experience.

Whether you’re scaling personal desktops based on schedules or empowering shared pools to self-heal and adapt, Nerdio’s profiles give you the precision you need.

Stay tuned for more insights and examples as we continue exploring smarter EUC strategies. And if you haven’t already, catch up on the full series to get the complete picture!