N-central Devices

N-central Devices

Devices are the unit of inventory in N-central. Every agent- or probe-discovered endpoint — server, workstation, network device — has a device record scoped to a customer or site org unit. This skill covers listing strategy (filters vs org-unit scoping), the asset/lifecycle data model, and service-monitor triage.

Anti-triggers

• Doing something to the device — everything here reads, apart from lifecycle writes. Running a script, restarting a service, or pushing a fix is ncentral-monitoring-tasks and its direct-task tool.
• The same endpoint under a different RMM — atera-agents, syncro-assets, superops-assets, immybot-endpoint-management, ninjaone-devices, datto-rmm-devices, and connectwise-automate-computers each see only their own fleet. Watch for atera-devices in particular, where "device" means an agentless SNMP or HTTP monitor rather than an endpoint.
• Hardware refresh programmes — N-central lifecycle fields are a free-text store someone has to populate; procurement-grade planning is scalepad-lifecycle-manager.
• Which customer or site a device belongs to — org-unit resolution is ncentral-organizations.

Tools

Listing Strategy: Filters First

N-central admins maintain saved device filters in the UI ("Windows Servers", "Offline > 30 days", "Missing patches", …). These are the cheapest way to slice a large fleet server-side:

1. ncentral_list_device_filters — get the filter names and filterIds visible to the API user.
2. ncentral_list_devices with filterId — the server applies the filter; you page through only the matching devices.

Prefer this over pulling the whole fleet and filtering client-side — N-central deployments routinely exceed 10k devices, and pagination caps at 1000 per page. When the question is per-customer ("what does ACME have?"), use ncentral_list_devices_by_org_unit with the customer or site orgUnitId instead.

Assets and Lifecycle

Two different data sets, two different tools:

• Assets (ncentral_get_device_assets) — what the agent discovered: OS and version, CPU, memory, disks and free space, NICs, installed software. Refreshed by the agent's asset scan; can be stale if the device has been offline.
• Lifecycle (ncentral_get_device_lifecycle) — what a human recorded: warranty expiry date, purchase date, expected replacement date, cost, lease information. Empty unless someone (or an integration) populated it.

ncentral_update_device_lifecycle writes lifecycle fields — useful for bulk-stamping warranty expiry dates from a vendor export. It only touches the lifecycle record; it never modifies monitoring or the device itself. Still, confirm with the user before bulk updates: overwriting a populated warranty date loses data with no undo.

For warranty/refresh audits, the standard pass is: list devices for the org unit, pull lifecycle for servers and network devices, flag anything expired or expiring within 90 days, and separately flag devices with no lifecycle data at all (an untracked device is a hidden risk, not a healthy one).

Service-Monitor Triage

Each device runs a set of service monitors (agent status, disk, CPU, backup jobs, AV status, application-specific checks). ncentral_get_device_service_status returns the per-service state for one device — the drill-down after ncentral_list_active_issues tells you which devices are unhealthy:

1. Active issues sweep says device X has a failed service.
2. ncentral_get_device_service_status on X shows every monitor and its state (Normal / Warning / Failed / Misconfigured / Disconnected / Stale).
3. Distinguish real failures from data problems: Stale or Disconnected usually means the agent stopped reporting (device offline, agent broken) — every other monitor on that device is untrustworthy until the agent checks in. Misconfigured is a setup error, not an outage.

Best Practices

• Resolve filterId by listing filters first — filter IDs differ per server; never hardcode them.
• Asset scan timestamps matter: quote when the asset data was collected if the device looks offline.
• Lifecycle updates are writes — echo the before/after values and get confirmation before applying them in bulk.
• Device IDs are per-server. When correlating with PSA or documentation tools, match on hostname/serial, not ID.

Related Skills

• api-patterns - pagination, filters, rate limits
• organizations - org-unit scoping for device lists
• monitoring-tasks - active issues that lead into device triage