How to use this document

Sections 1–4 are written for management and security stakeholders (what it is, why it helps, how it compares, and whether it can replace current tools).

Sections 5–10 provide technical enablement details (security, RBAC, ports/URLs, Zscaler configuration, session flow, and deployment).

Environment: hybrid identity (on-prem AD + Entra Connect + Entra hybrid join) with authentication federated to Okta, assuming that Zscaler SSL inspection is enabled.

1. Executive Summary

Microsoft Intune Remote Help is a cloud-based remote assistance solution that lets the help desk connect securely to an end user’s device for real-time, attended support. It is delivered as an Intune add-on (available standalone or as part of the Intune Suite) and is built specifically for organizations that already manage identity and devices through Microsoft Entra ID and Intune.

The value proposition for us is that Remote Help replaces ad-hoc, less-governed remote tools with a solution that is identity-bound, consent-based, role-controlled, and fully auditable. Both the technician (“helper”) and the user (“sharer”) sign in with their own Entra ID accounts, so assistance is limited to their tenant and to the exact permission level we grant for each support tier.

It works identically for on-premises and remote/work-from-home users because all traffic is outbound HTTPS to Microsoft cloud endpoints — there is no inbound firewall rule, no VPN dependency, and no listening port on the endpoint. The one environmental prerequisite for us is allowing the required Microsoft URLs through the network path. Because the company uses Zscaler, that means excluding the Remote Help and Azure Communication Services endpoints from SSL inspection and ensuring the real-time media traffic is allowed, this document specifies exactly what to configure.

Key points at a glance

Dimension	Summary
What it is	Cloud remote assistance integrated with Intune & Entra ID, attended view, full control, and UAC elevation on Windows.
Who it secures	Helper and sharer both authenticate to their respective tenants via Okta federation; cross-tenant assistance is not possible.
Access control	Intune RBAC defines who can help and at what level (view-only, full control, elevation). Conditional Access can enforce MFA / compliant device for helpers.
On-prem vs remote	Identical experience — outbound 443 only, no inbound ports, no VPN required.
Encryption	RDP session over TLS 1.2 to the Remote Assistance Service, media over encrypted Azure Communication Services.
Auditability	Session reporting and Intune audit logs (who helped whom, on what device, how long). No keystroke/recording access by Microsoft.
Network change	Allow-list Microsoft endpoints and bypass SSL inspection in Zscaler, allow UDP media for Azure Communication Services.
Licensing	Remote Help add-on or Intune Suite license for every helper and sharer.

2. What Remote Help Is and How It Works

Remote Help establishes a trusted, consent-based session between a helper and a sharer. Both parties launch the Remote Help app (or, for limited scenarios, a browser-based web app) and sign in with their organizational Entra ID account. Microsoft Entra ID establishes the trust between the two parties for the session, and the connection is brokered through the Microsoft-hosted Remote Assistance Service. In the hybrid environment, that Entra ID sign-in is federated to Okta, which performs the primary authentication against on-premises Active Directory, the user accounts are synchronized from on-prem AD into Entra ID by Entra Connect, and corporate devices are Microsoft Entra hybrid joined.

2.1 Core concepts

• Helper — the support technician who provides assistance.

• Sharer — the end user who shares their screen/session with the helper.

• Tenant-bound — helper, sharer, and device must all be in the same tenant, you cannot assist users in another tenant or external organization.

• Consent-based — on Windows, every session is initiated and accepted by the user, and a remote session is visibly indicated on screen.

2.2 Session modes (Windows)

The level of interaction is selected per session and is bounded by the helper’s assigned permissions:

Mode	What the helper can do
View only	See the sharer’s screen without taking control. Recommended default to minimize privacy impact.
Full control	View and control the sharer’s device after the sharer grants access.
Elevation	Respond to Windows User Account Control (UAC) prompts by entering credentials allows supporting tasks that require admin rights without exposing the password to the user.
Unattended	Connect without the user accepting each time. Windows is not supported for unattended.

2.3 Notable capabilities

• Compliance warning before connecting, the helper is warned if the target device is non-compliant with its assigned Intune/SCCM policies.

• Remote launch a helper can trigger Remote Help on the sharer’s device from the Intune admin center via a notification (requires the Intune Management Extension IME).

• Chat is a continuous in-session chat thread (can be disabled tenant-wide).

