262-299-4606 • Email us

Support Assist Feature

Joymalya Basu Roy from Atos shows you everything you need to know about Support Assist


Support Assist Feature

By Joymalya Basu Roy


Joymalya Basu Roy is an experienced professional in the IT services field within M365 Mobility and Security. He is currently working as a Technical Architect on Microsoft Intune with Atos. He is an ex-Microsoft employee working as Premiere Support Engineer on Microsoft Intune. This page is a copy of the original blog from Joymalya's "Learn with Joy" blog series that can be found here.


Support Assist feature helps your Help Desk to service your end-user requests more efficiently.

When I was doing the beta testing for the now public released ABR client (version 7), I came across a feature that was actually introduced back with the previous client (version 6.4) – Support Assist.

This blog post is to discuss and understand what that new feature is and what purpose does it serve. To understand the same, let’s start with the fundamentals of Admin By Request.

Different ways a user can request for elevated privilege with Admin By Request

On a Windows 10 endpoint enabled with Admin By Request client, the end-user gets the following options for requesting privilege elevations.

Run as admin

This is the most common scenario which your end-user would be using to

  • request privilege elevation to install/uninstall an application, or
  • run a particular application with elevated privilege.

Admin By Request - Run as admin is the most common form of elevation requests to be made by end-users. By nature, it is per-time per-app elevation request that end-user would require to make when requiring to run an app/process with elevated privilege.

Admin By Request – Run as admin is the most common form of elevation requests to be made by end-users. By nature, it is per-time per-app elevation request that end-user would require to make when requiring to run an app/process with elevated privilege.

As you can understand, this is a per-time per-app elevation request that the end-user would require to make when requiring to run an app/process with elevated privilege.

You would see the audit entries for such requests in the Admin By Request portal as shown below

Admin By Request - Check the Run as admin audit events from the ABR portal

Admin By Request – Check the Run as admin audit events from the ABR portal

You can click on any records to see the activity records in more details as below

Admin By Request - Click to open a Run as admin audit event to see further details for that transaction.

Admin By Request – Click to open a Run as admin audit event to see further details for that transaction.

Request administrator access

Run as admin, though the most common form of elevation requests to be made by your end-users, due to its nature of being per-app per-time is not that effective for scenarios where it involves or requires to run multiple tasks with elevated privileges simultaneously.

This is where Request administrator access comes handy.

You being the IT Admin can allow the end-user to start a protected admin session on the workstation where the user requesting the same will be provided with a sandboxed elevated session for a specified period of time as configured, thereby allowing the user to perform various elevated tasks simultaneously which otherwise required separate approvals.

Admin By Request - Request administrator session if configured (allowed) by IT Admin, provides end-user with a sandboxed elevated session for a specified period of time as configured, thereby allowing the user to perform various elevated tasks simultaneously which otherwise required separate approvals.

Admin By Request – Request administrator session if configured (allowed) by IT Admin, provides end-user with a sandboxed elevated session for a specified period of time as configured, thereby allowing the user to perform various elevated tasks simultaneously which otherwise required separate approvals.

In the below snap, you see an example Admin session in use where the end-user is installing an application and also working on an elevated PowerShell session. [Though this might not seem to be the best of examples, hope you are getting the point am talking about.]

Admin By Request - Request administrator session if configured (allowed) by IT Admin, provides end-user with a sandboxed elevated session for a specified period of time as configured, thereby allowing the user to perform various elevated tasks simultaneously which otherwise required separate approvals.

Admin By Request – Request administrator session if configured (allowed) by IT Admin, provides end-user with a sandboxed elevated session for a specified period of time as configured, thereby allowing the user to perform various elevated tasks simultaneously which otherwise required separate approvals.

If the Admin session is not allowed by IT Admin, the end-user would have required to make two elevation requests, separate Run as admin requests for performing the same set of activities.

As usual, the entire session is audited for the activities performed and is available for future reference.

Everything you need to know about Support Assist with Admin By Request - Learn with Joy 1

Admin By Request – Check the Admin Session audit events from the ABR portal

You can click to see further details, what all activities were performed during the elevated session.

Admin By Request - Click to open an Admin Session audit event to see further details for that transaction.

Admin By Request – Click to open an Admin Session audit event to see further details for that transaction.

Both the features as shown above had been a part of Admin By Request for a long and helps to address end-user requirements when it comes to elevation requests.

Then naturally comes the question.

