Installing the sensor on Windows

The sensor is the small service that runs on each machine and reports what processes started and what files changed. Without it, the endpoint half of Qorionix has nothing to look at. This article covers Windows specifically: the artefact, the exact command, where everything lands, how to tell it worked, and how to take it off again.

Windows is the best-supported of the three platforms. It is the only one where the installer is code-signed, which matters more than it sounds: an unsigned installer is one your own tooling should be suspicious of, and you should not have to switch that suspicion off to deploy a security product.

What you need before you start

• A 64-bit x64 Windows machine. The MSI is built -arch x64 and installs per-machine. There is no 32-bit build and no Windows-on-Arm build, so an Arm-based Windows device cannot run the sensor today.
• Local administrator rights, because the service is installed per-machine and runs as LocalSystem.
• Outbound HTTPS from the machine to your API base URL — the console origin you were given at enrolment, e.g. https://app.qorionix.com. Nothing inbound is needed.
• An enrolment token, created in the console under Settings -> Endpoints -> Enrolment tokens. See Enrolment tokens for what a token is scoped to and how long it lasts.

The artefact, and its signature

Use the versioned Windows downloads returned by the console. The installer and standalone executable have these names:

Both files are signed with the same certificate (subject CN=Qorionix Sensor (self-signed)), so you only ever need to trust one unknown publisher rather than two. The thumbprint the generated command pins is published alongside the release manifest; if you are verifying by hand rather than through the generated command, compare Get-AuthenticodeSignature <file>.SignerCertificate.Thumbprint against the value published with the download rather than against anything printed here — thumbprints change if the signing certificate is ever reissued.

The signature is still RFC 3161 timestamped, which matters independently of trust: it is what lets a signature keep verifying years after the certificate itself expires, whether the chain is trusted or self-signed.

Artefacts are published under the download location given to you with your enrolment token, with a manifest.json and a SHA256SUMS.txt beside them, so a signature check and a hash check are both available to you before you deploy anything.

The install command

The console generates the Windows PowerShell command with the download URL, release checksum and API URL. Open PowerShell as administrator, paste the command, and enter the displayed token at its masked prompt. The MSI installs silently after that prompt and suppresses automatic restart.

For unattended deployment, supply the hidden enrollment property through the Windows Installer COM API from your management tool's protected secret input. Passing SENSOR_ENROLL_TOKEN to msiexec.exe as a command-line argument exposes it to process auditing. The MSI's native enrollment action passes the coupon to the sensor through standard input.

The command starts by fetching the MSI on purpose. An earlier version named a bare filename the admin had never been told how to obtain, and produced a confident copy-pasteable line that could only ever fail with No such file or directory. A command that cannot work is worse than no command at all.

`UILevel = 2`

Fully silent. No user interface, nothing for a logged-in user to dismiss or cancel.

`REBOOT=ReallySuppress`

Never reboots the machine. The sensor does not need a restart to start collecting.

`SENSOR_ENROLL_TOKEN`

The hidden enrollment property passed in memory. MsiHiddenProperties and hidden custom-action data suppress its MSI log value; the native action uses standard input for the child process. A fresh installation without this property installs an unenrolled service.

`SENSOR_API_URL`

The API base URL the sensor talks to. Set it to the console origin you were given at enrolment; there is no default worth relying on.

1. 1

   Create an enrolment token

   In the console, Settings -> Endpoints -> Enrolment tokens. Scope it to windows if the whole batch is Windows, and set a use cap matching the number of machines. The plaintext token is shown exactly once and is never recoverable, so copy it now.

2. 2

   Copy the generated command

   Copy the Windows command. Keep the separately displayed token available for the masked prompt.

3. 3

   Run it elevated on the target

   Paste the command into PowerShell opened as administrator, then enter the token when prompted. Package trust is checked before the token is requested.

4. 4

   Confirm the service is running locally

   sc query QorionixSensor should report RUNNING. See the next section for what to check if it does not.

5. 5

   Confirm the machine appears in the console

   This is the check that actually counts. The machine should appear under Endpoints within a minute of installing.

Where everything lives

The config path is compiled into the binary rather than passed by the service definition, so the service, the installer and the enrolment command cannot disagree about it. It honours %ProgramData% and falls back to the literal C:\ProgramData\Qorionix\Sensor\qorionix-sensor.yaml if that variable is missing.

