tatersecurity.com Open App

FAQ & Troubleshooting

Answers to common questions and solutions for typical issues with TATER.

General Questions

What is TATER?

TATER (Threat Analysis Targeting Enterprise Resources) is a multi-tenant compliance management platform for Microsoft 365 and endpoint environments. It automates security auditing against CIS Benchmarks, CISA SCuBA, DISA STIGs, and custom frameworks.

Which compliance frameworks does TATER support?

TATER supports CIS Benchmarks (M365, Windows 11, Server 2019/2022/2025, Edge, Intune), CISA SCuBA, DISA STIGs, and maps to NIST 800-53, ISO 27001, SOC 2, PCI DSS, HIPAA, and GDPR. See Frameworks & Standards for details.

How many controls does TATER evaluate?

Over 4,000+ controls across 19 frameworks, plus dynamic vulnerability controls from MDE endpoint scanning.

Does TATER support multi-tenant environments?

Yes. TATER is designed for multi-tenant use. MSPs and organizations with multiple M365 tenants can manage each tenant independently with separate scan results, overrides, and reports.

Authentication

I cannot sign in. What should I check?

  • Verify your Entra ID app registration has the correct redirect URIs
  • Ensure the app registration includes app.tatersecurity.com in redirect URIs
  • Clear browser cache and cookies, then try again
  • Check that your account has been added to an organization in TATER
  • Verify popup blockers are not blocking the MSAL authentication popup

I get 401 Unauthorized from the API

  • Your JWT token may have expired. Sign out and sign back in.
  • The API accepts both raw GUID and api:// prefixed audience formats
  • For runbook authentication, ensure the API key is correctly configured

Scanning Issues

My scan shows no controls

  • Verify the scan script completed without errors
  • Check the output JSON file exists and contains control data
  • Ensure you are importing the correct file format

Scans time out on large tenants

Large M365 tenants may require 30+ minutes. Increase the timeout parameter in the scan script. For Azure Automation, the default timeout is 3 hours.

Why do Teams controls show SKIP?

Teams Cs* cmdlets require delegated authentication, which cannot be automated in Azure Automation runbooks. Approximately 36 Teams controls permanently return SKIP status. This is a known platform limitation.

Endpoint scan runs out of memory

The MDE bulk vulnerabilities endpoint can cause out-of-memory in Azure Automation's ~400MB sandbox. The Scan-Endpoints runbook uses per-machine vulnerability queries with deduplication to avoid this.

Dashboard Issues

Dashboard shows no data

  • Ensure at least one scan has been imported
  • Check that you are viewing the correct organization
  • Verify your user account has appropriate permissions (at least Viewer role)

Trend chart looks flat

The trend chart needs multiple scans over time to show meaningful trends. Run scans regularly (daily or weekly) to build up historical data points.

Compliance score seems wrong

  • Check if overrides are affecting the score (overridden controls show as "Override" not "Fail")
  • Verify the correct compliance zones are configured (unchecked zones exclude controls)
  • Check the Framework Category filter (Compliance vs. Vulnerability views show different metrics)

Data looks stale - how do I refresh without reloading the browser?

Click the ↺ circular arrow button in the topbar (between the bug report icon and the dark/light mode toggle). It re-fetches and re-renders the current page's data in-place without losing your scroll position or navigation state. This is useful after a scan completes, after another user makes changes, or any time you want the latest data without a full page reload.

Open the record (e.g., a specific risk, POAM, audit, vendor, wiki page, ConfigDoc, etc.) so its detail view is on screen. Click the 🔗 chain-link button in the topbar - the shareable URL is copied to your clipboard with a toast confirmation. Paste it anywhere; the receiver's browser will land on the same record after sign-in.

Keyboard shortcut: Shift+L from anywhere except text inputs. Works in TATER Security, TATER Ops, TATER Manage, and My TATER - each app's topbar has the same icon.

If you're on a list page (Risks, POAMs, Audits, etc.) without a record selected, the button copies a link to the list itself. If you're on a detail page but haven't selected a specific record, the button refuses to copy and toasts "No record selected on this page".

MCP-driven tools (Claude, Copilot) include these same links automatically in their responses after a create/update - so when an AI agent reports "I created a risk acceptance, here's the link," clicking it lands on the record.

How do I quickly jump between pages?

Press Ctrl+K (Cmd+K on Mac) from anywhere. In TATER Ops, TATER Manage, My TATER, and TATER Insights this opens a command palette: start typing the name of any page in the sidebar, use the arrow keys to highlight it, and press Enter to jump there - Esc closes it. In TATER Security the same shortcut opens the fuller search overlay (recent pages, quick actions, and cross-record search). It's the fastest way to move around without hunting through the sidebar.

Remediation

Remediation button does nothing

  • Ensure remediation is enabled for your organization in Organization Settings
  • Verify the remediation webhook URL is configured correctly
  • Check that the remediation catalog has entries matching your failing controls
  • Confirm the Azure Automation Account is running and accessible

Exchange remediation fails

