Skip to main content
Deploying to macOS devices? See Intune (macOS) — macOS uses the signed .pkg plus custom Configuration Profiles instead of an MSI.
AI Watch deploys to Windows as a signed app (aiwatch.exe) installed once per device. The MSI writes only bootstrap credentials plus optional MDM-owned operational limits to the registry. Mode, Sessions, discovery, and scan tuning come from the Runlayer settings sync. Before the first successful sync, AI Watch is Monitor + Sessions off and installs no hooks. The MSI also registers device-local Scheduled Tasks that run scans (all real user profiles), reconcile settings and hooks, and install managed AI Watch updates as SYSTEM, so there are no Intune Remediations to create. It additionally installs the RunlayerAIWatch Windows service, which keeps the AI Watch hook daemon running in each user session.

​
Prerequisites

  • Microsoft Intune admin with app upload rights. No Remediations (P2 / add-on) access required — scanning and hook assertion are scheduled device-locally by the MSI.
  • Devices running Windows 10 1809+ / 11, 64-bit, Microsoft Entra joined.
  • A single organization API key with the Shadow AI Scan role (rl_org_...). It is minted automatically when you create the configuration in Settings → MDM configuration — copy it from the wizard’s deploy step; there is no separate key-creation step. The same key covers scanning, enforcement, sessions, and managed updates.
Windows Home and S mode are not supported.

​
What you receive

Download the deployment artifacts directly from the setup wizard in Settings → MDM configuration (Add new, or View deployment setup on an existing configuration). The wizard serves the version selected by your Client Updates policy: The scan, hook, and update task scripts run inside the MSI (registered by its custom action); you don’t upload them to Intune. Older releases ship these files as a single aiwatch-<version>-intune-package.zip bundle instead — extract it after downloading. The signed MSI is also available from the wizard if you need to wrap or rebuild the .intunewin yourself.

​
Install properties

The generated install command carries only AIWATCH_HOST and AIWATCH_ORG_API_KEY. The MSI also accepts the MDM-owned optional properties below. Capabilities managed in Runlayer are deliberately not MSI properties. Mode, Sessions, and detection options are not MSI properties. Configure them in Settings → AI Watch → Manage settings; devices pick up changes on their next hourly settings sync. Until a device completes its first sync, it runs Monitor with Sessions off and installs no hooks. The MDM configuration setup wizard stores selected capabilities in Runlayer and renders the bootstrap-minimal command. Copy the command before closing the dialog.
Older AI Watch MSIs accepted AIWATCH_MODE, AIWATCH_ENFORCEMENT, AIWATCH_SESSIONS, and AIWATCH_DETECT_* properties, and some fleets still run Intune Proactive Remediation scripts that write those values under HKLM\Software\Runlayer\AIWatch. Retire those scripts: the Runlayer settings sync now owns these values, and a remediation script that keeps re-asserting them fights the hourly sync — devices flip back and forth between the script’s values and the settings configured in Runlayer.

​
Phase 1 — Create the app

1

Open the Intune admin center

Go to intune.microsoft.com → Apps → Windows → Add → Windows app (Win32).
2

Upload the package

Select the aiwatch-<version>-win-x64.intunewin file from the deployment package.
3

App information

Click Next.
4

Program

Use the command rendered by the setup guide (Settings → MDM configuration → Add new). The only MSI properties needed are AIWATCH_HOST and AIWATCH_ORG_API_KEY — do not add others. The AIWatchHooks task fetches capabilities and scan tuning from Runlayer after installation.For full package, scheduled-task, and hook cleanup, see Remove AI Watch.Click Next.
5

Requirements

  • Operating system architecture: 64-bit
  • Minimum operating system: Windows 10 1809
Click Next.
6

Detection rules

Choose Use a custom detection script and upload custom-detection/detect-install.ps1 from the deployment package. Set Run script in 64-bit PowerShell host to Yes and Enforce script signature check to No. It reports installed only when aiwatch.exe (≥ the packaged version) and the required scheduled tasks exist — so a wiped folder or an isolated failure to register a task flips the app to not installed and Intune reinstalls, re-running the task-registration custom action. This also drives Supersedence upgrades.
Enforce script signature check = No is required. Azure Trusted Signing rotates leaf certificates, which is incompatible with Intune’s Yes path (AllSigned plus the device’s Trusted Publishers store). Intune can refuse the script before line 1, leaving no detect-install.log, reporting 0x87D1041C, and repeatedly reinstalling a stale MSI.
If detection keeps failing, confirm Install behavior = System and Run script in 64-bit PowerShell host = Yes, and use the shipped detection script unmodified — Intune treats any STDERR output from a detection script as not installed, and the shipped script silences non-output streams for that reason. A script that starts appends one line to C:\ProgramData\Runlayer\Logs\detect-install.log with its identity and failing check.Click OK → Next.
7

Dependencies and Supersedence

  • Dependencies: skip (none required).
  • Supersedence: skip on first deploy. For upgrades, see Upgrade path below.
Click Next.
8

Return codes

Keep the defaults. They match the values expected by the MSI installer:Click Next.
9

Assignments

Select target device groups under Required or Available for enrolled devices → Review + create.

​
Phase 2 — Scheduling (automatic)