• Session monitoring & reporting active and historical session details in the Intune admin center, plus audit logs under Tenant Administration.

• Web app for sharers where the native app cannot be installed, the sharer can share via a supported browser (view-only to the helper).

3. Benefits to the IT Team and End Users

3.1 For the IT / helpdesk team

• Governed, least-privilege access Intune RBAC means a tier-1 agent can be limited to view-only, while tier-2 gets full control and elevation. Access maps to support role, not to a shared password.

• Faster resolution with elevation technicians can complete admin-level fixes by answering UAC prompts themselves, without handing local-admin rights or credentials to the user, or letting the support team use a long LAPS password.

• Device context before connecting the compliance warning surfaces risk (non-compliant device) up front.

• Built-in accountability every session is tied to a named Entra identity and logged, which supports security review and offboarding (removing a leaver from the role instantly revokes their ability to help).

• No extra infrastructure as a cloud service, there are no gateways, jump servers, or on-prem connectors to stand up or patch.

• Integrated with the existing stack one identity (Entra ID), one management plane (Intune), one audit trail, data can be correlated with Endpoint Analytics to spot recurring issues.

3.2 For end users

• Same support whether on-prem or remote a home or traveling user gets identical assistance to someone on the corporate LAN, with no VPN needed for the support session itself.

• In control and informed the user starts and accepts the session, sees a clear on-screen indicator while it is active, and can end it at any time.

• Trust by design only an authenticated member of their own organization can connect, the helper’s name, job title, and company are shown from their Entra profile.

• Lightweight a single app (or browser) on the device, no personal account, no third-party tool.

3.3 On-premises and remote users — why both work the same

Remote Help makes no distinction between network locations because the connection is always an outbound, helper-initiated/sharer-accepted session to Microsoft cloud endpoints over TCP 443 (with UDP used for real-time media). There is no inbound connection to the endpoint and no requirement that helper and sharer share a network. Practically:

• On-prem users: traffic egresses through the corporate proxy/Zscaler path the only requirement is that the Microsoft endpoints are reachable and not SSL-inspected (see Sections 7 and 8).

• Remote users: traffic egresses from wherever they are, if Zscaler Client Connector is in use, the same endpoint allow-list and media-bypass rules apply on the forwarding profile.

4. Comparison with Third-Party Remote Tools

The two incumbents most often compared with Remote Help are GoToAssist now LogMeIn Resolve, after the GoToAssist → GoTo Resolve → LogMeIn Resolve rebrands, and Bomgar, now BeyondTrust Remote Support. Both are mature, capable platforms. The essential difference is scope and design intent: Remote Help is a focused, identity-bound internal helpdesk tool that is part of the Microsoft/Intune stack, whereas the other two are broad, standalone remote support platforms (LogMeIn Resolve adds full RMM/endpoint management and ticketing) that also serve external customers, vendors, and unmanaged devices.

4.1 Side-by-side comparison

Dimension	Intune Remote Help	LogMeIn Resolve (was GoToAssist)	BeyondTrust Remote Support (was Bomgar)
Design intent	Internal employee help desk, built into Entra / Intune	Remote support + RMM/UEM + ticketing for IT & MSPs	Enterprise & privileged / vendor remote support
Who you can support	Your own Entra users, Intune-managed (optionally unenrolled) Win / macOS / Android	Anyone employees and external customers, managed or not	Anyone employees, customers, vendors, managed or not
Identity / trust	Entra ID, both ends authenticate to your tenant, cross-tenant impossible	Vendor accounts / SSO	Vendor accounts / SSO + AD integration
Attended / unattended	Attended (Win / macOS), unattended only on Android dedicated	Both, on all platforms	Both, jump clients + pre-logon / SYSTEM access
Platforms	Windows, macOS, Android, view-only web app	Windows, macOS, Linux*, iOS, Android, ChromeOS	Windows, macOS, Linux, iOS, Android, ChromeOS
Privileged access/vaulting	UAC elevation only	Limited (zero-trust command approval)	Strong PAM heritage (credential injection/vault)
Session recording	No (audit metadata only)	Yes	Yes
RMM / patch/scripting / ticketing	No use Intune separately	Yes — full suite	Partial (support-focused)
Deployment	SaaS (Microsoft cloud)	SaaS (vendor cloud)	SaaS or on-prem / virtual appliance
Licensing	included in Intune Suite G5	Per agent + per-device tiers	Concurrent / named enterprise licenses
Indicative price	Paid by G5 license	~US$ per agent/month	Enterprise quote, historically high
Network posture	Outbound 443 + UDP media to MS cloud, no inbound, no VPN	Outbound to vendor cloud, no inbound	Outbound to cloud or your appliance, no inbound

