Action1 Setup, Deployment & Test Runbook

CyberSuite’s RMM leg: deploy software (incl. Huntress), run security scripts, inventory, patch, and remote — Windows and Mac — on Action1 free (≤200 endpoints, full features). This is the tool that took over the deployment/patch/ script role from the now-decommissioned Syncro (see operations-only/strategy/syncro-decommission-and-function-map.md). It is not an MDM and not our EDR.

The triad (read this first). Action1 is one of three legs. Don’t expect it to do the other two:

• EDR → Huntress (Windows: manages built-in Defender AV; Mac: Huntress macOS agent). Action1 deploys the Huntress agent; Huntress does the detection.
• MDM / enforced config-profiles / FileVault & BitLocker enforcement → Microsoft Intune (in M365 Business Premium — the anchor SKU). Action1 can configure security via scripts, but enforced Apple/Windows config-profiles are Intune’s job.
• RMM (this doc) → Action1: software deploy, scripts, inventory, patch, remote.

Why this split is fine: the prior RMM’s Mac side was already script-driven (the patch SLA + Mac script-driven reality now lives in handbook/02-technical-sops/rmm-action1/policy-set.md), so moving the RMM leg to Action1 loses ~nothing — the real Mac profile/MDM layer was always Intune.

---

Prerequisites

• An Action1 free account for CyberSuite (its OWN account — never PDR’s; see [[project_two_company_tooling_separation]]). Sign up at app.action1.com with a CyberSuite admin identity.
• MFA enabled on the Action1 admin login (it’s god-mode over endpoints — treat like a crown-jewel credential; store in 1Password).
• Huntress account + this org’s ACCT_KEY and ORG_KEY (from the Huntress portal → the customer org’s deploy page).
• One test Windows PC + one test Mac with local admin/root (for the POC at the end). The internal M365 test tenant is ideal.
• Note: Action1 agent needs admin (Windows) / root (macOS) to install.

---

Part 1 — Account & organization structure

1. Create the Action1 account; complete email verification + MFA.
2. Model the org structure to match Client IDs. Action1 organizes endpoints with Endpoint Groups (and Enterprise tiers add multi-org). For the free tier, create a dynamic or manual group per customer, named with the Client ID — e.g. CS-1042 — Smith & Associates. This keeps each firm’s endpoints separated and reportable (the per-firm boundary the prior RMM’s Organization model gave us; the canonical customer record now lives on the HubSpot company record — see handbook/02-technical-sops/onboarding/action1-new-customer-setup.md).
3. Create a baseline group CS-INTERNAL for CyberSuite’s own + test machines.

Part 2 — Roll out the Action1 agent (PC + Mac)

Windows (silent, machine-wide — run elevated):

1. In Action1 → Endpoints → Add Endpoints → Windows to get the org-specific install command. It is a curl download + msiexec /quiet install (machine-wide; fails silently if not elevated).
2. Push it via existing tooling, GPO, or run locally on the test PC. Confirm the endpoint appears under the right group within a few minutes.

macOS (.pkg, root):

1. Action1 → Endpoints → Add Endpoints → macOS for the .pkg + install command (sudo installer -pkg <Action1Agent>.pkg -target /).
2. The .pkg is MDM-deployable — if a Mac is already in Intune/an Apple MDM, push the Action1 agent as a managed package. Otherwise install locally on the test Mac.
3. Grant the macOS approvals the agent needs (Full Disk Access / any TCC prompts) — on MDM-managed Macs, pre-approve via an Intune/MDM PPPC profile; on unmanaged, approve manually. Confirm the Mac checks in.

Part 3 — Deploy Huntress (the EDR agent) via Action1

Action1 deploys MSI / EXE / CMD / BAT / PS1 / ZIP with silent switches — so the Huntress installer pushes unattended.

Windows:

1. Action1 → Software Repository → Add Custom Package (or App Store → custom).
2. Upload the Huntress Windows installer; set the silent install command using the ACCT_KEY / ORG_KEY from the Huntress portal (copy the exact silent string from Huntress’s “Deploy” page — don’t hardcode vendor flags here, they version).
3. Deploy the package to the customer’s Windows group. Or, if you prefer a script: Scripts → new PowerShell script that downloads + runs the Huntress installer with the keys, and run it against the group.

macOS:

1. Add the Huntress macOS .pkg as a custom package (or a shell script that writes the keys + runs installer -pkg).
2. Deploy to the customer’s Mac group.

Verify (critical): open the Huntress portal and confirm every test endpoint reports in and shows healthy. Action1 deploying it is not proof EDR works — Huntress seeing the agent is.

