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.comin 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.
How do I share a link to a specific record?
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
/apisuffix - 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/versionin 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.ps1With auto-fix (elevated PowerShell required):
powershell.exe -ExecutionPolicy Bypass -File $env:TEMP\Verify.ps1 -FixExit 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 -FixAfter 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.jsonsentinel is missing OR very old (the agent only writes it on successful upload)C:\ProgramData\TATER\Logs\TATER-Agent_*.logshowsGet "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:
- 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. - Wait 5-15 min and re-download - the SWA edge typically catches up.
- Pull from the source of truth in your local TATER repo clone:
C:\path\to\TATER\Agent\TATER-Agent.intunewin(orC:\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 -Fixinstead. 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 NOTC:\Program Files\TATER). The MSI roots[TATERDIR]at%ProgramData%\TATERviaCommonAppDataFolder; any Win32 app reporting "failed to detect" almost certainly has the rule pointed atProgram Filesfrom 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 --noEmitto 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
TATER