TATER Tuning — M365 Tenant Tuning Setup

What this is

The TATER Tuning page (Security → TATER Tuning) shows two kinds of columns:

Device-scoped (chrome, edge, defender, office, windows, ux) — enforced by the Go agent running on each Windows endpoint. The default flow.
Tenant-scoped (defender-m365, exchange-m365, sharepoint-m365, entra-m365, power-bi, purview, teams-m365, power-platform) — tagged ☁ tenant. Enforced against the M365 tenant via the Run-Tenant-Tuning runbook in Azure Automation.

Both column types share the same dial UX, the same level-up workflow, and (after rollout) the same Phase 6 self-healing loop (drift detected → MonitoringFinding open → clears auto-resolve the next cycle).

Rollout checklist

This needs to be done once per tenant (i.e. per Caron Bletzer, per TATER Security, etc.). After it's wired, every dial change on a tenant column gets enforced automatically on the next runbook cycle.

Prerequisites

Tenant scanning is already configured (the Scan-M365Cloud runbook works for this org).
You have an API key bound to the org. If you don't, generate one at TATER Manage → Connections → API Keys.
The org's Automation Account (e.g. aa-tater-prod for TATER Security, aa-tater-cb for Caron Bletzer) is up and the Managed Identity has Storage Blob Data Reader on the sttatersectater account.

Step 1 — Upload the runbook

From the repo:

az automation runbook create \
  --name "Run-Tenant-Tuning" \
  --resource-group rg-tater-prod \
  --automation-account-name <aa-name> \
  --type PowerShell \
  --runbook-content @Runbooks/Run-Tenant-Tuning.ps1

az automation runbook publish \
  --name "Run-Tenant-Tuning" \
  --resource-group rg-tater-prod \
  --automation-account-name <aa-name>

Step 2 — Set the OrgName variable

The runbook needs to tag findings with a human-readable label (e.g. "Caron Bletzer"). The other vars (ApiBaseUrl, ApiKey, StorageAccountName, KeyVaultName, CertName, AppClientId, TenantDomain, OrganizationId) are inherited from your existing Scan-M365Cloud setup.

az automation variable create \
  --name "OrgName" \
  --resource-group rg-tater-prod \
  --automation-account-name <aa-name> \
  --value "Caron Bletzer"

Step 3 — Schedule daily

Daily at 4 AM ET (an hour after Scan-Endpoints, two after Scan-M365Cloud):

az automation schedule create \
  --name "daily-tenant-tuning" \
  --resource-group rg-tater-prod \
  --automation-account-name <aa-name> \
  --frequency Day --interval 1 \
  --start-time "2026-06-10T04:00:00-04:00"

az automation runbook schedule link \
  --runbook-name "Run-Tenant-Tuning" \
  --schedule-name "daily-tenant-tuning" \
  --resource-group rg-tater-prod \
  --automation-account-name <aa-name>

Step 4 — Test fire

Trigger the runbook once manually:

az automation runbook start \
  --name "Run-Tenant-Tuning" \
  --resource-group rg-tater-prod \
  --automation-account-name <aa-name>

Watch the job in Azure Portal. The output stream should show:

[TenantTuning] Org <orgId> has N tenant apps configured.
[TenantTuning] Graph connected.
[TenantTuning] EXO connected.
[TenantTuning] SPO connected.
─── [defender-m365] Level 2 — 5 script(s) ───
  Running REM_DEF_SafeLinks.ps1 ...
  ...
[TenantTuning] State accepted. findingsCreated=0 findingsResolved=0
[TenantTuning] Done.

What you'll see in TATER after the first run

TATER Tuning matrix: cells turn from "dial set but not enforced" to "applied" once the runbook reports state.
Application Monitoring: Hardening Drift KPI starts counting tenant-scoped findings alongside device ones. The top-3 chip strip lumps the worst drifted controls across both.
Manage → Devices: a synthetic row for "M365 Tenant (<orgName>)" surfaces if there's drift. The Tuning column shows tenant app levels.

How drift detection works for tenant cells

Same 3-consecutive-cycles rule as device drift. A control failing enforcement on day 1 just gets logged. Day 2, logged. Day 3 — MonitoringFinding opens at the appropriate severity (Defender + Entra = High; Exchange + SharePoint = Medium; Power BI / Purview = Medium; Teams / Power Platform = Low). When the runbook reports clean on a subsequent day, the finding auto-resolves.

Risk-accept overrides on tenant cells

Identical workflow to device cells: open the cell, list the control id (the REM filename without .ps1) in the Risk-accept overrides section, add a reason and expiry. The runbook skips it on the next cycle and any open finding resolves the cycle after.

Limitations today

Teams dial stays at L0/L1 guidance-only. Cs* cmdlets require delegated auth (cannot run in app-only context); this is a platform limitation, not a TATER one.
Daily cadence — tenant cells take up to 24h to surface drift (vs. the 30min poll on device cells). Run more frequently if your tenant moves fast.
One tenant per Automation Account — MSP scenario where you'd run multiple client tenants from one Automation Account isn't supported today (the runbook is single-tenant by design).

Last updated 2026-06-09