Exchange Online remediation requires the PS 5.1 companion runbook. Verify that Run-Remediation-EXO is published in your Automation Account and that the ExchangeOnlineManagement module (v3.4.0+) is installed.

Agent Issues

Agent cannot connect to API

  • Verify the API base URL includes the /api suffix
  • Check network connectivity and firewall rules for HTTPS (port 443)
  • Verify the Organization ID is valid
  • Test connectivity by opening https://api.tatersecurity.com/api/agent/version in a browser

Agent auto-update fails

Check that the download URL is accessible. CRLF line ending issues during SWA deployment can cause SHA-256 hash mismatches. Re-deploy the MSI to fix hash verification.

Device shows Offline forever even though the agent service is running

Before v2.4.11, the agent only wrote diagnostics to /api/agent/diagnostics when an operator explicitly ran tater-agent.exe -diagnostics or hit the local-dashboard diagnostics button. The Devices page in Ops + Manage reads agentVersion, lastLoggedInUser, runAt, and Online status from that record - so every fielded device showed Offline forever (no version, no last-user, no compliance) once the install-time diagnostic aged past 90 minutes, even though the agent was actively scanning and uploading.

Fix: upgrade to agent v2.4.11+. v2.4.11 adds a background heartbeat goroutine that runs diagnostics + POSTs to /api/agent/diagnostics every 30 minutes (60 s after startup so the initial scan can flow first). The Devices page's 90-minute Online window receives 3 heartbeats per cycle, so devices stay accurate. Wired into both service mode and interactive/tray mode - idempotent, no operator action needed. Verify on a sample device: check the Devices page 60–90 minutes after the v2.4.11 upgrade and the agentVersion / lastLoggedInUser / Online status should populate without intervention.

Devices page shows only 50 devices (or fewer than expected)

Fixed in 2026-05-29. GET /api/agent/diagnostics previously hardcoded OFFSET 0 LIMIT 50 before deduping to one row per device. With the v2.4.11 heartbeat goroutine POSTing every 30 minutes, 50 reports covered only the most active ~10–15 devices' latest few heartbeats - so any fleet bigger than ~20 devices silently dropped endpoints from the Devices / Fleet list in both TATER Manage and TATER Security.

Fix: the default report window is now 1000 (configurable via ?limit=N, 1–5000), and the projection is tightened to fleet-card fields only so the larger window still fits in the Functions response budget. A 100-device fleet now has ~5 hours of heartbeat history captured per device in the dedup window - comfortably enough to surface every endpoint.

Sentinel for very large fleets: the response includes a new _meta block with reportsScanned, limit, and truncated. If you see "truncated": true when curling the endpoint, the fleet outgrew the dedup window - bump the limit explicitly:

curl -sH "Authorization: Bearer $JWT" -H "X-Organization-Id: $ORG_ID" \
  'https://api.tatersecurity.com/api/agent/diagnostics?limit=5000' | jq '._meta'

No client change required - both the Manage Devices page and TATER Security Fleet page consume the same devices[] array and will surface the full fleet on the next API deploy.

Tray icon disappears after a binary swap or update

Before v2.4.10, swapping the agent binary (or any in-place update) required the logged-in user to sign out and back in before the tray reappeared. v2.4.10+ includes a service-mode goroutine that spawns the user-session tray via the WTSGetActiveConsoleSessionId / WTSQueryUserToken / CreateProcessAsUserW pattern (same Win32 APIs PsExec uses). It runs at service startup and every 15 minutes, idempotent - skips spawning if a tray is already running. All future binary swaps recover within ~15 minutes without requiring user logout.

What does Verify-TATERAgent.ps1 check, and how do I run it?

Verify-TATERAgent.ps1 is the field-tested health check + self-healing script for any TATER-deployed Windows machine. It runs 8 checks (filesystem, binary version, configuration, service status, process instances, network reachability, recent activity, summary). With -Fix, it auto-heals common drift: dead apiBase URL (rewrites config.json + restarts service), stale binary version (force-replaces via SHA-verified binary swap), stopped service (starts it), and multiple tray instances in one session (kills duplicates).

Standard run (any user, no elevation):

iwr https://www.tatersecurity.com/Agent/Verify-TATERAgent.ps1 -UseBasicParsing -OutFile $env:TEMP\Verify.ps1
powershell.exe -ExecutionPolicy Bypass -File $env:TEMP\Verify.ps1

With auto-fix (elevated PowerShell required):

powershell.exe -ExecutionPolicy Bypass -File $env:TEMP\Verify.ps1 -Fix

Exit codes: 0 = healthy, 1 = problems found (read the report), 2 = TATER agent not installed.

Agent is stuck on a pre-v2.4.6 version and won't auto-update

Per ADO #569, every agent build prior to v2.4.6 has the auto-update endpoint URL hardcoded to func-tater-api-prod.azurewebsites.net - the API host that was decommissioned during the tenant migration. These agents cannot self-heal because their first DNS lookup for the version-check call returns no-such-host. Force-upgrade them via Verify-TATERAgent.ps1 -Fix (it detects the version, downloads the current binary, SHA-verifies, and replaces in place):

