Platform Foundations

Build the mental model before memorizing features.

35 min3 lessons3 retrieval drills

The promise

What you will be able to do by the end of this module

Explain the assignment model on a whiteboard without notes, and answer the question that ends most technical evaluations: when two settings disagree, which one wins and why.

Name the four policy types — Agent, NMS, VM, MDM — and say which one a customer's switches, hypervisors, and phones each fall under.
Explain the Organization → Location → Device precedence chain and why the most specific assignment wins.
State the one-policy-per-device constraint from memory and defend it as determinism rather than apologise for it as a limitation.
Describe how Parent Policy inheritance keeps a single-policy model from exploding into hundreds of unrelated copies.
Answer a security team's transport question accurately — outbound TCP 443, no inbound listener — including the third-party patch fallback that makes a flat '443 only' claim wrong.

Start from what you already know

If you have debugged conflicting Group Policy Objects, you already understand the problem this solves. GPO merges multiple objects and resolves conflicts through precedence you have to reason about. NinjaOne takes the opposite approach, and the consequence of that choice shapes every design you will propose.

The 30-second model

Endpoint telemetry becomes governed action

A lightweight agent sends device data to the NinjaOne cloud platform and receives approved actions. Technicians organize devices, apply roles and policies, watch conditions, automate repeatable responses, and step in when human judgment is needed.

Organizations and locations establish administrative scope.
Device roles describe what a device is and influence policy.
Policies express desired monitoring, patching, automation, and configuration behavior.
Conditions turn telemetry into alerts, tickets, or automated remediation.

Verified sourcesNinjaOne product FAQ ↗NinjaOne Academy curriculum ↗NinjaOne Endpoint Management ↗

Hierarchy

Role, policy, inheritance, override

The critical design question is not 'what setting exists?' It is 'where should this control live so it scales safely?' Start broad, inherit by default, then introduce narrowly justified overrides.

Use roles to group devices by operational purpose.
Use inherited policies for standardization.
Treat overrides as managed exceptions with an owner and expiration.
Separate monitoring intent from remediation risk.

Field move

Draw the hierarchy and explain how you prevent configuration drift across thousands of endpoints.

Verified sourcesNinjaOne Academy curriculum ↗

Design principle

Automate the known; escalate the ambiguous

Good endpoint automation has a clear trigger, bounded action, evidence, error handling, and a safe path when the condition is not understood. The goal is repeatability, not automation theater.

Start with observable signals and a reversible action.
Log results into activities, fields, tickets, or reports.
Use maintenance windows and rollout rings for disruptive changes.
Keep a technician approval point where business impact is uncertain.

Verified sourcesNinjaOne Academy curriculum ↗NinjaOne Endpoint Management ↗

Mechanics

How it actually behaves

Each item is tagged with how far it can be trusted. Verified means checked against official documentation; field means it is our recommendation, not a vendor claim; unpublished means NinjaOne does not state it at all.

Four policy types, not one

verified

Agent policies cover Windows, macOS and Linux endpoints running the agent. NMS policies cover agentless network devices via SNMP/ICMP. VM policies cover virtualization hosts and guests. MDM policies cover Android, iOS and iPadOS without an agent. A customer asking 'can you manage our switches' is asking about a different policy type, not a feature flag.

Verified sourcesNinjaOne policies: types, inheritance, and assignment ↗

A device can hold exactly one policy at a time

verified

There is no merge, no stacking, no additive layering. The effective policy is a single object. This is the single most important design fact in the platform and the one most SEs get wrong in front of a customer.

Verified sourcesNinjaOne policies: types, inheritance, and assignment ↗

Precedence is Organization, then Location, then Device

verified

Location assignment overrides organization assignment. Device assignment overrides both. Most specific wins, and because only one policy is ever in effect, the answer to 'why is this machine behaving this way' is always a single object you can open.

Verified sourcesNinjaOne policies: types, inheritance, and assignment ↗

Inheritance happens at authoring time via a Parent Policy field

verified

