Deploy Orb on Windows using Microsoft Configuration Manager

This guide walks you through deploying Orb across a Windows fleet using Microsoft Configuration Manager (ConfigMgr, formerly SCCM). The guide covers:

1. Choosing between the Orb sensor and the Orb app
2. Building the content source and keeping your Deployment Token out of logs
3. Creating the Application and its deployment type
4. Deploying, verifying, updating and uninstalling
5. The files and processes to allow-list in endpoint security tools

Requirements:

1. An Orb Cloud subscription
2. A Configuration Manager current branch site with a distribution point and management point
3. Windows devices with the ConfigMgr client installed, in a device collection
4. A Deployment Token for your Space

Which should I deploy?

Orb offers two Windows deliverables. They behave very differently under managed deployment, so choose deliberately.

Before you start

Create a Deployment Token in the Orchestration section of Orb Cloud. A Deployment Token links each Orb to your Space automatically, with no user interaction.

Use a dedicated, revocable token per deployment so you can attribute devices and revoke access without disrupting other rollouts.

Deploy the Orb sensor

Prepare the content source

Create a folder on your content source share, for example \\server\Source$\Orb\OrbSensor, containing the sensor MSI and your token:

OrbSensor\
  orb-sensor.msi
  deployment_token.txt

deployment_token.txt contains only your token, with no trailing newline:

orb-dt1-yourdeploymenttoken678

Create the Application

1. In the console, go to Software Library → Application Management → Applications and select Create Application.

2. Leave Automatically detect information about this application from installation files selected, set Type to Windows Installer (*.msi file), and set the location to the MSI on your share, for example \\server\Source$\Orb\OrbSensor\orb-sensor.msi.

3. Select Next. Configuration Manager reads the package, fills in the name, publisher and version, and creates the detection rule from the MSI product code.

4. On General Information, set the installation program so it reads the token from the content:

   msiexec /i "orb-sensor.msi" /q DEPLOYMENTTOKENFILE=deployment_token.txt

   Set Install behavior to Install for system.

5. Complete the wizard.

Open the deployment type's properties and confirm two settings on the User Experience tab:

• Logon requirement: Whether or not a user is logged on
• Installation program visibility: Hidden

On the Programs tab, the uninstall program is already filled in from the package:

msiexec /x {ProductCode} /q

Distribute and deploy

1. Right-click the application and select Distribute Content, then choose your distribution point.
2. Right-click the application and select Deploy, choose your device collection, set the Purpose to Required, and set the deadline.

The service installs and starts, then links to your Space with no user interaction and without anyone logging in. The MSI installs the Orb service as LocalSystem with start type Automatic and configures it to restart on failure, so it also returns after every reboot with nothing further to configure.

Configuration properties

Set any of these as PROPERTY=value pairs on the installation program. They are persisted, so they survive upgrades.

Other sensor options from Orb Configuration are available as properties of the same name, including ORB_FIRSTHOP_DISABLED, ORB_BANDWIDTH_DISABLED, ORB_EPHEMERAL_MODE, ORB_MEASURE_SERVER_ENABLED and ORB_MEASURE_SERVER_PORT.

Migrating from a scripted sensor installation

If your devices already run a sensor installed by script, the MSI takes over the existing service in place, keeps the device's identity, and removes the old executable, its folder and its firewall rule. Each device stays the same Orb in your Space.

To migrate, configure the MSI application to supersede the older application and leave Uninstall unchecked, because the MSI replaces the old installation in place.

Install Orb on Windows describes an optional Orb Auto-Update scheduled task for scripted installations. The MSI removes that task if it finds it. Do not recreate it on devices you manage with Configuration Manager: it would replace files owned by the installer, after which the version Configuration Manager reports would no longer match what is running.

Deploy the Orb app

The app has no MSI, so it is deployed as a script installer. It also needs a startup entry that its silent installation does not create.

Allow PowerShell scripts to run

The app's deployment type uses PowerShell for installation and detection. Configuration Manager writes detection scripts to C:\Windows\CCM\SystemTemp and runs them, so the client must be allowed to execute them.

In the console, go to Administration → Client Settings, edit your client settings, select Computer Agent, and set PowerShell execution policy to Bypass.

PSSecurityException / UnauthorizedAccess
CScriptHandler::DiscoverApp failed (0x87d00327)

Prepare the content source

OrbApp\
  Orb-installer.exe
  Install-OrbApp.ps1
  Uninstall-OrbApp.ps1
  deployment_token.txt

Download the installer from https://pkgs.orb.net/earlyaccess/windows/Orb-installer.exe.