Part 4 — Deploy other software

• Built-in repository: pick common apps (browsers, agents, utilities) → deploy to a group; Action1 keeps them patched.
• Custom packages: MSI/EXE/PKG up to 32 GB with silent switches + EULA auto-accept (EULA_ACCEPT=YES on MSI). Use for any line-of-business or vendor agent.

Part 5 — Security configuration via scripts (the “profiles” question)

Action1 applies security settings through scripts, not enforced MDM profiles.

• Windows (PowerShell): firewall rules, registry hardening, enable/verify BitLocker (manage-bde), disable legacy protocols, baseline checks. Save reusable scripts to the repository; schedule or run on demand per group.
• macOS (shell): enable FileVault (fdesetup), firewall (socketfilterfw), Gatekeeper, baseline checks.
• Where you need enforced config-profiles (Apple Configuration Profiles, compliance, enforced FileVault that re-applies if changed): that’s Intune (Business Premium customers) — see the C-10 Endpoint Encryption SOP. For a Mac customer with no Intune, add a lightweight Apple MDM (Mosyle has a free tier) for profile enforcement.

Part 6 — Patch management baseline

Carry the established SLA cadence so coverage doesn’t regress:

1. Action1 → Automations / Patch policies → create a policy per group.
2. Cadence: Critical 7 days · High 30 · Standard 60 (matches the RMM Policy Set SOP).
3. Include third-party app patching (Action1’s strength). Set a maintenance window + reboot policy that respects the firm’s hours.
4. Mac patch limit (be honest): Action1 does app + minor macOS patching, not major macOS version upgrades or OS-vuln discovery. Track major-OS upgrades via Intune or a scheduled manual step; don’t claim Action1 covers them.

Part 7 — How we manage Macs from day 1 (summary)

Need	Tool	Day-1 status
EDR	Huntress macOS agent	✓ deploy via Action1
Inventory / patch (app+minor OS) / scripts / software / remote	Action1	✓
Enforced FileVault + config-profiles + compliance	Intune (Business Premium)	✓ where licensed
Mac MDM when no Intune	Mosyle (free tier) / Jamf	add as needed
Major macOS upgrades / OS-vuln discovery	Intune / manual	⚠️ not Action1

---

Part 8 — TEST PLAN (prove the whole stack works)

Run this POC on the test PC + test Mac before relying on Action1 for a real customer. Capture a dated pass/fail per row (this is the acceptance evidence).

#	Test	Pass criteria	Win	Mac
1	Agent enrollment	Endpoint appears in the correct CS-… group, checks in	☐	☐
2	Inventory	HW + installed-software inventory populates	☐	☐
3	Software deploy (test app)	A test app installs silently from a package	☐	☐
4	Huntress deploy	Agent installs and reports healthy in the Huntress portal	☐	☐
5	Security script	A hardening script runs; setting verified after (e.g. FileVault/BitLocker on)	☐	☐
6	Patch policy	Policy applies; a pending patch installs in the window	☐	☐
7	Remote access	Connect to the endpoint from the console	☐	☐
8	Removal/cleanup	Uninstall the test app; endpoint can be retired from the group	☐	☐

Acceptance: all 8 pass on both OSes (note Mac caveats from Parts 6–7 as expected-limits, not failures). File the completed table as the Action1 POC evidence. If any row fails, log it with the fix before using Action1 on a paying customer.

Run this alongside the SSPM/Defender POC (runbooks/sspm-defender-poc-internal-tenant.md) on the internal tenant so the full triad — Action1 + Huntress + Intune/Defender — is validated end-to-end on real PC + Mac before go-live.

Limits & honest notes

• Action1 free = ≤200 endpoints (≈ 8–10 firms) — the graduation signal, not a ceiling.
• No PSA/ticketing in Action1 — tickets stay on the shared inbox interim.
• Action1 is RMM, not MDM — enforced profiles = Intune/Mosyle.
• Mac: no major-OS upgrades / OS-vuln discovery yet.

References

• operations-only/strategy/cybersuite-stack-architecture.md — where Action1 sits (rented RMM leg).
• operations-only/strategy/syncro-decommission-and-function-map.md — what each retired Syncro function moved to.
• handbook/02-technical-sops/rmm-action1/policy-set.md — the patch SLA + Mac script-driven reality this mirrors.
• runbooks/sspm-defender-poc-internal-tenant.md — the parallel Defender/SSPM POC; run together.
• drafts/sops/endpoint-encryption.md — C-10 (BitLocker/FileVault via Intune + Action1 scripts).
• Action1 docs: agent install (Win/macOS), custom packages, patch automations.