4.2 Where the third-party tools are still stronger

• External & vendor support — helping customers, partners, or unmanaged third-party devices that are not in your tenant. Remote Help cannot do this, it is tenant-bound.

• Unattended Windows access — servers, kiosks, or always-on machines with no user present. Remote Help has no unattended Windows mode, both incumbents do.

• Privileged access management — BeyondTrust offers credential injection / vaulting and strong governance for privileged and vendor access, Remote Help offers UAC elevation only.

• Session recording for compliance — both incumbents record sessions, Remote Help keeps audit metadata, not recordings.

• Bundled RMM / ticketing — LogMeIn Resolve includes patching, scripting, monitoring and a help desk in one product, Remote Help does none of these (Intune covers management separately).

• On-prem / air-gapped option — BeyondTrust can run on its own appliance, independent of a vendor cloud.

4.3 Where Remote Help is the better fit for us

• Already in the stack — no new vendor, contract, or identity store, it uses the Entra ID and Intune we already run.

• Tighter security for internal support — tenant-bound, RBAC-scoped, Conditional-Access-enforced, consent-based, least standing privilege.

• Lowest unit cost & simplest licensing — Included in G5 Intune Suite, we already owned.

• No extra infrastructure — nothing to run or patch, one audit trail alongside Intune, plus a native non-compliance warning before connecting.

4.4 Can Remote Help replace them and save budget?

Yes, for the internal, attended employee helpdesk use case, Remote Help can replace GoToAssist /LogMeIn Resolve or Bomgar/BeyondTrust and eliminate recurring third-party spend, provided every scenario you rely on is internal-facing and attended. Use this test:

Replace and save if all of these are true	Keep a specialist tool (or a small license pool) if you need
You support only your own employees’ Intune-managed / Entra-registered Win / macOS / Android devices	To support external customers, partners, or vendors / unmanaged devices
Sessions are attended (the user is present)	Unattended access to Windows servers, kiosks, or always-on machines
UAC elevation is enough for admin tasks	Privileged access management, credential vaulting, or vendor-access governance
Audit metadata + Event Log meet your compliance needs	Mandatory full session recording for compliance
Intune already handles device management (RMM)	A bundled RMM / patching / ticketing suite inside the support tool

Budget logic. If the company already licenses (or is moving to) the Intune Suite, Remote Help is effectively included, so retiring a per-agent LogMeIn Resolve contract (roughly US$29–94 per agent per month) or an enterprise BeyondTrust concurrent-license agreement becomes a direct, recurring saving with no loss of capability for internal attended support. Where only a minority of cases need unattended, vendor, recording, or PAM features, the common pattern is to move the bulk of the help desk to Remote Help and keep a much smaller pool of the incumbent license for just those scenarios, capturing most of the saving while preserving the specialist capability.

Recommended approach

Run a 30–60 day pilot in which the help desk uses Remote Help for all internally attended sessions.

Track what (if anything) still genuinely requires the incumbent, unattended, vendor access, recording, or PAM.

At the next renewal, right-size or cancel the third-party contract based on that residual, keeping only the licenses that those edge cases justify.

5. Security Model

Remote Help was designed to deliver remote assistance with enterprise security controls in place. The protections fall into four layers: identity, authorization, transport, and accountability.

5.1 Identity — both ends authenticate to the tenant

• Helper and sharer must each sign in with a Microsoft Entra ID account from the organization, the trust for the session is established through Entra ID.

• Hybrid identity: user accounts are mastered in on-premises Active Directory and synchronized to Entra ID by Entra Connect, corporate devices are Microsoft Entra hybrid joined (domain-joined and registered with Entra).

• Federated authentication: the Entra ID sign-in for Remote Help is federated to Okta, which performs primary authentication against on-prem AD. Entra ID issues the token and remains the identity the Remote Help service trusts. Remote Help integrates with Entra ID, not directly with Okta.

