Mass Deployment via Google Workspace

Force-install the Zeuslock Chrome extension and push the desktop agent to managed Macs from the Google Admin Console — no per-user setup, no shadow installs.

What you'll deploy

This guide walks a Google Workspace super admin through pushing Zeuslock to every managed endpoint in the org, in two parts:

  1. The Zeuslock Chrome extension, force-installed and pinned to the toolbar through Chrome Enterprise Core.
  2. The Zeuslock desktop agent on any managed Macs, delivered through Google Endpoint Management.

Chromebooks are covered by the extension alone — ChromeOS sandboxes third-party network filters, so no separate agent is shipped (or needed) there.

Prerequisites

  • Google Workspace Enterprise (Standard or Plus). Business tiers don't expose the Chrome extension force-install policies.
  • Chrome browsers enrolled in Chrome Enterprise Core (free with any Workspace license — enroll at chromeenterprise.google.com/enrollment).
  • The account performing the deployment must hold the Super Admin role, or a custom role with Services → Chrome Management and Mobile Device Management privileges.
  • Your Zeuslock organization pairing token, copied from the Operator Console under Settings → Organization → Deployment tokens.

If you also manage Windows endpoints, deploy the agent there through GPO or Intune — Google Endpoint Management does not push to Windows. See the Intune and GPO guides for those flows.

Part 1 — Force-install the Chrome extension

1. Open the policy surface

  1. Sign in to admin.google.com.
  2. Navigate to Devices → Chrome → Apps & Extensions → Users & Browsers.
  3. In the left-hand tree, select the organizational unit (OU) you want to target. Start with a small pilot OU — your security team is the usual first wave.

2. Add Zeuslock by extension ID

  1. Click the yellow + in the bottom-right and choose Add Chrome app or extension by ID.
  2. Paste the Zeuslock extension ID: iicgcadhcgbckmpapjihechjpgcdamhd. Confirm this against the value shown in your Operator Console — vanity IDs change between dev and production builds.
  3. Leave the source as Chrome Web Store and click Save.

3. Set the installation policy

  1. Click the Zeuslock row that just appeared.
  2. Under Installation policy, choose Force install + pin to toolbar. Plain “Force install” works but hides the icon, which makes user-visible status checks harder.
  3. Under Update URL, leave the default (Chrome Web Store).

4. Inject the org pairing config

Open Policy for extensions — the JSON editor on the same panel. Paste:

{
  "organization_token": {
    "Value": "ZL_org_pairing_token_here"
  }
}

Replace the placeholder with the token from the Operator Console. Save. Chrome propagates the policy to every enrolled browser in the selected OU within a few minutes — users don't need to restart Chrome.

Part 2 — Push the desktop agent to managed Macs

If your fleet includes Macs enrolled in Google Endpoint Management, ship the Zeuslock agent .pkg the same way you ship any managed-app payload.

  1. Download Zeuslock-Agent-macOS.pkg from Settings → Deploy → macOS in the Operator Console.
  2. In the Admin Console, go to Devices → Mobile & endpoints → Settings → Apple → Apple device management → Apps.
  3. Click Add app, upload the .pkg, and target the same OU you piloted the extension on.
  4. Pre-provision the org token by editing the package's preflight script so the agent registers on first launch with no user prompt. The template script is included next to the .pkg download.

Chromebooks: nothing to do. ChromeOS does not allow third-party network filters, so the browser extension already covers those users end to end.

Per-OU rollout

Don't push to every OU on day one. A safer cadence:

  1. Week 1 — Pilot OU: security and IT staff only. Watch the Operator Console for noisy detectors against your real traffic.
  2. Week 2 — Friendly OUs: early-adopter teams. Keep policies in Monitor mode.
  3. Weeks 3–5 — Broader OUs: switch high-signal detectors (api_key, credit_card, password) to Anonymize.
  4. Week 6+: escalate to Block for the same set, org-wide.

Because OUs inherit policy from their parent, leave a parent-level “default” OU on Monitor as a safety net while child OUs roll forward.

Verifying the deployment

On any managed Chrome browser in the target OU:

  1. Open chrome://extensions. Zeuslock should appear with the badge Installed by your administrator, pinned to the toolbar, with the extension ID matching the one you entered.
  2. Open chrome://policy and click Reload policies. Search for ExtensionInstallForcelist — the Zeuslock ID should be listed. Search for ExtensionSettings — your JSON block, including organization_token, should be visible.
  3. The Zeuslock toolbar icon turns green within roughly 30 seconds of the first browser launch once it has paired with the Operator Console.
  4. In the Operator Console under Devices, the new endpoint should appear with its hostname, Chrome version, and assigned OU.

Common Google Workspace pitfalls

  • Extension ID typo. A single wrong character silently installs nothing. Copy-paste from the Operator Console, don't transcribe.
  • “Force install” without pinning. Users assume nothing was installed because they can't see the icon. Always use Force install + pin to toolbar.
  • Conflicting allow/block lists. If Allowed Chrome apps and extensions is set to a closed list, add Zeuslock there too — otherwise the force-install policy and the allow list fight each other and the extension stays disabled.
  • OU inheritance surprises. A child OU set to “Override” will not inherit changes made at the parent. Check the Inherited vs Overridden labels next to each setting.
  • Token reuse across orgs. Each Workspace tenant should pull its own pairing token. Sharing a token between tenants merges their devices in the Operator Console.

Once the rollout is stable, lock down the policy at the top-level OU and remove the “Override” flag from child OUs. That makes the configuration auditable in one place and prevents drift.