visiq-discovery binary installed to stay: it lives on the host, re-scans on a schedule, and reports what it finds to your Discover dashboard. It is the recommended way to run Discovery — on a single machine or across a managed fleet.
It is distinct from an On-Demand Scan, which runs the same binary once through a device-management tool’s own execution channel and leaves nothing installed. The mnemonic: the sensor stays, the scan vanishes.
Before you start
- A harness key for your tenant (Settings → Harness Keys, or the Connectors page). The same key both authorizes the download and links the scan’s findings to your tenant. Without a key the sensor still runs, but only prints a local report.
- Administrative access on the target host — root on Linux and macOS, an elevated shell or SYSTEM on Windows.
Install on one host
The dashboard generates this command with your key already spliced in — copy it from Connectors → Discovery Agent rather than transcribing it. The shape is:Linux / macOS
xattr -d com.apple.quarantine visiq-discovery 2>/dev/null || true before chmod. A binary fetched with curl never carries the quarantine attribute, so Gatekeeper does not block it — the command strips the attribute defensively anyway, which matters if the file ever arrives by another route.
On Windows, use the PowerShell form the dashboard generates. It enables TLS 1.2 first (Windows PowerShell 5.1 on older images omits it and every HTTPS call fails before anything else), passes -UseBasicParsing (required under the SYSTEM/Server Core hosts that device-management tools run), verifies the digest with Get-FileHash, and runs Unblock-File before the scan.
Confirm it worked: ./visiq-discovery --version prints the sensor version, and a successful tenant report ends with visiq-discovery: reported to tenant (id …). If that line is absent the scan stayed local — the key did not reach the process.
Pick the right platform
The download path ends in a platform slug. Requesting one VisIQ does not publish returns400 with the valid list.
Roll it out to a fleet
The same command hardens into a script your device-management console pushes. It installs to a stable path, runs as root or SYSTEM, and is idempotent — safe to re-run on every check-in, because it downloads only when the binary is absent and re-scans every time. The dashboard carries console-specific walkthroughs for Microsoft Intune, Jamf Pro, Kandji, Group Policy, Configuration Manager, Workspace ONE, Ansible, JumpCloud and NinjaOne, each with the exact field to paste into and that console’s own pitfalls. Two rules hold across all of them:- Assign to a device group, never a user group. A root/SYSTEM install targeted at users silently no-ops.
- Exit 0 and stay idempotent. Consoles read a non-zero exit as a failed deployment and will retry.
Microsoft Intune, the persistent way
On Windows the robust path is a Win32 managed app — the app model is what makes the sensor persistent and self-healing, rather than a one-shot script:- Package it. Wrap
install.ps1anduninstall.ps1with the Microsoft Win32 Content Prep Tool (IntuneWinAppUtil.exe) into a single.intunewin. - Create the Win32 app under Apps → Windows → Add → Windows app (Win32). Install command
powershell.exe -ExecutionPolicy Bypass -File install.ps1, uninstall command the same withuninstall.ps1, and on the Program page set Install behavior = System. - Add a detection rule — for example the presence of the run-scan wrapper under
%ProgramData%\VisIQ\discovery, or the VisIQ Discovery Sensor scheduled task. Without one, Intune re-offers the installer in a roughly 24-hour loop. - Assign it to an Entra device security group as Required, starting with a pilot ring. The sensor installs on the next device check-in and self-heals on every scheduled scan after that.
.intunewin should be Authenticode-signed or managed-installer-trusted before a broad rollout — see the signing caveat above.
For macOS and Linux, Intune runs the bootstrap script instead, and the details differ per platform in ways that bite:
Both script forms must begin with a
#! shebang on macOS and Linux.
Intune’s Linux support is desktop-only and narrow — corporate-enrolled Ubuntu Desktop and RHEL on x86-64, GNOME, no servers and no ARM. For Linux servers or an agentic-AI fleet, install the Deployed Sensor directly with a configuration-management tool instead.
How the authenticated download works
The binary lives in a private bucket. There is no public download and no public GitHub release — the same pattern commercial endpoint vendors use.200 with a short-lived pre-signed URL as the plain-text body, plus these headers:
The heavy bytes come straight from object storage and are never proxied through VisIQ, and your
Authorization header is never forwarded to the storage host — the pre-signed URL is the only credential it sees.
The digest and the bytes cannot disagree. VisIQ resolves the channel pointer to a version, then reads both the checksum manifest and the binary from that immutable version prefix. A release published mid-download cannot leave you verifying one build and running another.
Two optional, validated query parameters let a self-updating agent fetch exactly what its policy targets:
?version=<version>— pin an immutable version.?channel=<channel>— take a specific channel’s head instead of the default.
400 rather than reaching storage.
What happens after the scan
The sensor performs a read-only scan and posts one structured report per host to your tenant, where it appears under Discover → Findings. Re-runvisiq-discovery scan any time to refresh a host’s inventory; a fleet install does this on its own schedule.
See Discovery for what each scanner detects and the read-only guarantees the sensor holds to.