There is no Phase 2 to configure. When the MSI installs, it registers the device-local Scheduled Tasks. The scan and hook tasks run once immediately; the update task’s first run comes about an hour after install. All three live in a hidden \Runlayer Task Scheduler folder: A single SYSTEM AIWatchScan task covers every user on the device: it enumerates the device’s real user profiles — local and Microsoft Entra — and scans each one separately, with that profile’s own MCP client configuration in scope. Service accounts are skipped. Each profile is scanned independently — one failure can’t abort the run. A logged-on user (incl. Entra) is scanned as themselves; a logged-off user who has signed in at least once is still covered (as SYSTEM); a brand-new user with no profile yet is picked up on the next tick.
This single SYSTEM task replaces the legacy per-user scan tasks used by earlier versions. The register custom action removes any leftover legacy tasks on upgrade.
Because scans are scheduled on the device (not by Intune), “did it run” is reported by device last-seen in Runlayer plus Task Scheduler’s LastTaskResult / event log — there is no per-run Intune Remediations dashboard row. This matches the macOS launchd model.

​
Tamper resistance

The \Runlayer task folder and every task are hidden with protected permissions: standard users cannot modify the tasks or trigger the SYSTEM update installer. Permissions are re-asserted on each MSI repair or upgrade, and if a required task is missing the detect-install.ps1 rule flips the app to not installed so Intune reinstalls. To remove AI Watch from a device, use the Intune uninstall assignment or your MDM’s removal workflow — see Remove AI Watch.

​
Phase 3 — Hooks (Protect, Enforce, or Sessions)

Also automatic. The AIWatchHooks task refreshes the deployment’s Runlayer settings and asserts hook configs hourly when Mode is Protect/Enforce, Sessions is enabled, or Track MCP tool usage without content is enabled. It is a silent no-op for Monitor with Sessions and that setting disabled. To stop applying endpoint decisions, use Settings → AI Watch → Manage settings and select Monitor; if Sessions stays enabled, hooks remain installed for telemetry.

​
Verification

After devices sync with Intune (and, for Protect or Enforce, a user logon):
In the Runlayer dashboard, go to Settings → MDM configuration and confirm Detect data is arriving (device last-seen advances each scan tick). There is no Intune Remediations dashboard row to check — task health is read from LastTaskResult / the Task Scheduler event log on the device. For updates, LastTaskResult = 0 on the parent task means the policy check completed or a detached handoff was accepted. It is not the final MSI result. Compare the installed Version with the version selected in Client Updates and inspect aiwatch-update.log after the handoff has had time to finish.

​
Upgrade path

Pushing a newer MSI upgrades in place: existing settings such as Host, OrgApiKey, and resource caps are preserved, and the Scheduled Tasks are refreshed rather than torn down mid-upgrade. Legacy MSI-written capability values are not carried forward because the Runlayer settings sync now owns them. On devices that already have the AIWatchUpdate task, upgrades happen automatically: the task downloads and verifies the MSI version selected by your Runlayer tenant, then installs it as SYSTEM once the running updater exits. No API key or MSI property appears on the task command line.
The first automatic update cannot install its own scheduler. Devices on an older MSI need one manual Intune/MDM push to a version that includes AIWatchUpdate; subsequent updates are automatic.
1

Download the new package

Download the new .intunewin from the setup wizard (Settings → MDM configuration → View deployment setup). On older releases this is a aiwatch-<version>-intune-package.zip bundle — extract the .intunewin from it.
2

Create a new app

Follow Phase 1 again. The install command must still include AIWATCH_HOST and AIWATCH_ORG_API_KEY; re-writing the same values is a no-op, but the MSI requires both mandatory properties.
3

Set the detection rule + Supersedence

Upload custom-detection/detect-install.ps1 from the new deployment package; its packaged-version check drives the upgrade. On the new app’s Supersedence page, add the previous version and select Supersede, then assign to the same device groups. Retire the old app once the new one is assigned.

​
Troubleshooting

  • Ensure the device is Microsoft Entra joined (not just registered)
  • Check that the Intune Management Extension service is running
  • Verify the install command has the correct host and API key
  • Review logs in C:\ProgramData\Microsoft\IntuneManagementExtension\Logs
The install command is missing a mandatory property. Both AIWATCH_HOST and AIWATCH_ORG_API_KEY are required — the MSI’s launch conditions refuse a half-configured registry write. Re-run with both set.
  • The task-registration action gates on OrgApiKey. Confirm Get-ItemProperty "HKLM:\Software\Runlayer\AIWatch" shows OrgApiKey, then trigger an app repair/reinstall.
  • Check the task-registration lines (tagged [register]) in C:\ProgramData\Runlayer\Logs\scheduled-task.log.
  • A user who has never signed in has no profile yet, so they aren’t scanned until the next AIWatchScan tick (logon / boot / 15 min) after their first sign-in.
  • Verify the organization API key is current in Settings → MDM configuration — if it was revoked or rotated, regenerate the configuration to mint a new key and re-push — and that the device can reach your Runlayer instance over HTTPS.
The single SYSTEM AIWatchScan task runs aiwatch.exe scan --all-users and scans each real profile in a child process. Check its LastTaskResult and tail C:\ProgramData\Runlayer\Logs\scheduled-task.log for the orchestrator summary (all_users_scan_complete) and per-profile lines (all_users_profile_scan_*) — a non-zero task result means at least one profile’s child scan failed, and the log names the SID/username. (The detailed per-profile child-scan output lands in each scanned user’s own profile at C:\Users\<username>\.runlayer\logs — the child scan’s USERPROFILE is pointed at that profile — not in scheduled-task.log.) Confirm the profile has a real ProfileImagePath under HKLM\...\ProfileList (local S-1-5-21-... / Entra S-1-12-1-...; service SIDs S-1-5-18/19/20 are skipped by design). A logged-off Entra user is scanned as SYSTEM (env-pointed at their profile), not privilege-dropped — expected and documented; they are scanned as themselves once logged on.
Expected. Standard users have read + execute only for the \Runlayer folder, AIWatchScan, and AIWatchHooks, and no access to AIWatchUpdate or its transient handoff. Use an elevated session to inspect or change them.