Supporting Intune-Only Laptops: Remote Help, Diagnostics and Slow Devices in One Chat ​

September 18, 2026 · InfraScout Team

If your Windows laptops are joined to Entra ID and managed only by Intune, you can end up with a verified Microsoft Remote Help rollout, a log-based diagnosis of why a helper's client fails, and before-and-after performance numbers for a user's slow laptop, all from one conversation. This post walks through that pattern. It is a composite of a common scenario rather than a single customer story, and it includes the Remote Help checklist you can reuse whether or not you use InfraScout.

The problem: no domain, no VPN, no PsExec ​

Traditional desktop support relies on the domain. PsExec, WinRM with Kerberos, remote registry and admin shares all assume a domain trust and a network path to the device. A cloud-only laptop on a home network has neither, so the familiar tools don't work.

That leaves the tools that are native to Intune, such as Remote Help, remote actions and device reports, plus anything already running on the device. The InfraScout Windows agent keeps an outbound connection to the server, so the AI can run read-only diagnostics on the laptop over mTLS without inbound ports or a VPN. It can combine that with what Intune, Entra ID and Defender know about the same device.

A conversation like this usually starts with a short prompt:

text
Our Windows laptops are Entra-joined and managed only by Intune. What are our
options for remote support, are we already licensed for Remote Help, and what
would a correct rollout look like? Check the tenant before recommending anything.

Rolling out Remote Help correctly ​

The AI starts with what you already have. It checks its memory of your environment, the subscribed licenses and the Intune configuration. A common result is that Remote Help is already licensed but nobody uses it. From there it compares enterprise apps, detected apps, assigned mobile apps and configuration profiles with a correct rollout, and saves the gaps as a finding.

Some steps only exist in the Intune admin center: turning on the tenant setting, creating the helper group and assigning the role. The AI gives these to you as operator steps, and after you finish them it checks the group membership through Graph. The checklist that comes out of this is the part you can reuse:

  1. License both sides. The helper and the person sharing their screen each need a Remote Help license.
  2. Turn on Remote Help for the tenant in the Intune admin center.
  3. Assign a role. Helpers need an Intune role that includes the Remote Help permissions, and the role assignment needs a scope that covers the target devices.
  4. Use a dedicated helper group as the role assignment's members, and check which account each helper actually signs in with.
  5. Deploy the client as the Win32 package Microsoft publishes, assigned to both the helpers' and the users' devices.
  6. Enable Remote Desktop on the target with a Settings Catalog profile if you want unattended control. The operating system setting has to be on; opening the firewall alone isn't enough.
  7. Start unattended sessions from the device page in the Intune admin center. The local app doesn't offer them.

TIP

Remote Help looks a lot like Quick Assist by design, so it's easy to mix them up on a device. The Intune detected-apps list tells them apart. That list covers the whole tenant, though, so use the agent to check what is actually installed on a specific laptop.

When the AI changes its own conclusion ​

Partway through a rollout like this, you may suspect that what is installed on the helpers' machines is Quick Assist rather than Remote Help. The AI checks the detected-app data, confirms they are different apps and looks up the supported deployment method. It also goes back to one of its own earlier conclusions. It had called Remote Help "inactive" because the Remote Assistance Service service principal was missing from the tenant. That was a poor signal. You only create that service principal yourself when you want to target Remote Help in Conditional Access, so its absence says nothing about whether the feature is on. The AI says so, withdraws the conclusion and updates the saved finding.

That is a strength: the record you hand to a reviewer shows what is true now, not what someone thought on the first pass.

Diagnosing a failing helper client ​

The first real session often fails with a vague error saying the service isn't working. The AI rules out a Microsoft 365 service incident first. Then it opens an InfraScout session on the helper's laptop and uses only read-only tools: PowerShell queries, event logs and a network reachability test.

In this scenario, the Remote Help operational log is full of the same "element not found" error, repeated over and over and coming from the embedded remote desktop component. The client binaries for that component are older than the operating system build, and a reboot is pending. You then work through a set of possible causes together: the helper account isn't licensed, the device is out of scope, the wrong admin account is signed in, or the helper and the target are the same machine. The AI checks each one against Graph data and reads the log again after every retest. One cause holds up: the helper accounts are missing a license. People who have several admin identities often have a license on only one of them.

Some things the AI can't read, such as the effective scope of an Intune role assignment. When that happens, it asks you to look it up rather than guessing. It also asks before it reboots anything. The next step, a reboot to finish the pending component update, goes back to you to schedule.

Sitting down virtually at a slow laptop ​

The same pattern works for everyday complaints. Take a user whose screen sharing in Teams stutters. The AI collects performance counter samples and process lists from the laptop and finds that the CPU stays saturated for a long time after boot. On a laptop with few cores, security scanning, search indexing and collaboration apps all compete at the same moment. A tightly scoped Defender exclusion is one option to weigh — but weakening endpoint protection needs evidence that it is the cause and a decision made against your management policy, not just a spike in CPU. Whether a local exclusion would even take effect depends on that policy: managed exclusions can be tamper-protected, and DisableLocalAdminMerge makes locally added exclusions ineffective, so the effective policy has to be checked first. In this scenario the user asks for a narrowly scoped exclusion on that one machine, and the AI adds it there only, additively, and verifies it.

When the second measurement shows no improvement, the AI says so plainly, and the exclusion is a change to reconsider rather than keep.

A newly imaged laptop that updates slowly is a similar case. The AI compares the device's MDM policy registry keys under PolicyManager with the update ring settings you describe, which confirms whether the policy actually reached the device. A policy value can look alarming without matching how the device behaves. In this scenario, the AI withdraws a high-severity finding of its own on that basis. The feature update simply hasn't been offered yet, because feature updates roll out in waves. It also finds that only quick scans are scheduled and no full scans.

What Intune can and can't tell you ​

Intune is good at showing policy assignment, compliance, a device's primary user and a tenant-wide view of detected apps. It can't tell you what is running on a laptop right now, what its event logs say, or which apps are installed on that one machine. That's what the agent adds. The useful diagnosis usually comes from combining the two.

Governance throughout ​

Every investigation gets its own session, which is submitted for review at the end. The AI uses read-only PowerShell first. It makes changes only with explicit consent, on a named machine, and verifies them afterwards. It asks before any reboot or update. Actions that only exist in a console are handed to you as operator steps, and findings are corrected openly rather than silently overwritten. The main thread in a scenario like this runs on and off for about ten days, mixing research, console work and agent diagnostics. The smaller investigations take 30 to 90 minutes each.

Next steps ​

To try this pattern, connect your tenant and install the agent on a few laptops.