Intune Remote Help not working usually comes down to one of five gates, and only one of them is a fault. The other four are licensing, a tenant switch, helper permissions, and the boundary of which devices and tenants Remote Help will cross, all of them documented and all of them easy to miss. The errors the app shows rarely name the gate, which is why the threads ranking for this problem are mostly unanswered. Below is each gate with Microsoft’s own wording, the order I would check them in, and the two places Microsoft’s documentation currently contradicts itself. It slots into the wider Intune troubleshooting order.
Both people need a licence, not just the helper
This is the cause that surprises people most. Microsoft’s planning guide requires “A Remote Help license for everyone targeted to use the service”, and spells out that this means “both helpers (IT support workers) and sharers (users)”. An end user without a licence cannot be helped, however the helper is configured.
It has become more confusing since July 2026, when Microsoft brought Remote Help into Microsoft 365 E3 and E5, a change covered with the other Intune Suite moves in Endpoint Privilege Management cost. The planning guide has not caught up. At the time of writing it still says the feature “requires a subscription in addition to Microsoft Intune Plan 1 or Plan 2” and does not mention E3 or E5 at all. If you hold E3 or E5 and the page is telling you to buy an add-on, the page is out of date, not your licensing.
Activation is the second licensing trap, and the documentation disagrees with itself about it. The deployment guide says “New licenses or trial licenses could take a while to become active, from anywhere between 30 minutes to 8 hours.” The troubleshooting guide says “It can take up to 30 minutes (or a few hours in some cases) after assigning licenses for the service to activate.” I would plan around the longer figure. A same-day test that fails an hour after licensing is not evidence of anything yet.
The tenant switch, and unenrolled devices
Remote Help has to be enabled at tenant level, under Tenant administration, Remote Help, Settings. The deployment guide warns that the switch can lag behind reality: “New Remote Help sessions might continue to indicate Remote Help isn’t enabled for the tenant, even if Remote Help is enabled.” Another reason not to judge a fresh setup on the first attempt.
The setting that catches more people is the one for unenrolled devices. Helping a device that is not enrolled in Intune requires Allow Remote Help to unenrolled devices, and the deployment guide is explicit: “By default, this setting is disabled.” A personal laptop, or a device mid-way through enrolment, will fail until it is switched on.
Turning it on is not the end of it. The planning guide notes that the All Devices scope group “doesn’t include unenrolled devices” and says to use a user scope group instead. A helper whose role is scoped to devices will still be unable to reach an unenrolled one. Scoping is its own subject, covered in Intune scope tags.
Helper permissions: two you will not think to add
The obvious Remote Help permissions are View screen, Take full control and Elevation. They are not enough. The planning guide’s note is the sentence to keep:
A person needs a combination of the Remote Tasks – Offer Remote Assistance permission, the Remote Assistance Connector – read permission, and at least one of the Remote Help permissions to provide help.
Remote Assistance Connector, Read is the one most often missing from custom roles. The guide explains why it matters: it is “Required to allow the user to see if Remote Help is configured for the tenant when starting a session.” Without it, a helper with full control rights can still be turned away at the start.
That said, there are Microsoft Q&A threads where the permissions error persists with every documented permission in place, and no answer in them resolves it. If you have checked the role, the scope and both licences, the remaining step is a support case rather than another permission.
Sign-in, tenants and Conditional Access
The troubleshooting guide states that “Both the helper and sharer must sign in with a Microsoft Entra account from your organization.” Two consequences follow. In one Microsoft Q&A thread, a sharer signed into Windows with a local account produced the “signed in with the wrong account” error; in another, the same error came from users with no Remote Help licence. And cross-tenant help does not exist: “You can’t establish a Remote Help session from one tenant to a different tenant.” An MSP supporting several customers needs a helper identity in each.
Conditional Access is the gate that looks least like Remote Help. The backend is a separate application, Remote Assistance Service, with the app ID 1dee7b72-b80d-4e56-933d-8b6b04f9a3e2, and the deployment guide has you create its service principal before you can target it in a policy. A policy that blocks or challenges that app blocks sessions. Two limits are worth knowing: the planning guide says “Microsoft Entra Conditional Access policies for Remote Help are supported only on Windows and macOS”, and the Remote Help hub notes that policies do not apply to unattended access. When a session fails at sign-in, check the Entra sign-in logs for that app before anything else.
The network path
The planning guide states that Remote Help “communicates over port 443 (https) and connects to the Remote Assistance Service at https://remotehelp.microsoft.com”, with the full list in the Intune network endpoints reference. The planning guide adds the sentence that explains most corporate-network failures:
If your proxy servers are using SSL inspection, the domains listed for Remote Help should be excluded to avoid issues.
A session that works from home and fails in the office is the pattern I would expect from this.
Windows-side faults
Once the gates above are clear, the remaining failures are on the device, and the troubleshooting guide documents them well.
- WebView2. Remote Help depends on the Microsoft Edge WebView2 runtime, and the guide lists three error codes for it: 1001, Remote Help failed to initialise one of its internal components; 1002, “Remote Help failed to load WebView2.”; and 1003, Remote Help failed to install WebView2.
- The Intune Management Service. The guide states that notifications for a remotely triggered session “fail if the Microsoft Intune Management Service isn’t running”, and that it takes a short while to start after a restart. Check it in the Services console alongside the Intune management extension.
- New enrolments. “For newly enrolled devices, there’s a 1 hour delay before the user’s device begins receiving notifications when a helper initiates a session.” Testing on a device enrolled this morning will fail.
- The web app. For sharers using the web app, the guide notes that “SSO must be enabled for the tenant to use the Remote Help web app.”
Operational logs are under Event Viewer, Application and Services, Microsoft, Windows, RemoteHelp, which is the place to start when a session drops rather than failing to start.
Intune Remote Help not working: the order I would check
- Confirm both the helper and the sharer hold a Remote Help entitlement, and that it was assigned more than eight hours ago.
- Confirm the tenant switch is on and, if the device is not enrolled, that unenrolled devices are allowed.
- Confirm the helper’s role includes Offer remote assistance, Remote Assistance Connector Read, and at least one Remote Help permission, with a scope that actually contains the target.
- Confirm both people are signed in with Entra accounts from your tenant.
- Check the sign-in logs for the Remote Assistance Service app for a Conditional Access failure.
- Check for SSL inspection on the network path.
- Only then look at the device: WebView2, the management extension, enrolment age, and the RemoteHelp event log.
What I would do differently
If I had Intune Remote Help not working because of permissions, I would expect a custom role to be the cause, because the two non-obvious permissions are exactly what an existing helpdesk role lacks. So I would build a dedicated Remote Help role rather than extending an old one. I would license and switch on the tenant a day before anyone tests, so that activation lag is not mistaken for a fault. And I would put the Remote Assistance Service app into the Conditional Access review deliberately, rather than discovering it through a blocked session.
I have not run Remote Help in production. My tenant is a lab with no enrolled devices, so everything here is what Microsoft documents and what admins report, not something I have measured. Where the documentation contradicts itself, on activation time and on the licensing route, I have quoted both sides rather than guess which is current.
Primary sources, verified on the date below: Planning for Remote Help with Microsoft Intune, Deploying Remote Help with Microsoft Intune, and Troubleshoot and Monitor Remote Help.
Last verified: 9 October 2026. I have not run this in production; my tenant is a lab with no enrolled devices, so everything above is what the documentation states, what practitioners report, and where I would expect it to bite.
