Deployment

Where to place the policy file, how the Launcher loads and merges multiple policy files, and options to deploy and test at scale.

What You'll Learn

• Which policy file locations the Launcher loads and how system-wide vs user-specific precedence works
• Deployment patterns across SCCM, Group Policy, and Intune
• How to support per-user testing without affecting enterprise policy

---

Effective policy sources and precedence

The Launcher can load policy from two locations:

1. System-wide (enterprise): %PROGRAMDATA%\Turbo\Launcher\policy.json
2. User-specific: %LOCALAPPDATA%\Turbo\Launcher\policy.json

If both files exist, only the system-wide (enterprise) policy is loaded; the user-specific policy is ignored. The system-wide policy acts as the authoritative source.

Summary

• If a system-wide policy exists at %PROGRAMDATA%\Turbo\Launcher\policy.json, it is the only policy evaluated; the user policy is ignored.
• If no system-wide policy exists, the user-specific policy (if present) governs.
• There is no cross-location merging. See: Merging & Precedence (location precedence)

Policy file locations

Lookup and load

1. If the system-wide file is present, load it and ignore any user-specific policy.
2. If no system-wide file is present, load the user-specific file if available: %LOCALAPPDATA%\Turbo\Launcher\policy.json
3. The effective policy is the single loaded file; no cross-location merging occurs.

Recommendations

• Use the system-wide path for organization-wide configuration and enforcement.
• Use the user-specific path only on devices where no system-wide policy is deployed (debug/testing). Do not rely on a user policy when a system-wide policy exists, as it will be ignored.

Merge semantics across locations

Location precedence is absolute. If a system-wide policy is present, the user-specific policy is ignored entirely. There is no cross-location merging. All configuration—including authorization, flags, arguments, and handlers—is derived solely from the active policy file (system-wide if present, otherwise user-specific).

Per-user testing flows

Goal: test changes for a single user without affecting enterprise settings. When a system-wide policy is present, the Launcher intentionally ignores user policies—localized testing on that managed device is impossible by design.

Preferred options

• Use a test device or VM without the system-wide policy. Place policy.json in %LOCALAPPDATA%\Turbo\Launcher\policy.json for the test account.
• Use device scoping (SCCM collections, Intune assignments, or GPO link scoping) so that the system-wide policy is not deployed to your test device(s). Treat these as staging rings for validation.

On a device that already has a system-wide policy

• You cannot run user-scoped policy tests on this device; the system-wide policy always wins. Do not modify, move, or remove the system-wide policy on managed devices.
• Shift testing to a staging ring: exclude the device from the enterprise deployment or target a separate test collection/group that omits the system-wide policy.

Validation notes

• With a system-wide policy present, apps allowed only by a user policy will not authorize or appear.
• With a system-wide policy present, the user policy is ignored entirely; changes to the user policy have no effect on managed devices.

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:

# 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

• If you also distribute user-scoped test policies, remember the enterprise policy will override conflicts and retains sole authorization control when present.

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:

$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

• For per-user test policies, use User Configuration to target %LOCALAPPDATA%\Turbo\Launcher\policy.json, but remember enterprise override semantics.

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:

$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

• Define configurationTemplates in the system-wide policy at %PROGRAMDATA%\\Turbo\\Launcher\\policy.json. When a system-wide policy exists, it is the only policy evaluated; any user policy (including templates) is ignored.
• 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

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
  • Add $schema to enable IntelliSense and basic structure checks:

    { "$schema": "https://schemas.turbo.net/launcher-user-configurations.schema.json", "userProfilesVersion": 1, "profiles": [] }

  • See schema reference: User Configurations Schema and Schema Versioning and Compatibility.
• 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

• Merging & Precedence (location precedence details)
• Testing & Validation
• Authorization & Visibility
• Policy Overview