• Cross-tenant assistance is not possible, a helper cannot assist a user outside the tenant, which structurally prevents an external party from connecting in.

5.2 Authorization — RBAC and Conditional Access

• Intune RBAC determines who can help and the maximum capability of each session (view, full control, elevation). Detail in Section 6.

• Conditional Access can be applied to the Remote Assistance Service so helpers must satisfy, for example, MFA and/or a compliant device before they can provide help. (CA for Remote Help is supported on Windows and macOS.)

• With Okta federation, MFA is commonly enforced at Okta, Entra Conditional Access still applies and can additionally require a hybrid-joined or compliant device for helpers.

• Least privilege Microsoft’s guidance is to grant only the minimum Remote Help permission each tier needs and to use custom roles where the built-in role is too broad.

5.3 Transport — encryption in transit

• The remote session uses Remote Desktop Protocol (RDP) to the Remote Assistance Service at remotehelp.microsoft.com, encrypted with TLS 1.2.

• Real-time media (screen/audio/video signaling) is carried over Azure Communication Services, which is itself encrypted.

• Because the session is end-to-application encrypted, the Remote Help domains must be excluded from any SSL/TLS inspection — inspecting them breaks the connection. This is the central Zscaler consideration (Section 8).

5.4 Accountability and privacy

• Sessions are consensual and visibly indicated on the user’s screen, no session recordings are stored in the service.

• Microsoft cannot access a session or view any actions or keystrokes that occur in it.

• Session details are written to Windows Event Logs on both helper and sharer devices, and to Intune session reports / audit logs (who helped whom, on what device, for how long).

• Microsoft retains only minimal session health metadata (start/end time, participants, features used) for 30 days, and auditing is reduced for unenrolled devices.

Security recommendations to adopt at rollout

Require MFA and a compliant device for helper accounts via Conditional Access.

Default tier-1 to view-only, reserve full control and elevation for tier-2+ via separate custom roles.

Keep “Allow Remote Help to unenrolled devices” OFF unless a specific need exists (it reduces audit fidelity and compliance visibility).

Monitor Entra sign-in and Intune audit logs for unusual helper activity, and remove leavers from Remote Help roles as part of offboarding.

6. Role-Based Access Control (RBAC)

Remote Help uses Intune RBAC to set the level of access a helper is allowed. A user needs a combination of the Remote Tasks – Offer remote assistance permission, the Remote Assistance Connector, Read permission, and at least one Remote Help capability permission, granted through a role assignment scoped to the users/devices they support.

6.1 Available permissions

Permission	Grants
Remote Help – View screen	View the sharer’s screen without taking control.
Remote Help – Take full control	Take full control of the sharer’s device.
Remote Help – Elevation	Interact with Windows UAC prompts during a session.
Remote Help – Unattended	Connect to Android dedicated devices without per-session acceptance.
Remote Tasks – Offer remote assistance	Offer remote assistance to users (required).
Remote Assistance Connector – Read	See whether Remote Help is configured for the tenant when starting a session (required).

6.2 Built-in roles that include Remote Help

• Help Desk Operator — includes View screen, Take full control, Elevation, Unattended, Offer remote assistance, and Connector – Read (i.e., the full set).

• School Administrator — includes View screen, Take full control, Elevation, Offer remote assistance, and Connector – Read.

6.3 Suggested tiering for the environment

Support tier		Recommended permissions	Rationale
Tier 1 (service desk)		View screen + Offer remote assistance + Connector Read	Guide users without controlling the device, lowest privacy/risk footprint.
Tier 2 (desktop support)		Add Take full control + Elevation	Hands-on remediation including admin-gated tasks.
Tier 3 / specialized		Full set, tightly scoped groups, CA-gated	Reserve elevation and broad scope for a small, monitored group.
	Scoping note The All Devices scope does not include unenrolled devices. If you support unenrolled devices, assign helpers using a user scope group. If a sharer or their device is outside a helper’s scope, that helper cannot assist them.

7. Network Requirements — Ports and URLs

Both the helper and the sharer must reach a defined set of Microsoft endpoints. Remote Help communicates over TCP 443 (HTTPS) for the session/signaling, and the underlying Azure Communication Services media uses UDP 3478–3481 (with TCP 443 fallback). There are no inbound ports.

Two endpoint sets must both be allowed

1. The Remote Help feature endpoints (and their web-pubsub dependency).

