Smart Recovery™: Let Users Reset a Stuck Session

Let users clear a stuck desktop session from the User Portal with Reset My Session, and see how VM self-healing restarts unavailable session hosts.

Before you begin

  • Smart Recovery: the Professional plan or higher, with the User Portal turned on for the tenant (the portal is included on every plan)
  • The Smart Recovery admin page: an administrator account
  • VM self-healing: the Enterprise plan or higher

Where users find it

In the User Portal, users open Recovery from the sidebar. The page walks them through three steps, from least to most disruptive. Step 1 is Reconnect, which reopens their desktop, because most hiccups are a dropped connection. Step 2 offers Quick fixes: Reconnect or Retry last connection, Open in browser, Copy diagnostics (a summary to share with support) and Report a problem, plus a few tips such as signing out of the portal and back in. Step 3 is Reset Your Session, the last resort.

What Reset My Session does

  1. The user clicks Reset My Session, reads the warning to save open documents, and confirms with Reset Session.
  2. Atlas finds the user's session across your host pools. If the user has a disconnected session, that is the one it resets, so a healthy working session is left alone.
  3. Atlas signs the session off gracefully on the session host first.
  4. If the graceful sign-off fails, Atlas drains the host so it takes no new connections, and then forces the sign-off.
  5. When Atlas drained the host, it waits briefly for the user to reconnect on a different host, then lets the original host take new connections again.

Resetting signs the user out of that session. Anything they had not saved in it may be lost.

Safeguards

  • Only one recovery per user can run at a time. A second request while one is running is refused until the first finishes.
  • A host that was already drained before the recovery, for example by an administrator, stays drained. Atlas never turns on new connections for a host it did not drain.
  • If something interrupts a recovery, Atlas still turns new connections back on for any host it drained, so a host is not left drained.
  • Users see the friendly name of their desktop, never the session host's VM name.

What the user sees

While the reset runs, a progress bar shows each step: Detecting your session, Preparing your desktop, Signing you out. It finishes on one of three results, each with a Go to Desktops to Reconnect button:

  • Recovery Successful!: the session was reset and the user can reconnect now.
  • Session Reset — Follow-up Needed: the session was signed out and the user can reconnect, but the original host could not be put back into service. Your administrators are told so they can finish the job.
  • Recovery Failed: the reason is shown in plain language, for example no session was found to reset, the session could not be looked up just then, or the sign-off did not go through. Users can try again or contact support.

Below the reset card, Recovery History lists the user's recent resets with the desktop, status and time.

Follow every recovery as an admin

Open Intelligence → Smart Recovery, or search for Smart Recovery in the global search. You can also see recoveries on the Recovery Events tab of the Session Engine page. The Smart Recovery page shows:

  • Four cards across the top: Total Events, Successful (with the success rate), Failed and In Progress. These always count all of your tenant's recoveries, whatever the table is filtered to.
  • Recovery Event History: one row per recovery with the user, host pool, session host, status, start time and duration. The Details column shows the current step of a running recovery or the error of a failed one.
  • Search by user, email, host pool, session host or error, and filter by status (Success, Partial, Failed or In Progress) and by time range (Last 24 hours, Last 7 days, Last 30 days or All time).
  • Export the filtered rows to CSV or Excel (XLSX).

A Partial result means the user was signed out but the session host was left drained. Open that host in its host pool's Session Hosts table and turn its Maint. switch off once you have checked it, so it takes new sessions again.

How VM self-healing works

VM self-healing runs in the background on the Enterprise plan. It has no page or setting. It checks session hosts every couple of minutes. When Azure Virtual Desktop reports a host as Unavailable or Needs Assistance and it stays that way for a few minutes with no user sessions on it, Atlas restarts the host's VM. Restarting the VM is the only fix self-healing applies.

  • At most 2 restarts per episode (one stretch of being unavailable), with at least 10 minutes between them.
  • At most 6 restarts of the same VM in any 24 hours.
  • At most 5 restarts across your environment in one check, so a wide outage does not cause a flood of reboots.
  • After 4 hours unavailable, Atlas stops trying and leaves the host for you to look at.

When self-healing leaves a host alone

  • The host still reports user sessions.
  • A person drained the host, for example during patching or a manual fix.
  • The VM is being deleted or is waiting to be deleted.
  • The host pool is inside a maintenance window that pauses autoscale.
  • The host pool is an AVD Hybrid pool, because Azure cannot restart on-premises machines.

A skipped host does not use up a restart attempt. Atlas checks it again on the next pass. Every restart, failed restart and recovery is recorded in the audit log (Security → Audit) under Atlas Self-Heal.

Next steps