Every pool is now a load balancing pool, which spreads users across the computers in the pool instead of letting one machine carry more than it should. Two methods are available. Based on Performance sends each user to the computer with the most capacity at that moment. Round Robin assigns them in order for an even, predictable split.

Based on Performance is the default, and you can switch methods later from the pool’s Settings tab. One thing to watch: switching resets any Auto Scaling configuration back to its defaults, so plan to set that up again afterward. Before this release, the pool type was picked once during creation and stayed that way.

Pools running Based on Performance get a new Auto Scale step. Turn it on and we create new computers in the pool once your scaling thresholds are met, so nobody has to sit watching a dashboard waiting for the pool to fill up. It is off by default, and it is not available on Round Robin pools.

Enabling it comes down to four decisions:

• The template new computers are built from
• The region they are created in
• The hardware plan, or a custom CPU and RAM combination with pricing shown as you adjust it
• At least one scaling trigger: users per computer (1 to 99), utilization (50 to 100%), or both

Scaling only fires once every computer in the pool has reached a threshold, and a 60 minute cooldown sits between events, so a busy afternoon will not spin up more machines than you actually need. An Autoscaling Triggered notification goes out each time a new computer is created. Auto-scaled computers are billed at the hardware plan you selected.

Auto Scaling requires a custom template. Without one, the Auto Scale step shows a banner explaining what is missing and the toggle stays disabled. To create a template, open Manage VM on any cloud computer and choose Convert to template. You can enable, reconfigure, or turn Auto Scaling off later from the pool’s Settings tab.

Creating a pool moved from a single page into a step by step modal: Type, Settings, Auto Scale, Authentication, and Build. The Auto Scale step only shows up for Based on Performance pools, so picking Round Robin gives you a four step flow instead.

Choosing computers is quicker. The list is searchable, has a Select all option, and shows each computer’s current user count next to a Multi-user or Individual badge. Computers can also be added after the pool exists, so the first pass does not have to be perfect.

Authentication options are the same as before. V2 Users, Active Directory connectors, and SSO connectors are all still there, just presented in a cleaner selector. The final Build screen recaps the pool type, load balancing method, Auto Scaling state, authentication method, and selected computers before anything is created. Worth knowing: the authentication method is locked in at that point and cannot be changed later.

The list used to give you a name, a description, and a type. It now adds a Computers column, a Created column with date and time, computer and user counts under each pool name, and the pool type as a badge. You can see which pools are carrying load without opening a single one.

Row actions are simpler too. Edit, Manage, and Delete became Manage Pool and Delete Pool, with editing now living inside the Manage page’s Settings tab. Search, CSV, print, PDF export, and pagination all work the way they did before.

Five tabs became three. The Manage Pool page now holds Computers, Users, and Settings. Directory Access and SSO Access are gone, since the authentication method is set when the pool is created and now shows up as a read only domain field in Settings.

A breadcrumb header replaces the old pool switcher chip. It carries the pool’s name, description, type badge, computer and user counts, and authentication domain, so you always know which pool you are working in.

The Computers tab lists each computer with its template and status, with actions on every row plus an Update Computers checklist for adding and removing several in one pass. Pull a computer out of a pool and we ask what should happen to the users sitting on it rather than deciding for you.

Settings handles name and description edits, the load balancing method switch, and the Auto Scaling panel on Based on Performance pools, where you can enable it, reconfigure it, or turn it off. Pool deletion lives there too, behind a clear warning, because it is permanent and erases the pool’s associated SSO data.

All pool users now sit in one table with login ID, full name, connected sessions, and creation date. Each row carries its own actions, and bulk selection handles several users at once.

Remove and Delete are now separate actions, which matters more than it sounds. Removing takes a user off the pool and restores whatever access they had before. Deleting wipes the user permanently. A misclick no longer costs you an account.

Adding a user happens in the same tab. Pick the OS login preference (Local, Azure^®, Domain, or Self Managed) and login and Windows^® passwords are generated for you, with copy and regenerate buttons alongside them. Enter an email that already belongs to a V2 Cloud user and we grant that person access to the pool instead of creating a duplicate account.

The same flow covers the rest of the setup: apply White Label, enforce two-step authentication, require a password change at next login, keep the OS password in sync, email our setup instructions straight to the user, scope access to the full desktop or specific published apps, and flag the user as an administrator.