Install-OrbApp.ps1:

[CmdletBinding()]
param([string] $DeploymentToken)

$ErrorActionPreference = 'Stop'

if (-not $DeploymentToken) {
    $sidecar = Join-Path $PSScriptRoot 'deployment_token.txt'
    if (Test-Path $sidecar) { $DeploymentToken = (Get-Content $sidecar -Raw).Trim() }
}
if (-not $DeploymentToken) { exit 2 }

$installer = Join-Path $PSScriptRoot 'Orb-installer.exe'
$flags = @('/S', '/LAUNCH_AT_STARTUP=1', '/START_IN_BACKGROUND=1', "/ORB_DEPLOYMENT_TOKEN=$DeploymentToken")
$p = Start-Process -FilePath $installer -ArgumentList $flags -Wait -PassThru
if ($p.ExitCode -ne 0) { exit 1 }

# Create the all-users startup entry so the app runs at each user's next logon.
$startupDir = Join-Path $env:ProgramData 'Microsoft\Windows\Start Menu\Programs\StartUp'
New-Item -ItemType Directory -Path $startupDir -Force | Out-Null
$shell = New-Object -ComObject WScript.Shell
$lnk   = $shell.CreateShortcut((Join-Path $startupDir 'Orb.lnk'))
$lnk.TargetPath       = 'C:\Program Files\Orb\Orb.exe'
$lnk.WorkingDirectory = 'C:\Program Files\Orb'
$lnk.Save()
exit 0

Uninstall-OrbApp.ps1:

$ErrorActionPreference = 'Continue'

$lnk = Join-Path $env:ProgramData 'Microsoft\Windows\Start Menu\Programs\StartUp\Orb.lnk'
if (Test-Path $lnk) { Remove-Item $lnk -Force -ErrorAction SilentlyContinue }

Get-Process Orb -ErrorAction SilentlyContinue | Stop-Process -Force -ErrorAction SilentlyContinue

$un = 'C:\Program Files\Orb\uninstall.exe'
if (Test-Path $un) { Start-Process -FilePath $un -ArgumentList '/S' -Wait }
exit 0

Create the Application

1. Select Create Application and choose Manually specify the application information.

2. Name the application, for example Orb App, and set the publisher and version.

3. On Deployment Types, select Add and choose Script Installer.

4. Set the Content location to your package folder, for example \\server\Source$\Orb\OrbApp.

5. Set the programs:

   Installation program

   powershell.exe -ExecutionPolicy Bypass -NoProfile -File .\Install-OrbApp.ps1

   Uninstall program

   powershell.exe -ExecutionPolicy Bypass -NoProfile -File .\Uninstall-OrbApp.ps1

6. On Detection Method, choose Use a custom script to detect the presence of this deployment type, set the script type to PowerShell, and paste:

   $MinVersion = '1.5.0'
   
   $arp = Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*',
                           'HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*' -ErrorAction SilentlyContinue |
          Where-Object { $_.DisplayName -eq 'Orb' -and $_.Publisher -like 'Orb Forge*' } |
          Select-Object -First 1
   
   if (-not $arp) { exit 0 }
   if (-not (Test-Path 'C:\Program Files\Orb\Orb.exe')) { exit 0 }
   
   try {
       if ([version]$arp.DisplayVersion -ge [version]$MinVersion) { Write-Output "Installed $($arp.DisplayVersion)" }
   } catch { }
   exit 0

7. On User Experience, set Installation behavior to Install for system, Logon requirement to Whether or not a user is logged on, and Installation program visibility to Hidden.

Distribute the content and deploy it the same way as the sensor.

Verify the deployment

In the console, select the application and review Deployments for installation status.

On a target device:

# Sensor
Get-Service Orb
& 'C:\Program Files\Orb Sensor\Orb.exe' version

# App
Get-Process Orb

In Orb Cloud, confirm the device appears in your Space and is reporting.

Useful client logs, in C:\Windows\CCM\Logs:

For the sensor, add /l*v C:\Windows\Temp\orb-sensor.log to the installation program while troubleshooting, to capture a verbose Windows Installer log.

Update Orb

Sensor. Import the newer MSI as a new application, configure it to supersede the current one with Uninstall unchecked, and deploy it. Windows Installer performs a major upgrade in place, and product-code detection reports the new version automatically.

Upgrading keeps the device's identity: it stays the same Orb in your Space rather than appearing as a duplicate, and its Deployment Token and configuration properties are preserved.

