Huntress operations

Onboarding is the part of the platform where mistakes touch commercials. Runbook execution stays on the helpdesk floor; subscription, product-mix, and deployment-strategy decisions bump every time.

The org record is the spine every onboarding step hangs off. Get the name, branding, and notification routing right from the runbook before you click save, then verify the blank state catches the wrong-tenant or duplicate-onboarding signal.

Two integration paths exist. Direct per-tenant Global Admin consent or GDAP/CSP via Partner Center. Your MSP uses one; the runbook says which. Many MSPs reserve the connection step itself for senior staff because of the permissions involved.

Same back-end model as M365, different integration path. Super-admin role, Google OAuth consent, and sometimes a domain-wide-delegation step in the Admin console. Don't run the M365 runbook with names swapped.

Bulk rollout is where one mistake hits the most endpoints fastest. The runbook owns scope and timing; you own the running, the monitoring, and the gap between RMM success and portal enrolment.

Endpoints, identity, and SIEM all need verification, not just the agent count. Green status on an integration is necessary, not sufficient. Run the reconciliation at 24 hours and again at 48.

A new customer typically generates a Low-severity wave for one to two weeks as the SOC learns their environment. Two opposite failure modes are reacting too hard and suppressing the queue to clear it. The middle path is the standard Low workflow, on each one, every time.

Six steps, in order. Pause alerts, disconnect ITDR, bulk uninstall, disconnect SIEM, archive incidents, raise the billing-closure ticket. Permanent org deletion is not in scope.

The mirror image of bulk rollout, with a sharper failure surface. RMM success is not portal disappearance. Distinguish slow from resistant; resistant agents get per-endpoint follow-up, not bulk re-push.

The step half-done offboardings most often skip. Each connected tenant gets its own disconnect; if both M365 and Workspace were connected, both need cutting. Verify no events arrive in the 24 hours after.

Six final-state targets. The discipline is the physical checklist, ticks are honest. Permanent org deletion is not on the list, the senior owns it.

A mental model of what the Huntress agent collects and where it sends telemetry. Installation and registration are two separate steps that fail separately. Carry the split into every diagnostic that follows.

The daily reflex for new laptops, replacement workstations, and rebuilt servers. Five-minute job when pre-flight is done; a long week when the RMM exit code gets trusted as the final word.

The most common install-failure cause. The right fix is documented exclusions pushed via the AV management console, not disabling AV. The customer's IT shouldn't have to know the agent's install was bumpy.

Policy blocks look like AV blocks on the install log, but the fix lives in GPO, MDM, AppLocker, or WDAC. Reading the system event log alongside the install log is what separates them.

Sometimes the right answer is "this endpoint can't be covered." The supported-platforms list is the bright line. A missing dependency on a supported OS is a routine fix; an unsupported OS is a senior conversation, not a different install attempt.

Where install-vs-registration matters most. The install completes cleanly; the RMM exits zero; the agent service starts. And the portal shows nothing because the agent can't reach Huntress to register.

Agent offline is one status hiding four different problems with four different fixes. A two-question diagnostic separates them in under a minute. Skipping it is the most common reason offline-agent work takes an hour instead of ten minutes.

Backlogs are a category problem disguised as a count problem. Categorise first, batch only within a category, document each endpoint. The customer wants the count down for the right reason, not cosmetically.

The agent self-upgrades. When it doesn't, the cause is almost always one of the install-failure causes coming back on a different operation. Manual upgrades treat a symptom; the fix lives in the original cause.

The daily mirror of single-endpoint deploy. The portal's organisation-specific uninstall key authorises the removal cleanly. Verify both ends of the uninstall (portal and endpoint) before closing the ticket.

Two paths, two outcomes. Move-in-place preserves telemetry continuity; uninstall-and-re-install gives a clean break. The runbook decides; rules of thumb apply when the runbook doesn't cover.

Six discrete steps from notification to closure for every routine Low or High EDR Incident Report. Claim, review, approve remediations, verify, close, document — the spine the rest of the EDR arc hangs on.

What the autoruns remediation does on the endpoint, what it doesn't do, how to verify it cleanly, and the re-detection pattern that turns a routine approve into a containment-and-escalate call.

Three more remediation types, each with a different blast radius. Scheduled tasks are bounded; services stop a running process; file removals depend on the file's role. Diligence on review and verify scales with what gets touched.

Isolation cuts the endpoint's network at the agent, with a documented allow-list. Local stays working. Knowing what the user will experience is what makes the customer call survivable.

Severity and the Recommendation decide. Critical and isolation-recommended High mean isolate first, then call. High without isolation and Low mean don't add it. The 30-second-vs-30-minute trade is the whole game.

Un-isolation is the easiest action in the portal to click and the hardest one to do correctly. A five-item recovery checklist walked before the click is what separates fast triage from fast triage that holds up.

Four sections, every time. What you did, what you verified, who you contacted with names and times, open items. The note is for the next reader; the cold-read test is the standard.

Two systems hold the work — Huntress and the PSA. Closing one and not the other is the cardinal drift trap. Six small close-out steps, takes two minutes, prevents the most common helpdesk pattern in the EDR arc.

The whole EDR machine working together on a routine Low. Eleven minutes, six steps, no surprises. The rhythm is the point; the components are familiar by now.

A Low plus tighter SLA, paired actions (often isolation), and the customer call. Components are the same; tempo, coordination, and stakes differ. Twenty-eight minutes, six steps, one isolate-then-call cycle.

Four markers tell you the response model has flipped, ransomware canary trip, mass deletion, lateral movement, admin-credential abuse. Recognise the shape and you switch from triage to contain-and-escalate before the severity tag confirms it.

A canary trip is unambiguous, either a decoy file was touched or it wasn't. See the trip, isolate inside 60 seconds, escalate in parallel. Investigation of the canary is for after, and not by you.

Contain, escalate in parallel, do not investigate. One rule across five branching shapes, single-host, multi-host, identity, mixed, and re-detection. The branching is what you contain and who you call, not whether you switch into the reflex.

Two failure modes appear in new techs on Critical, freezing and overstepping. The line is sharp, containment is in scope, investigation is not. The map below is the one to carry.

Legitimate admin tools and attacker tradecraft look identical at the OS level. The SOC weighs context the OS can't see; the tech reads the Recommendation, not the pattern.

Exclusions are persistent suppression of a detection pattern. Done right they reduce noise; done wrong they create blind spots. Four conditions gate "appropriate", and customer pressure isn't one of them.