Appearance

Deployment ​

Where to place the policy file on each platform, how the Launcher and daemon pick the one active document, and options to deploy and test at scale.

What You'll Learn

  • How the policy file reaches a managed machine
  • Which sources each platform loads policy from and what it runs on when none is delivered
  • Deployment patterns across SCCM, Group Policy, and Intune
  • How to test a candidate policy without affecting enterprise policy

How policy reaches the machine ​

There are two ways the system-wide policy file arrives, and they write the same path.

Automatic sync from the server. On Windows clients with the Launcher feature enabled, the Sandbox Manager service downloads the published policy and writes %PROGRAMDATA%\Turbo\Launcher\policy.json itself. This is the normal path for a Turbo-managed fleet: publish the policy on the server and endpoints pick it up on their next check, without a management-tool deployment. Enable it per machine with:

powershell
turbo config --enable=Launcher

The check interval is carried by the policy document in configuration.policyUpdateIntervalMinutes (1 to 60 minutes; 5 minutes when the field is absent). Details, including the ETag behavior and how to force an immediate check, are in Sandbox Manager policy sync.

Direct file deployment. Push policy.json to the same path with SCCM, Group Policy, or Intune, as described below. Use this when the endpoints are managed by an existing deployment tool, when the Launcher feature is not enabled, or when the policy is not served from a Turbo server. The Launcher watches the policy directory, so a file deployed this way applies within seconds.

If you use both, the automatic sync overwrites a deployed file on its next check whenever the served policy differs. Choose one delivery path per machine.

Effective policy sources and precedence ​

One policy document is active on a machine at a time; there is no cross-source merging. The chain of sources differs by platform, the evaluator does not. Full detail: Merging & Precedence → Policy sources and delivery.

Windows ​

  1. Server download (Sandbox Manager sync, above) → written to %PROGRAMDATA%\Turbo\Launcher\policy.json
  2. %PROGRAMDATA%\Turbo\Launcher\policy.json deployed directly (SCCM, GPO, Intune)
  3. In-memory last-known-good, when a newer candidate is refused
  4. The embedded allow-all default — a Windows machine with no delivered policy is unfiltered

The Launcher re-checks every 5 minutes (configuration.policyUpdateIntervalMinutes) and watches the policy directory, so a deployed file applies within seconds. There is no per-user policy file; per-user input is limited to User Configurations, which are validated against the enterprise policy's templates and cannot authorize applications.

macOS ​

  1. A managed-preferences plist delivered by MDM
  2. /Library/Application Support/Turbo/policy.json
  3. Deny-all — with no source present nothing is launchable

The Turbo daemon polls the sources every 5 seconds and applies a change as soon as it decodes. A source is trusted only when its path is root-owned and not world-writable; deploy the file as root with a management tool, not by copying it as a user. The macOS launcher reads no file of its own — it receives the daemon's decoded policy over XPC.

Merge semantics across sources ​

Source precedence is absolute: the first source in the platform's chain that yields a decodable document is the Active Policy, and every merge and tie-break (authorization, modifications, profiles, routing) happens inside that one document. A document that fails to decode is refused whole and the previous good policy stays in force; nothing is ever half-applied.

Per-user testing flows ​

Goal: test changes for a single user without affecting enterprise settings. There is no user-scoped policy file on either platform, so localized testing on a managed device is impossible by design.

Preferred options

  • Use a test device or VM that is excluded from the enterprise deployment, and deploy the candidate policy to it through the same machine-wide path (%PROGRAMDATA%\Turbo\Launcher\policy.json on Windows; /Library/Application Support/Turbo/policy.json or a managed preference on macOS).
  • Use device scoping (SCCM collections, Intune assignments, GPO link scoping, MDM device groups) so that the enterprise policy is not deployed to your test device(s). Treat these as staging rings for validation.

On a device that already has an enterprise policy

  • Do not modify, move, or remove the machine-wide policy on managed devices; on Windows the Sandbox Manager sync would overwrite it on the next check anyway, and on macOS a user-writable copy is refused.
  • Shift testing to a staging ring: exclude the device from the enterprise deployment or target a separate test collection/group.

Validation notes

  • Validate the candidate document against the JSON Schema before deploying; every shipped policy must validate.
  • A refused document (unknown action, schemaVersion above 2, matchNone without schemaVersion: 2) leaves the previous policy in force — check the Launcher's policy status rather than assuming the new file applied.

Configuration Manager (SCCM) ​

Steps

  1. Create an Application or Package that includes policy.json.
  2. Add a PowerShell install script to create the folder and copy the file.
  3. Deploy to target device collections.

Example install script:

powershell
# Create the Launcher policy directory
$policyPath = "$env:PROGRAMDATA\Turbo\Launcher"
if (!(Test-Path $policyPath)) {
    New-Item -Path $policyPath -ItemType Directory -Force
}