The firewall rule is outbound only and scoped to the sensor executable. There is no inbound exception because the sensor never listens on a port — it polls the platform rather than accepting connections. Service recovery is set to restart on the first, second and subsequent failures with a 60-second delay, so a crashed sensor comes back without anybody noticing it went.

Confirming it is actually running

sc query QorionixSensor
services.msc      (look for Qorionix XDR Sensor)

A running service is necessary but not sufficient. The authoritative check is the console: the machine appearing under Endpoints with a recent last-seen time. A sensor that installed cleanly but could not enrol will show as a running service on the host and as nothing at all in the console — which is exactly the failure an admin with no security team is least likely to notice, so check both.

If enrolment did not complete, the installer does not fail the install. The service starts anyway and retries in the background at 5 seconds, 30 seconds, 2 minutes, 10 minutes and 30 minutes, then every 30 minutes. A rejected token is different: it is fatal and loud, because no amount of retrying fixes a token that has been spent. The messages you will see are:

sensor: no credential configured — this endpoint will not report. Re-run the installer with an enrolment token from Settings -> Endpoints -> Enrolment tokens.
sensor: enrolment token rejected — <reason>. A new token must be issued in the console; this endpoint will not report until it is.
sensor: the server rejected this endpoint's credential (HTTP 401). Re-run the installer with a fresh enrolment token, or check the endpoint has not been revoked in the console.

To re-enrol a machine without reinstalling, use enroll --token-stdin against the same config path from an elevated PowerShell session, then restart the service. The example below collects a fresh token at a masked prompt and keeps it out of process arguments. Replace the API URL with the one shown in your console; the request timeout defaults to 20 seconds.

$secret = Read-Host 'Enrollment token' -AsSecureString
$buffer = [Runtime.InteropServices.Marshal]::SecureStringToBSTR($secret)
try {
  [Runtime.InteropServices.Marshal]::PtrToStringBSTR($buffer) | & "$env:ProgramFiles\Qorionix\Sensor\qorionix-sensor.exe" enroll --token-stdin --api 'https://api.example.test' --config "$env:ProgramData\Qorionix\Sensor\qorionix-sensor.yaml"
  if ($LASTEXITCODE -ne 0) { throw 'Enrollment did not complete. Review the sanitized message above.' }
  Restart-Service QorionixSensor
} finally {
  [Runtime.InteropServices.Marshal]::ZeroFreeBSTR($buffer)
  $secret.Dispose()
}

Uninstalling

Remove it the way you remove any per-machine MSI: Settings -> Apps -> Installed apps, or silently with msiexec /x against the same MSI file. The uninstall stops and removes the service and deletes the enrolled config file — the config holds a live credential for that machine, and leaving it on disk after the software is gone would be careless.

Because the uninstall deletes the config, a later reinstall needs a fresh enrolment token. That is a deliberate trade: the alternative is an orphaned credential sitting in %ProgramData% on a machine that no longer runs the software.

Limits specific to Windows

Two of these will shape what you can expect from detections on this platform, so they are worth reading before you judge the coverage.

• Process data still comes from the live process table, not an ETW callback. A process snapshot runs every two seconds through Win32 calls, which buys you an agent with no driver and no prerequisites for process visibility, and costs you any process that starts and exits inside a single two-second window. Sensor 1.7.0 does add a real ETW consumer to this sensor, but it is scoped narrowly to two specific channels — DNS query completion (Microsoft-Windows-DNS-Client) and, when a FIM watch requests who-data, object-access events off the Windows Event Log API — not a general Sysmon-style process/thread ETW feed. If process visibility on your estate depends on a broad ETW or Sysmon-equivalent stream, that is still not what this sensor provides.
• Command lines are read out of the target process's memory, which needs at least equal privilege and the same architecture. A protected process — System, csrss, an antivirus service — refuses the read. The sensor still emits the process with its identifier, parent and name so the process tree stays connected, and any rule that needed the command line abstains rather than recording a non-match. An abstention is honest; a silent non-match would look like a clean result.
• No network connection events are collected on any platform, Windows included. That bounds which detections can fire and is explained in What the sensor collects.

What to do next

1. Enrolment tokens — scoping, lifetimes, and every failure message you might see.
2. The endpoint list and endpoint health — what stale means and the ordinary reasons a machine goes quiet.
3. Keeping the sensor up to date — there is no auto-update, so plan the upgrade path now rather than later.
4. The endpoint telemetry page — sensor 1.7.0's DNS, logon, USB, script and FIM WhoData channels, read per host.
5. How to get help — if the machine never appears, this is the fastest route to someone who can read the server side.