2. The Azure Communication Services media/signaling endpoints. Microsoft explicitly notes that Remote Help requires the ACS network requirements to be configured in addition to the Remote Help endpoints.

7.1 Remote Help feature endpoints (TCP 443)

Allow the following FQDNs outbound on TCP 443:

Remote Help FQDN	Port
*.support.services.microsoft.com	TCP 443
remoteassistance.support.services.microsoft.com	TCP 443
remotehelp.microsoft.com	TCP 443
remoteassistanceprodacs.communication.azure.com	TCP 443
remoteassistanceprodacseu.communication.azure.com (EU customers)	TCP 443
teams.microsoft.com	TCP 443
edge.skype.com	TCP 443
edge.microsoft.com	TCP 443
aadcdn.msftauth.net	TCP 443
aadcdn.msauth.net	TCP 443
alcdn.msauth.net	TCP 443
wcpstatic.microsoft.com	TCP 443
*.aria.microsoft.com	TCP 443
browser.pipe.aria.microsoft.com	TCP 443
*.events.data.microsoft.com	TCP 443
v10c.events.data.microsoft.com	TCP 443
*.monitor.azure.com	TCP 443
js.monitor.azure.com	TCP 443
*.trouter.communication.microsoft.com	TCP 443
*.trouter.teams.microsoft.com	TCP 443
*.trouter.communications.svc.cloud.microsoft (rolling out 2026, regional go-amer/go-eu/go-apac variants)	TCP 443
api.flightproxy.skype.com	TCP 443
ecs.communication.microsoft.com	TCP 443

Web-pubsub dependency (TCP 443)

Dependency FQDN	Port
*.webpubsub.azure.com	TCP 443
AMSUA0101-RemoteAssistService-pubsub.webpubsub.azure.com	TCP 443

7.2 Azure Communication Services — media and signaling

Remote Help’s real-time media rides on Azure Communication Services. This is the part most often missed behind a proxy, because it needs UDP, not just HTTPS:

Category	Destination	Ports
Media traffic	20.202.0.0/16 (ACS media processor / TURN service)	UDP 3478–3481, TCP 443
Signaling / telemetry/registration	.skype.com, .microsoft.com, .azure.net, .azure.com, *.office.com	TCP 443, 80

External DNS for these endpoints must resolve, and the firewall must not change the NAT mapping for UDP (maintain UDP session persistence), or media quality will degrade.

7.3 Windows Firewall (host) if locally restricted

Where host firewall rules are restrictive, allow these Remote Help executables:

• C:\Program Files\Remote help\RemoteHelp.exe

• C:\Program Files\Remote help\RHService.exe

• C:\Program Files\Remote help\RemoteHelpRDP.exe

7.4 GCC note

If any tenant is GCC, the endpoints differ (e.g., gcc.remotehelp.microsoft.com, gcc.relay.remotehelp.microsoft.com, remoteassistanceweb-gcc.usgov.communication.azure.us, *.gov.teams.microsoft.us). Remote Help is not supported on GCC High or DoD tenants. This brief assumes a commercial cloud.

8. Zscaler Configuration

Because traffic egresses through Zscaler, two things must be true for Remote Help to work reliably: the Microsoft endpoints must be reachable and not TLS-inspected, and the real-time UDP media must be allowed to flow (ideally bypassing the proxy). The steps below map the Section 7 endpoints onto Zscaler Internet Access (ZIA) and Zscaler Client Connector (ZCC).

Why this matters

Remote Help sessions are RDP-over-TLS 1.2 and ACS-encrypted media. SSL inspection terminates and re-signs TLS, which breaks these connections. Microsoft states the Remote Help domains should be excluded from SSL inspection. ACS media additionally needs UDP 3478–3481, which a forward proxy does not carry, that traffic should bypass the proxy and egress directly.

8.1 Step 1: Create a custom URL category

1. In the ZIA Admin Portal, go to Administration > URL Categories and create a custom category, for example “Microsoft Remote Help”.

2. Add the Remote Help feature FQDNs and the web-pubsub dependency from Section 7.1 (wildcards where listed).

3. Add the Azure Communication Services signaling/registration domains from Section 7.2 (*.skype.com, *.microsoft.com, *.azure.net, *.azure.com, *.office.com) or rely on the Microsoft 365 recommended one-click bypass for these shared domains if already in place.

