Skip to main content
You arrived here from the “Discovery Sensor (On-Demand Scan)” card, which shows three console marks. Only one of them is live, and this section says which, so the card’s marks and this page cannot tell you different things.The two unavailable consoles appear on the card and in the picker, but cannot be selected.
Which path do you want? VisIQ delivers one payload — the signed visiq-discovery binary — two ways, and the difference decides what you get.
  • Discovery Sensor (Standalone): the binary installed persistently as a managed app through your own app catalog. Self-healing, re-runs on a schedule, carries the Context Firewall’s host proxy, and is the recommended path. Your MDM admin installs it.
  • Discovery Sensor (On-Demand Scan) (this page): Intune runs the binary once and it removes itself. It discovers only: nothing is persistently installed, so there is no self-healing, no scheduled re-scan and no firewall proxy. VisIQ pushes it for you.
Mnemonic: the sensor stays, the scan vanishes. Both can be driven from Intune, which is exactly why they are easy to confuse: the question is not which console you use, it is whether anything remains on the host afterwards.

​
Before you start

  • Intune with Remediations (deviceHealthScripts). Remediations needs a Windows licence that Microsoft lists on its Remediations page; 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.
  • 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 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.
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:
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.
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.

​
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 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:
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.

​
When to pick which

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