> ## Documentation Index
> Fetch the complete documentation index at: https://docs.visiqlabs.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Microsoft Intune On-Demand Scan

> Run the VisIQ discovery sensor once across your Intune-managed Windows endpoints as an On-Demand Scan — nothing stays installed on the host.

<Note>
  **Which path do you want?** VisIQ delivers **one** payload — the signed `visiq-discovery`
  binary — two ways, and the difference decides what you get.

  * **[Deployed Sensor](/discovery/deployed-sensor)** — the binary installed **persistently**
    as a managed app through your own app catalog. Self-healing, re-runs on a schedule, and
    is the **recommended** path. Your MDM admin installs it.
  * **On-Demand Scan** (this page) — Intune runs the binary **once** and it removes itself.
    Nothing is persistently installed. VisIQ pushes it for you.

  Mnemonic: the **sensor stays**, the **scan vanishes**. Both are "Intune", which is exactly
  why they are easy to confuse.
</Note>

## Before you start

* **Intune with Remediations** (`deviceHealthScripts`). Remediations is gated on
  Windows Enterprise E3/E5, Education A3/A5, or Windows 365 Enterprise — it is **not**
  part of every Intune plan. Confirm it before you begin; without it VisIQ has no channel
  to push the scan.
* **Windows endpoints only.** Intune Remediations do not run on Linux, and macOS is not
  covered by this path. For those, use the [Deployed Sensor](/discovery/deployed-sensor).
* **A VisIQ harness key** (**Settings → Harness Keys**) so the scan can report findings
  back to your Discover dashboard.
* **An Entra admin who can grant application permissions** — see
  [Consent](#consent-the-one-step-that-needs-an-admin) below. This is the step most setups
  stall on.

***

## How an On-Demand Scan works

1. You connect your Intune tenant on the **Microsoft Intune** card under
   **Integration → Connectors → Discover**, and choose which device groups to scan.
2. VisIQ creates a remediation script in your Intune tenant through Microsoft Graph, and
   Intune's management extension runs it on the selected devices.
3. The script downloads the signed `visiq-discovery` binary, runs it **once**, reports its
   findings to your VisIQ tenant, and deletes itself.
4. VisIQ removes the remediation from your tenant when the run reaches a terminal state,
   so nothing accumulates in your Intune console.

What it finds: agentic frameworks (npm/pip), MCP servers, local models, and AI tools on
each host — the inventory that populates **Discover**.

***

## Consent: the one step that needs an admin

The connector app initially holds only `DeviceManagementManagedDevices.Read.All`, which is
**read** access. Creating a remediation needs an application permission it does not have
yet:

```
DeviceManagementScripts.ReadWrite.All
```

An Entra administrator must grant **and admin-consent** that permission for the VisIQ
connector app. Until they do, Graph answers the create call with
`403 Authorization_RequestDenied`, and the connector reports the run as gated rather than
failing silently.

<Warning>
  This is a deliberate gate, not a bug. A tool that can write remediation scripts into your
  tenant can run code on every managed device, so VisIQ asks for that scope separately from
  read access and only when you choose this delivery path.
</Warning>

***

## Windows SmartScreen and ASR, stated plainly

The binary **is** code-signed (DigiCert OV, `VISIQ LABS LLC`). Signing is necessary, but on
Windows it is **not sufficient on its own**:

* **SmartScreen reputation is earned, not granted.** A certificate issued recently has no
  reputation history, so early runs of a freshly-signed binary can still raise a SmartScreen
  prompt until enough clean executions accrue.
* **ASR's "block executables unless they meet a prevalence, age, or trusted-list criterion"**
  rule judges on prevalence too, and a new binary has none.

Neither is specific to VisIQ — it is how Windows treats any newly-signed executable. Two
ways through it:

1. **Allowlist the binary** as a managed installer / trusted publisher in your own policy.
   This is the durable answer and the one enterprise deployments use.
2. **Use the [Deployed Sensor](/discovery/deployed-sensor) instead.** Installed through your
   app catalog it inherits managed-installer trust, which is the main reason it is the
   recommended path.

If a scan reports no findings from hosts you know are in scope, check SmartScreen/ASR
blocks before assuming the scan itself failed.

***

## Verifying a run

On the connector card, each scan shows the devices targeted and the state Intune reported.
A run that never reaches a device is almost always one of three things, in this order:

| Symptom                                      | Most likely cause                                                                                                |
| -------------------------------------------- | ---------------------------------------------------------------------------------------------------------------- |
| The run is refused before any device sees it | `DeviceManagementScripts.ReadWrite.All` not consented — see [Consent](#consent-the-one-step-that-needs-an-admin) |
| Devices are targeted but report nothing      | SmartScreen / ASR blocked the binary on the host                                                                 |
| Some devices never run it                    | Intune's management extension re-evaluates Remediations on an hourly-ish cadence — a scan is not instantaneous   |

<Note>
  **Cadence, so you are not surprised on a call.** Intune decides when a remediation runs.
  The management extension evaluates on roughly an hourly cycle, so an On-Demand Scan is
  "once, soon" rather than "once, now". If you need a result at a predictable moment, the
  Deployed Sensor is the better fit.
</Note>

***

## When to pick which

|                     | Deployed Sensor                      | On-Demand Scan                                              |
| ------------------- | ------------------------------------ | ----------------------------------------------------------- |
| **Persistence**     | Installed and self-healing           | Runs once, removes itself                                   |
| **Who installs**    | Your MDM admin, via the app catalog  | VisIQ pushes it for you                                     |
| **Platforms**       | Windows, macOS, Linux                | Windows only                                                |
| **SmartScreen/ASR** | Inherits managed-installer trust     | Needs allowlisting until reputation accrues                 |
| **Timing**          | Scheduled, recurring                 | Once, on Intune's cadence                                   |
| **Best for**        | Ongoing inventory of a managed fleet | A one-off look at a population you don't want to install on |

For continuous discovery, use the **Deployed Sensor**. Use an On-Demand Scan when you want a
single snapshot without installing anything.