4. Add your Okta federation domains (your-tenant.okta.com, login.okta.com, *.oktacdn.com) so the sign-in redirect to Okta is allowed and not broken by SSL inspection.

8.2 Step 2 — Exclude from SSL inspection (do-not-inspect)

1. Go to Policy > SSL Inspection.

2. Add a Do-Not-Inspect rule targeting the “Microsoft Remote Help” custom URL category created above.

3. Ensure this rule is ordered above any broad inspect-all rule so it takes effect.

Rationale: These endpoints are end-to-application encrypted, inspecting them breaks the RDP/ACS connection. This mirrors Microsoft’s guidance that *.manage.microsoft.com, *.dm.microsoft.com, and the Remote Help domains must not be SSL-inspected.

8.3 Step 3 Allow the traffic in URL & firewall policy

1. In Policy > URL & Cloud App Control, ensure the custom category is Allowed for the relevant groups (helpers and all potential sharers).

2. If authentication is enforced at the proxy, add these destinations to the authentication-bypass / exemption list so the service-to-service calls are not challenged.

3. In ZIA Firewall Control, allow outbound UDP 3478–3481 and TCP 443 to the ACS media range 20.202.0.0/16 (Section 7.2).

8.4 Step 4 Bypass the proxy for real-time media (recommended)

A forward proxy is not designed to carry real-time UDP media. For the best call/media quality, Microsoft recommends bypassing the proxy/VPN for this traffic (the same pattern used for Teams). Implement a direct path for the ACS media:

• PAC file / forwarding bypass add the ACS media range 20.202.0.0/16 and the Remote Help media FQDNs so they egress direct (DIRECT in PAC, or proxy-bypass on the forwarding profile) rather than tunneling through the proxy.

• Preserve UDP & NAT persistence — do not let the firewall re-map UDP ports mid-session.

8.5 Step 5 Zscaler Client Connector (remote users)

For off-network users running Zscaler Client Connector, apply the same exclusions on the forwarding/app profile so the endpoint behaves like an on-net device:

• Add the Remote Help + ACS destinations to the ZCC forwarding-profile bypass (or app bypass), so UDP media is not forced through ZIA.

• Confirm the Do-Not-Inspect rule applies to ZCC-forwarded traffic as well as on-net GRE/IPSec traffic.

8.6 Step 6 Validate

• Run Microsoft’s connectivity test from a managed device: .\Test-IntuneAFDConnectivity.ps1. This is a Microsoft Script to check the connectivity (checks DNS, TCP 80/443, and HTTPS reachability to Intune/AFD).

• Initiate a pilot Remote Help session on-net and via ZCC, confirm full control, elevation, and that the media connects (no TLS errors, no dropped session).

• If sessions are established but media is poor/drops, revisit the UDP allow + media bypass (Steps 3–4).

Zscaler control	Action for Remote Help
SSL Inspection	Do-Not-Inspect the Remote Help custom URL category.
URL & Cloud App Control	Allow the custom category for helper and sharer groups.
Firewall Control	Allow UDP 3478–3481 + TCP 443 to 20.202.0.0/16.
Authentication	Exempt the service endpoints from auth challenges if proxy auth is enforced.
PAC / forwarding bypass	Send ACS media (20.202.0.0/16) DIRECT for quality.
Client Connector	Mirror bypass + do-not-inspect on the forwarding profile.

9. Connection and Session Flow

The diagram below traces a Remote Help session from initiation to teardown. It shows where each step happens — on the endpoints, at the Zscaler egress, or in the Microsoft cloud — and the protocols involved. Read it left-to-right, top-to-bottom (1→9).

Title: Remote Help session flow - Description: Nine-step connection flow from session start to end across endpoints, the Zscaler egress, and the Microsoft cloud.

Figure 1. Remote Help session lifecycle and connection flow.

9.1 Step-by-step

1. Initiate — the Helper opens Remote Help (or uses Remote Launch from the Intune admin center), the Sharer opens the app on the endpoint.

2. Secure egress — traffic leaves via Zscaler: outbound only, TCP 443 set to do-not-inspect, UDP 3478–3481 media bypassed.

3. Authenticate — sign-in is federated to Okta, which performs primary authentication against on-prem AD, Entra ID issues the token. MFA is enforced at Okta, and Entra Conditional Access can additionally require a hybrid-joined / compliant device.