Self-updating sensors. On devices installed with AUTOUPDATE=1, the sensor updates itself and you do not deploy new versions. The Orb Sensor Update task first runs four hours after installation and every four hours after that. Each run waits a random 0–10 minutes, then compares the installed version with the latest release. If a newer one exists, the task downloads it, checks that it is signed by Orb Forge, and installs it as the same in-place upgrade. To check for an update immediately, run:

schtasks /run /tn "Orb Sensor Update"

Each check writes update.log (and, when it installs an update, msiexec.log) to a new C:\Windows\Temp\OrbSensorUpdate-<random>\ folder. After a self-update, the version installed on the device no longer matches the application you deployed, which is why we recommend leaving AUTOUPDATE at 0 when Configuration Manager manages versions.

App. Replace Orb-installer.exe in the content source, update the distribution points, and raise $MinVersion in the detection script so clients re-evaluate.

Uninstall Orb

Change the deployment's Action from Install to Uninstall, or create a new deployment with the Uninstall action against the target collection.

Uninstalling the sensor removes the service, the program folder, the firewall rule and the Add/Remove Programs entry, and leaves C:\ProgramData\Orb in place. That folder holds the sensor's identity and Deployment Token, which is what allows a reinstall to return as the same Orb rather than creating a duplicate in your Space.

msiexec /x {ProductCode} /q PURGEDATA=1

Files and processes for endpoint security

Use this section to allow-list the Orb sensor in antivirus, EDR, application control (AppLocker, WDAC) and data loss prevention tools. It describes what the sensor MSI installs and what the sensor writes while it runs. It covers the sensor only, not the Orb app.

Code signing

The MSI, Orb.exe and update.ps1 are all Authenticode-signed with Orb Forge's EV code-signing certificate:

Allow by publisher (O=Orb Forge Inc) rather than by file hash or certificate thumbprint. The hash changes with every release and the thumbprint changes each time the certificate is renewed. The subject stays the same.

Processes

During installation and uninstallation, Windows Installer also runs the package's custom-action DLLs from C:\Windows\Installer\MSI*.tmp, and calls schtasks.exe and netsh.exe to manage the update task and remove legacy firewall rules.

Files

Program files, installed and removed by the MSI:

Data, in C:\ProgramData\Orb. The service writes these files as SYSTEM. The folder is kept on uninstall unless you pass PURGEDATA=1.

On a test device, the folder grew to about 70 MB in its first day.

Updater working files, only present when AUTOUPDATE=1:

The updater downloads only from https://pkgs.orb.net/stable/windows/latest/ (version.txt and orb-sensor-amd64.msi). It refuses to install any file whose Authenticode signature does not match the subject above.

Registry, firewall and scheduled task

Recommendations

• Treat deployment_token.txt and private.key as secrets. Anyone who has them can link a device to your Space, or impersonate this Orb. Keep them out of backups and support bundles that leave the device, and rotate the token in Orchestration if it leaks.
• Exclude C:\ProgramData\Orb\orbstore from real-time scanning if scanning causes high CPU. The sensor writes many small files there continuously. Leave the rest of C:\ProgramData\Orb monitored.
• Do not quarantine or block update.ps1 on devices where you install with AUTOUPDATE=1. If Configuration Manager manages versions, leave AUTOUPDATE at 0 and the script never runs.

Troubleshooting

The sensor installation fails with 1603

1603 is Windows Installer's generic failure code. The device's Application event log says which failure it was. In Event Viewer → Windows Logs → Application, filter on the source MsiInstaller around the time of the failure:

If the cause is not clear, add /l*v C:\Windows\Temp\orb-sensor.log to the installation program and redeploy, then search the log for Return value 3. The lines just above it name the step that failed. Include that log, the MsiInstaller events and C:\Windows\CCM\Logs\AppEnforce.log when you contact support.

A failure that does not repeat on the next attempt points to something else happening on the device at that moment, such as another installation in progress or security software scanning the newly installed files. A failed installation is rolled back and leaves the previous version running. Configuration Manager retries a Required deployment at the client's next application deployment evaluation cycle, or you can trigger the cycle from Configuration Manager in Control Panel (Actions → Application Deployment Evaluation Cycle).

The application installs but reports as failed

Detection is failing. For the sensor, confirm the deployment type's detection rule is the product code of the package you deployed; a new version has a new product code. For the app, check AppDiscovery.log, and if you see 0x87d00327 with PSSecurityException, set the PowerShell execution policy client setting to Bypass as described above.

The app is installed but does not appear in Orb Cloud

The app only reports while it is running, and it runs only in a user session. Confirm that C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp\Orb.lnk exists and that a user has logged on since installation.