You build variation by creating a child policy from a parent and changing only what differs. This is the mechanism that keeps a single-policy model from exploding into hundreds of unrelated copies — the relationship is explicit rather than computed at evaluation time.

Verified sourcesNinjaOne policies: types, inheritance, and assignment ↗

Agent transport is outbound HTTPS on 443

verified

No inbound port, no listening service to expose, no VPN dependency. A laptop in an airport is as manageable as one in the building. Port 80 is used only to answer an initial request and immediately redirect to 443.

Verified sourcesNinjaRMM firewall allow list (partner mirror of the NinjaOne global allowlist) ↗mirror

Not an official source: NinjaOne's canonical allowlist article (ninjarmm.zendesk.com/hc/articles/211406886) requires an authenticated support account and returns HTTP 403 to anonymous requests, so it could not be cited directly. This is a partner's published mirror of that list. Treat the hostnames as a starting point and re-verify inside your own tenant before handing them to a network team.

The 443-only claim has one real exception

verified

Where a third-party vendor only publishes update payloads over anonymous FTP or HTTP, the agent may fall back to 21/FTP or 80/HTTP after repeated HTTPS attempts fail. Disclose this before a proxy team discovers it.

Verified sourcesNinjaRMM firewall allow list (partner mirror of the NinjaOne global allowlist) ↗mirror

Discovery

Ask these, then listen

“When one site needs a different setting, what happens today?”

Listen for: 'We clone the GPO' means exception sprawl. Ask how many exist and who retires them.

“Who is allowed to create an exception?”

Listen for: 'Only the platform team' is a bottleneck you can price. 'Anyone with admin' is a governance finding worth naming out loud.

“If I picked a random laptop, could you tell me every setting applied to it and why?”

Listen for: Hesitation is the opening. Single-policy determinism is the answer, and it is a real one.

Demo path

Three moves, in this order

1
A parent policy and a child that changes two settings.
“Variation is authored, not computed. You can see exactly what differs.”
2
The same device viewed from organization, location, and device scope.
“Three places you could assign, one that actually wins. Most specific.”
3
The effective policy on a single device.
“One object. This is the whole answer to 'why is this machine like this'.”

Objection handling

What they say, what you say, how you prove it

“One policy per device is less flexible than layering.”

It trades compositional flexibility for determinism. You give up clever stacking and you get an answer to 'why' that takes one click instead of an afternoon.

Proof method: Ask them how long it took to debug their last GPO precedence problem. That number is the value.

“Our security team will not allow a cloud control plane.”

The agent is outbound-only on 443 with no inbound listener. That is usually a narrower ask than the VPN or jump-host model they already run.

Proof method: Walk the allowlist with their network team early. Include the FTP/HTTP patch fallback so nothing surfaces late.

Where SEs blow it

Do not say these

Do not say policies 'merge' or 'stack'. They do not, and a technical evaluator will catch it.
Do not describe device role and policy as the same thing. Role describes what a device is; policy describes how it behaves.
Do not promise 443-only without the third-party patch caveat.

From NinjaOne's channel

Watch it explained

Short clips from NinjaOne's own channel that reinforce the mechanics above. Each one says why it is here and what it backs up. These are supporting context, not product demonstrations — the sourced claims stay in the mechanics section.

Why this is here: The sense-decide-act-prove loop, and why the console is a control plane rather than a dashboard.Watch on YouTube ↗

Why this is here: Scope is a governance decision before it is a product decision — the same argument as the Organization / Location / Device hierarchy.Watch on YouTube ↗

Why this is here: Orientation to the agent-plus-console model before the policy mechanics land.Watch on YouTube ↗

Retrieval practice

Rapid fire

Answer aloud before opening each response.

01What does the agent do?

It sends endpoint data to the cloud platform for analysis and receives actions for execution.

02Policy or script?

A policy expresses ongoing desired behavior; a script is one automation mechanism used to achieve an outcome.

03Why inheritance?

It makes a standard scalable while preserving controlled exceptions.