# Copy policy file from SCCM package contents
Copy-Item "$PSScriptRoot\policy.json" "$policyPath\policy.json" -Force

Notes

  • There is no user-scoped policy file; deploy test policies to a staging ring of devices instead.

Group Policy (GPO) ​

Option A — Group Policy Preferences (Files)

  1. Computer Configuration → Preferences → Windows Settings → Files.
  2. Create a File item:
    • Action: Update
    • Source: \your.domain\SYSVOL\your.domain\Policies\…\Turbo\policy.json
    • Destination: %PROGRAMDATA%\Turbo\Launcher\policy.json
    • Enable “Create all folders” if needed.
  3. Link and scope the GPO to target computers.

Option B — Startup Script

  1. Computer Configuration → Policies → Windows Settings → Scripts (Startup/Shutdown).
  2. Add a Startup script that creates the folder and copies the file from SYSVOL/secured share.

Example startup script:

powershell
$policyPath = "$env:PROGRAMDATA\Turbo\Launcher"
if (!(Test-Path $policyPath)) {
    New-Item -Path $policyPath -ItemType Directory -Force | Out-Null
}

$source = "\\your.domain\SYSVOL\your.domain\Scripts\Turbo\policy.json"
Copy-Item $source "$policyPath\policy.json" -Force

Notes

  • Scope the GPO to a staging OU or security group to test a candidate policy; there is no per-user policy path.

Microsoft Intune (MDM) ​

Method 1 — PowerShell scripts

  1. Intune admin center → Devices → Windows → PowerShell scripts → Add.
  2. Upload a script that creates the folder and downloads or embeds policy.json.
    • Run this script using the logged-on credentials: No
    • Run script in 64-bit PowerShell: Yes
  3. Assign to device groups.

Download example:

powershell
$policyPath = "$env:PROGRAMDATA\Turbo\Launcher"
if (!(Test-Path $policyPath)) {
    New-Item -Path $policyPath -ItemType Directory -Force | Out-Null
}

$uri = "https://contoso.blob.core.windows.net/turbo/policy.json" # replace with your URL
$dest = Join-Path $policyPath "policy.json"
Invoke-WebRequest -Uri $uri -OutFile $dest -UseBasicParsing

Method 2 — Win32 app (packaged)

  1. Package policy.json + install script with the Win32 Content Prep Tool (.intunewin).
  2. Install command places the file in %PROGRAMDATA%\Turbo\Launcher.
  3. Detection rule: file exists at %PROGRAMDATA%\Turbo\Launcher\policy.json (optionally verify hash/version).
  4. Assign to device groups; use delivery rings as needed.

Method 3 — Proactive remediations

  • Detection script validates existence and optional hash.
  • Remediation script deploys/repairs policy.json.
  • Assign to device groups on a schedule.

Operational guidance ​

  • Prefer the system-wide path for all users; it is authoritative when present.
  • Use HTTPS hosting with authentication for downloads, or embed the file in the deployment artifact.
  • After deployment, reload in the Launcher (Retry) and validate using Testing & Validation.

Configuration Templates deployment tips (Windows) ​

  • Define configurationTemplates in the enterprise policy at %PROGRAMDATA%\\Turbo\\Launcher\\policy.json. Templates and user configurations are a Windows-only feature; the macOS readers accept and ignore them.
  • On managed devices, do not rely on user-scoped templates. Use device scoping (SCCM/Intune/GPO) to deploy the enterprise policy with template definitions.
  • Ensure apps that should surface user configurations include apps[].configurationTemplates referencing the desired template ids in the same effective policy.
  • Pattern guidance for mounts:
    • Use glob for Windows path patterns (recommended for readability).
    • Use regex for value constraints (for example, environment variable formats).
    • Environment variables inside patterns are resolved at validation time.
  • Templates do not change authorization scope. Apps still must be discoverable via shortcut scan and allowed by an enabled application policy.

Per-user configurations storage (Windows) ​

User configurations are stored at %LOCALAPPDATA%\Turbo\Launcher\user-profiles.json.

  • Scope and authority
    • This is a per-user file. It does not authorize applications or override the system-wide policy. Enterprise policy (when present) remains authoritative.
    • Configuration contents are validated against enterprise configurationTemplates (environment variables only) at creation and launch time.
  • Seeding/pre-staging (optional)
    • Admins may optionally seed a starter user-profiles.json for a user during onboarding (for example, with a few example profiles). Ensure the file is written under the target user’s profile path.
    • Do not deploy a shared user-profiles.json across users; this file is user-specific by design.
  • Editor validation
  • Managed devices
    • On managed devices with a system-wide policy, user configurations are allowed but always validated against the enterprise templates and cannot bypass deny rules or add VM flags/arguments.

Next steps ​

Turbo.net © 2025