Remove-Item $env:TEMP\Verify.ps1 -Force -ErrorAction SilentlyContinue
iwr https://www.tatersecurity.com/Agent/Verify-TATERAgent.ps1 -UseBasicParsing -OutFile $env:TEMP\Verify.ps1
powershell.exe -ExecutionPolicy Bypass -File $env:TEMP\Verify.ps1 -Fix

After force-upgrade, the agent has the auto-update foreign-platform-tolerance fix from v2.4.9+ and will self-heal for all future version bumps.

Agent shows healthy locally but uploads nothing to TATER

Most common cause: the agent's config.json apiBase still points at the decommissioned func-tater-api-prod.azurewebsites.net URL from before the tenant migration. The agent's scan loop runs locally, writes log files, but every API call fails silently (DNS no-such-host). Two telltale signs:

  • last-upload.json sentinel is missing OR very old (the agent only writes it on successful upload)
  • C:\ProgramData\TATER\Logs\TATER-Agent_*.log shows Get "https://func-tater-api-prod.azurewebsites.net/...": dial tcp: lookup ... no such host

Fix: run Verify-TATERAgent.ps1 -Fix from an elevated PowerShell - the script detects the dead URL, rewrites config.json apiBase to https://api.tatersecurity.com/api, restarts the service, and (if also stale) force-upgrades the binary. Both fixes happen in one run. Per ADO #569.

.intunewin download is tiny (~6 KB) and Intune rejects it

You downloaded the SWA's 404 HTML page with a .intunewin extension. The SWA's incremental sync occasionally leaves /Agent/* URLs 404 for 5-15 minutes after a TATER release deploy. Three remedies, in order of preference:

  1. Verify the SHA before uploading: (Get-FileHash TATER-Agent.intunewin -Algorithm SHA256).Hash. The .intunewin should be ~5.5 MB; the 404 HTML is ~6 KB.
  2. Wait 5-15 min and re-download - the SWA edge typically catches up.
  3. Pull from the source of truth in your local TATER repo clone: C:\path\to\TATER\Agent\TATER-Agent.intunewin (or C:\path\to\TATER\Installer\bin\IntuneWin\TATER-Agent.intunewin - both identical).

Intune install fails with exit code 1603 after a successful auto-update

Per ADO #568, the agent's in-place auto-update replaces tater-agent.exe without going through Windows Installer. After that, any msiexec /i repair triggers SECUREREPAIR validation which fails because the on-disk binary doesn't match what MSI's cached source expects. Two workarounds:

  • Avoid MSI repair entirely for version upgrades - use Verify-TATERAgent.ps1 -Fix instead. The script's binary-swap path matches the agent's own auto-update mechanism so MSI's database doesn't matter.
  • For Intune Detection rule: use File exists at C:\ProgramData\TATER\tater-agent.exe (NOT MSI product code, and NOT C:\Program Files\TATER). The MSI roots [TATERDIR] at %ProgramData%\TATER via CommonAppDataFolder; any Win32 app reporting "failed to detect" almost certainly has the rule pointed at Program Files from older guidance. The file-existence rule survives auto-updates; the product-code rule breaks after the first one.

Deployment Issues

Intune Win32 app reports "failed to detect" after every install

Almost always the detection rule is pointed at the wrong path. The TATER MSI installs tater-agent.exe to C:\ProgramData\TATER\ (rooted via CommonAppDataFolder\TATER in Installer/Directories.wxs line 8). It does NOT install to C:\Program Files\TATER. If your Intune detection rule says C:\Program Files\TATER\tater-agent.exe, Intune will see "file missing" after every successful install and report the deployment as failed forever, even while the agent runs normally on the endpoint.

Fix: change the detection rule to:

  • Type: File
  • Path: C:\ProgramData\TATER
  • File: tater-agent.exe
  • Method: File or folder exists

Update the rule in the existing app assignment - you don't need to rebuild the .intunewin package or rotate the API key. Endpoints will flip from Failed to Succeeded on their next Intune compliance check (usually within 60 minutes, faster after a manual sync from Settings > Accounts > Access work or school).

SWA deployment hangs

The swa deploy CLI can hang when run from Git Bash on Windows. Use PowerShell for SWA deployments instead.

API deployment returns errors

  • Run cd api && npx tsc --noEmit to check for TypeScript compilation errors
  • Verify all environment variables are set on the Function App
  • Check that the database is accessible from the API

Performance

Dashboard loads slowly

  • Large datasets (thousands of controls across many scans) can slow initial load
  • Use framework and status filters to reduce the displayed data set
  • Ensure you have a stable internet connection to the API
  • Modern browsers with at least 2GB RAM recommended

Getting Help

If your issue is not covered here:

  • Review the relevant guide page in this documentation
  • Check Azure Automation job output for runbook errors
  • Review browser developer console (F12) for frontend errors
  • Contact support at support@tatersecurity.com