The sensor does not have this constraint: it runs as a service and reports without anyone logging in.

Orb does not link to my Space

1. Confirm C:\ProgramData\Orb\deployment_token.txt exists (sensor), or that HKLM\SOFTWARE\Orb\MDM\OrbDeploymentToken is set (app).
2. Confirm the token is still valid in Orchestration.
3. Confirm the device can reach the internet.

If the token was rejected, the sensor MSI fails the installation immediately with 1603 and gives the reason in its verbose log, rather than installing a sensor that never links. If Orb Cloud is merely unreachable, installation succeeds and the device links when it next has connectivity.

Wi-Fi network name and access point are missing

Windows 11 only gives Wi-Fi network details (network name, access point, link rates, Wi-Fi standard and security) to apps that are allowed to use location, and it applies this to services such as the Orb sensor too. When location is blocked, the sensor still reports scores, signal strength and channel, but the network name and access point are empty.

To confirm, open the newest log in C:\ProgramData\Orb\logs and search for windows wifi: query results changed:

"msg":"windows wifi: query results changed",...,"connection":5,...,"location_denied":true

"location_denied":true means Windows refused the sensor's request for Wi-Fi details. Once location is allowed, the next line shows "connection":0 and "location_denied":false.

Find what blocks location. Run these on an affected device:

reg query HKLM\SOFTWARE\Policies\Microsoft\Windows\LocationAndSensors /v DisableLocation
reg query HKLM\SOFTWARE\Policies\Microsoft\Windows\AppPrivacy /v LetAppsAccessLocation
reg query HKLM\SOFTWARE\Microsoft\PolicyManager\current\device\System /v AllowLocation
reg query HKLM\SOFTWARE\Microsoft\PolicyManager\current\device\Privacy /v LetAppsAccessLocation

Policies from Intune do not appear in gpresult; they are the values under PolicyManager above. To check Location services itself, look in Settings rather than at the ConsentStore\location registry value: changing that value by hand does not change the setting.

Allow location for the sensor. The sensor only needs Location services turned on for the device. Users can keep Let apps access your location and Let desktop apps access your location turned off, and their own apps stay blocked, so turning on Location services on each device is the narrowest option. No policy turns it on centrally while leaving the rest to users; the policies below allow location for every app.

1. Remove any setting that forces location off. If DisableLocation is 1, set Computer Configuration → Administrative Templates → Windows Components → Location and Sensors → Turn off location to Not Configured in the Group Policy object that sets it. If AllowLocation is 0, change the policy in your MDM. Fix these at their source; a value changed only on the device is restored at the next policy refresh.
2. Allow apps to use location. Either turn on Location services on each device, or set it centrally with Group Policy Computer Configuration → Administrative Templates → Windows Components → App Privacy → Let Windows apps access location: Enabled, Default for all apps = Force Allow. This works even when Location services is turned off in Settings. With Intune or another MDM, set Privacy/LetAppsAccessLocation to Force Allow.

Co-managed devices. If you set device policy with Intune and deploy Orb with Configuration Manager, set Let Apps Access Location in Intune, as described in Microsoft Intune. Do not also set it with a configuration baseline.

Deploy the setting with Configuration Manager. If Configuration Manager manages settings on these devices and you do not use Group Policy, use a configuration baseline:

1. In Assets and Compliance → Compliance Settings → Configuration Items, create a configuration item of type Windows Desktops and Servers (custom), and add a setting:
   • Setting type: Registry value
   • Data type: Integer
   • Hive: HKEY_LOCAL_MACHINE
   • Key: SOFTWARE\Policies\Microsoft\Windows\AppPrivacy
   • Value name: LetAppsAccessLocation
   • Select Create the registry value as a REG_DWORD data type if remediated for noncompliant rules.
2. Add a compliance rule: the value Equals 1, with Remediate noncompliant rules when supported and Report noncompliance if this setting instance is not found selected.
3. Add the configuration item to a configuration baseline and deploy the baseline to the device collection with Remediate noncompliant rules when supported selected.

The sensor picks up the change within seconds. You do not need to restart it or the device. If a Group Policy object also sets LetAppsAccessLocation, the Group Policy value wins at the next refresh, so change it there instead.

Additional configuration

Both deliverables support the configuration options described in Orb Configuration. For the sensor, set them as MSI properties as described above. For the app, MDM settings are read from HKLM\SOFTWARE\Orb\MDM, where OrbDeviceNameOverride sets the name the device reports in your Space.

To deploy Orb with Microsoft Intune instead, see Microsoft Intune.