4. Authorize — Intune RBAC confirms the helper’s scope and capability (view / full control / elevation).

5. Broker & match — the Remote Assistance Service pairs the two parties, Entra ID establishes the session trust.

6. Consent & mode — the Sharer sees any compliance warning, accepts, and the agreed session mode is set.

7. Connect — RDP over TLS 1.2 to the Remote Assistance Service, screen media flows over Azure Communication Services.

8. Active session — view / control / elevation / chat as permitted, with a visible on-screen indicator, events write to the Windows Event Log.

9. End & audit — either party ends the session, details appear in Intune session reports and audit logs (~30-day metadata retention).

10. Deployment Overview

The following is the end-to-end enablement path. Detailed click-paths are in Microsoft’s deploy guide (see References).

10.1 Prerequisites and licensing

• Active Intune subscription, with devices registered in Microsoft Entra ID (Intune-enrolled devices must be Entra-registered).

• Hybrid identity in place: Entra Connect syncing on-prem AD users to Entra ID, corporate devices Entra hybrid joined and Intune-enrolled (hybrid join satisfies the Entra-registration requirement).

• Okta federation configured for the Entra tenant, so the helper and sharer (Entra-synced) accounts authenticate via Okta.

• A Remote Help add-on license or Intune Suite license for every helper and sharer who will use the service.

• Supported platform/OS and a supported browser for any web-app sharers.

• Network endpoints allowed and Zscaler configured per Sections 7–8.

10.2 Enable the tenant

1. Intune admin center > Tenant administration > Remote Help > Settings.

2. Set Enable Remote Help = Enabled. (Leave “Allow Remote Help to unenrolled devices” Disabled unless required, optionally set Disable chat.)

3. Save. New/trial licenses can take 30 minutes to 8 hours to activate.

10.3 Configure RBAC

1. Assign the built-in Help Desk Operator role, or create custom roles per the tiering in Section 6.3, scoped to the right groups.

10.4 Deploy the app

• Recommended: deploy via the Enterprise App Catalog (Intune Suite) for simplest packaging and updates.

• Alternative: package remotehelpinstaller.exe as a Win32 (.intunewin) app. Install command remotehelpinstaller.exe /quiet acceptTerms=1, assign to device groups.

• Remote Help auto-updates by default and requires the Microsoft Edge WebView2 Runtime (installed automatically if absent). Latest version at time of writing: 5.1.1998.0.

10.5 Configure Conditional Access (recommended)

Provision the Remote Assistance Service principal, then target it in a CA policy. Because sign-in is federated to Okta, decide whether MFA is satisfied by Okta (federated) or enforced by Entra, the policy can additionally require a hybrid-joined / compliant device for helpers:

• Install-Module Microsoft.Graph -Scope CurrentUser

• Connect-MgGraph -Scopes "Application.ReadWrite.All"

• New-MgServicePrincipal -AppId "1dee7b72-b80d-4e56-933d-8b6b04f9a3e2"

• Then build a Conditional Access policy targeting the RemoteAssistanceService app (AppId 1dee7b72-b80d-4e56-933d-8b6b04f9a3e2).

10.6 Pilot, then roll out

• Pilot with IT/a small department, validate on-net and remote (ZCC) sessions, full control, elevation, and media quality.

• Brief the help desk (how to start/launch sessions, confirm user consent, the cross-tenant limitation) and end users (what to expect, that only authorized IT can connect).

• Expand in phases once stable, keep apps current and monitor audit/sign-in logs.

11. Decisions to Confirm Before Rollout

#	Decision	Recommendation
1	Unenrolled device support on/off?	Off by default, enable only with a clear need and a restricted helper role.
2	Chat enabled or disabled?	Enable unless policy requires otherwise.
3	RBAC tiering model	Adopt the tier-1 view-only / tier-2 full-control split (Section 6.3).
4	Conditional Access for helpers	Require MFA + compliant device.
5	App delivery method	Enterprise App Catalog if on Intune Suite, otherwise Win32.
6	Zscaler ownership & change window	Assign SSL-inspection exclusion + firewall/PAC changes to the network team, validate in pilot.
7	Tenant region / cloud	Confirm NA vs EU/APAC endpoints (commercial, non-GCC, hybrid AD + Okta confirmed).