What is Support Assist? What is the need for this new feature?

Understanding Support Assist and the need for it

Consider a scenario as below

  • End-user reaches out to helpdesk with a request to install some applications on his company device required for work. 
  • End-user asks helpdesk engineer to take a remote session and perform the activities as required as he is not that good with computers.
  • Helpdesk engineer initiates a remote session with end-user consent and proceeds to start an Admin session on the end-user device. (Or maybe request for Run as admin to execute an installer file.)

At this point, Admin By Request may either prompt to provide a Reason for the requested action or not, depending on configuration settings of the scope that applies to the end-user.

Admin By Reuqest - IT Admin can create seperate scopes (Global and multiples of sub-setting scopes) and then use those scopes to further control the elevation requests using any combination as deemed suitable per organization security policy.

Admin By Request – IT Admin can create seperate scopes (Global and multiples of sub-setting scopes) and then use those scopes to further control the elevation requests using any combination as deemed suitable per organization security policy.

Whatever be the configuration, the Helpdesk engineer starts the admin session (or Run as admin) on the end-user device over remote and performs the necessary activities as requested.

As usual, the action gets audited in the Admin By Request portal, but the audit event is tagged to the end-user account.

This is not ideal since even though it was the end-user requesting for the actions in the audit events as captured, but the activities were actually performed by the Helpdesk engineer.

Also when questioned later, the end-user may actually deny the audited actions stating that he/she provided remote access to the Helpdesk engineer and then went away to grab a coffee or maybe something else.

On the contrary, if the Helpdesk engineer logs-in to end-user device using his own credential and then there can again be two scenarios.

  • Helpdesk engineer has local admin rights on the endpoints by virtue of Azure AD Device Administrator role  or made via OMA-URI/PowerShell script deployment, and logs-in to the end-user device to perform the necessary actions/activities as per user request.

This action can’t be audited by Admin By Request and as such should be avoided if you are implementing ABR in your environment. Ensure that your Helpdesk team also goes via the Admin By Request flows when supporting end-users. This ensures proper audits of admin actions

  • Helpdesk engineer does not have local admin rights on the endpoint, but still logs-in to end-user device to perform the activities as requested by user, elevating the session/process via Admin By Request.

In this case, the audit will pick up the Helpdesk engineer as the current logged-in Windows user requesting elevation and performing activities.

This is not ideal either since even though the actions were performed by the Helpdesk engineer, which is true, but it was at the request of the end-user. Also, the end-user would not be able to monitor the actions of the Helpdesk engineer.

Thus, if auditing actions performed with elevated privilege on the endpoints is a concern, then the ideal audit event should show

  • the Requestor [End-user]
  • the Executor [Helpdesk Engineer], and
  • the actions/activities being performed with elevated privilege,

thus logging both the identities engaged in the entire transaction. This is what Support Assist in Admin By Request facilitates.

Support Assist introduces a whole new way of how IT Support can work to assist end-users more efficiently within the scope of Admin By Request.

When assisting end-user, helpdesk/deskside support engineers, instead of using the end-user logged-in Windows session or log-in to the end-user endpoint using own credentials to help resolve end-user requests, can make use of the Support Assist feature of Admin By Request which allows them to sign-in to Admin By Request on the end-user devices within the current end-user logged-in Windows session to start a support session within Admin By Request which is separate and not tagged to current logged-in Windows account and perform the actions as necessary to help resolve the end-user request.

The audit event for the session captures both the logged-in Windows user and the account used by the Helpdesk engineer to perform Support sign in.

Use-case scenarios of Support Assist

  • Users for whom IT has disabled both Run as admin and Admin Sessions (can be done using Global and Sub settings scopes) and as such are bounded to take assistance from the IT helpdesk for any tasks to be performed on the endpoint which requires admin rights.
  • Users for whom Run as admin/Administrator session is enabled but they are not the typical tech-savvy “IT users” and only go about doing their works on the device as configured and given to them by the company. Not very much affluent with self-service, they reach out to the IT helpdesk frequently to help sort issues.
  • Users who do not want to request for a Run as admin/Administrator session for app install/uninstall since they know the action will get audited and thus a concern.

Experience Admin By Request Support Assist feature

  • Helpdesk engineer starts a remote session with the end-user to assist.
  • Helpdesk engineer clicks on the Admin By Request icon expanding the System Tray and clicks on About Admin By Request and then clicks on Connectivity.

Starting a Support Assist session with Admin By Request - Available with client version 6.4 and above.

Starting a Support Assist session with Admin By Request – Available with client version 6.4 and above.

  • Helpdesk engineer clicks on Support sign in button the window that appears.

Starting a Support Assist session with Admin By Request - Support Sign in button facilitates Helpdesk engineer to sign-in to ABR client and run it seperately from the current logged-in Windows account.

Starting a Support Assist session with Admin By Request – Support Sign in button facilitates Helpdesk engineer to sign-in to ABR client and run it seperately from the current logged-in Windows account.

  • Helpdesk engineer performs sign-in using own credentials.

Starting a Support Assist session with Admin By Request - Support Sign in button facilitates Helpdesk engineer to sign-in to ABR client and run it seperately from the current logged-in Windows account.

Starting a Support Assist session with Admin By Request – Support Sign in button facilitates Helpdesk engineer to sign-in to ABR client and run it seperately from the current logged-in Windows account.

A new Admin By Request session starts which runs as a separate process.

An Admin By Request branded pop-up window is displayed for the entire duration of the session which shows the account name that the helpdesk engineer used to sign-in to start the support session and also a timer similar to the Admin session.

Starting a Support Assist session with Admin By Request - Support Sign in button facilitates Helpdesk engineer to sign-in to ABR client and run it seperately from the current logged-in Windows account.

Starting a Support Assist session with Admin By Request – Support Sign in button facilitates Helpdesk engineer to sign-in to ABR client and run it seperately from the current logged-in Windows account.


There are actually two instances of the Admin By Request client process running on the end-point when a Support Assist session starts.

One always runs with the end-user identity (or the logged-in Windows user) and the other gets started as a result of Support sign-in running with the identity used by the Helpdesk engineer to sign-in to Admin By Request to start the support session.

A Support Assist session initiates two processes of Admin By Request on the endpoint - one running with Windows logged-in user account and the other running with the helpdesk engineer provided account to do the Support sign in

Support Assist session initiates two processes of Admin By Request on the endpoint – one running with Windows logged-in user account and the other running with the helpdesk engineer provided account to do the Support sign in


Note: Helpdesk engineer starting a Support Assist session does not gain complete local admin privilege on the endpoint. The session is under the effect of the settings as configured by the IT Admin for the scope to which the Helpdesk engineer belongs.

Once done with assisting the end-user with the requested changes, the Helpdesk engineer can end the Support Assist session by clicking on the Done button and further confirming with Yes in the pop-up window.

Ending a Support Assist session with Admin By Request - Helpdesk Engineer clicks on Done when completed with making the necessary changes on the endpoint as requested by end-user and confirms to close the elevated support session.

Ending a Support Assist session with Admin By Request – Helpdesk Engineer clicks on Done when completed with making the necessary changes on the endpoint as requested by end-user and confirms to close the elevated support session.

Viewing Audit Events for a Support Assist session

Navigate to Auditlog tab within the Admin By Request portal to see audited events.

You can easily identify a Support Assist ABR elevation event from a normal ABR elevation event by looking at the User column.

Such events always come up with the end-user account (Windows logged-in user) followed by the account which was used by the helpdesk engineer to sign-in to ABR to initiate the Support Assist session.

Support Assist session with Admin By Request - Support Assist sessions can be easily identified in audited events since they appear with the end-user account (Windows logged-in user) followed by the account which was used by the helpdesk engineer to sign-in to ABR to initiate the Support Assist session.

Support Assist with Admin By Request – Support Assist sessions can be easily identified in audited events since they appear with the end-user account (Windows logged-in user) followed by the account which was used by the helpdesk engineer to sign-in to ABR to initiate the Support Assist session.


Support Assist audit events clearly shows

  • the logged-in Windows user (end-user) [Typically the Requestor]
  • the Helpdesk engineer who assisted the end-user [The Executor]
  • the app/program which was elevated (and if any software was installed/uninstalled)

Support Assist with Admin By Request - Support Assist sessions clearly shows the Requestor [End-User], Executor [Helpdesk Engineer who assisted] and the actions performed during the transaction.

Support Assist with Admin By Request – Support Assist sessions clearly shows the Requestor [End-User], Executor [Helpdesk Engineer who assisted] and the actions performed during the transaction.

Interested in Admin By Request?

Feel free to reach out to us for a discussion on how we can help you.

OTHER CYBERSECURITY BLOGS