Skip to content

Device Enrollment

This tutorial explains how to process device enrollment requests, associate approved devices with people, and verify that the resulting ownership mappings satisfy the deployment connectivity gate.

Concepts overview

Before diving into steps, understand the two key identifiers:

Term What it is Where it comes from
Device Key A unique string identifier for a device within the Policy Manager Automatically generated by ntkDrive on first registration
Peer ID The 32-character hex identity string for a person in the Policy Manager Assigned when you create a person record in ntkDeploy

Enrollment is the process of associating a device key (from a real Windows machine running ntkDrive) with a person's Peer ID. Once this mapping exists — called an Ownership Mapping — the deployment preflight can confirm that every target device has a known owner, which is required before any artifact can be written.

Prerequisites

  • The Policy Manager endpoint is configured and healthy. Open Settings, verify the URL, and click Validate.
  • At least one person record exists in the People registry — see Managing Policies — Adding a person.
  • ntkDrive is installed on the target device(s) and has contacted the Policy Manager at least once to create an enrollment request.

Step 1 — Navigate to the Enrollment Queue

  1. Click Policy in the sidebar.
  2. Click the People tab.
  3. Inside the People section, click the Enrollment Queue sub-tab.

The Enrollment Queue lists all pending enrollment requests received from devices running ntkDrive. If the queue is empty and you expect requests, click Refresh to reload from the Policy Manager.

Step 2 — Understand the queue columns

Each row in the Enrollment Queue represents a single enrollment request from a device:

Column Description
Display Name The device's self-reported display name
Peer ID The 32-character hex Peer ID that the device is requesting — this must match a person record before the device can be deployed to
Org Unique ID Optional organization-specific identifier reported by the device
Pending Fingerprint A truncated certificate fingerprint authenticating the device's key pair. Click the copy icon to copy the full fingerprint for external verification.
Requested At Timestamp of the enrollment request
Actions Approve (check), Reject (×), Inspect (eye) buttons

Step 3 — Inspect a request

Before approving, verify the request is legitimate:

  1. Click the Inspect icon (eye) in the Actions column, or click anywhere on the row. A detail dialog opens showing the full enrollment request fields including the complete certificate fingerprint.
  2. Compare the fingerprint with the device certificate on the target machine:
  3. On the Windows device, check the ntkDrive configuration or the device certificate store.
  4. Confirm the Org Unique ID matches your asset management system record for that device.
  5. Dismiss the dialog.

Security Note: Approving an enrollment request grants that device's Peer ID the ability to participate in deployments. Always verify fingerprints before approving, especially in production environments.

Step 4 — Approve an individual request

  1. Locate the row for the device you want to enroll.
  2. Click the Approve icon (check mark). The row is removed from the queue and the device key fingerprint is associated with the matching person record in the People registry.
  3. Navigate to the People sub-tab and find the person whose Peer ID matched the request. Their Enrollment column should now show Enrolled (shield icon, blue).

What happens on approval: The Policy Manager links the device's certificate fingerprint to the Peer ID in the person record. ntkDeploy stores this as a deviceKeyFingerprint on the person. This fingerprint is what the connectivity gate checks at preflight time.

Step 5 — Approve multiple requests in bulk

When multiple devices need to be enrolled at once:

  1. Check the checkbox on each row you want to approve. The toolbar button updates to Approve Selected (N) where N is the number checked.
  2. Click Approve Selected (N) to process all selected requests in one operation.
  3. After the bulk operation completes, the approved rows disappear from the queue. Any failures are reported in a snackbar message.

Step 6 — Reject a request

If a request is from an unknown or unauthorised device:

  1. Click the Reject icon (×) in the Actions column.
  2. The request is removed from the queue and the device's Peer ID is not linked to any person. The device remains unable to participate in deployments.

Note: Rejected requests do not trigger any notification to the device. If you reject a request accidentally, the device must re-initiate enrollment (typically by restarting ntkDrive).

Step 7 — Verify the ownership mapping enables deployment

After enrolling a device, confirm the deployment gate will pass:

  1. Navigate to Deploy in the sidebar to open the deployment wizard.
  2. Complete Steps 1–3 (profile selection, device group selection, options).
  3. On the Review step, observe the Policy Preflight Summary card.
  4. If preflight passes with no blocking findings for the newly enrolled device, the ownership mapping is correctly in place.

If preflight still reports device_owner_unassigned for the newly enrolled device, check the following:

Symptom Likely cause Fix
Device still shows as unassigned after approval The device key extracted and normalized from the UNC path does not match the device key registered against the expected person's Peer ID Open Device Groups, select the group, and verify that the device key extracted from the device path correctly maps to the Peer ID on the intended person record.
Enrollment column on Person shows "Not enrolled" after approval The fingerprint was saved to a different person record Open the People tab, search for the Peer ID from the enrollment request, and verify the fingerprint is present on the correct person.
Approval succeeded but queue still shows the row Stale cache; click Refresh in the Enrollment Queue toolbar —
Policy Manager returns backup_not_found error Unrelated to enrollment — see deployment troubleshooting See Deployment Failures.

Inline ownership assignment from the deployment wizard

As an alternative to the Enrollment Queue workflow, ntkDeploy supports assigning owners directly from the Review step of the deployment wizard when a device_owner_unassigned blocking finding is raised:

  • Go to Device Group to assign people — navigates to the Device Group detail page where you can assign a person to each device path individually. After returning, the wizard re-runs preflight.
  • Assign People (bulk) — opens an Assign People (bulk) dialog. Select a person from the picker and click Assign. ntkDeploy assigns that person as owner for every unmapped device in the selected groups in one batch operation, then re-runs preflight automatically.

Use this inline flow when you need to unblock a deployment quickly and the formal enrollment queue workflow is not needed (for example, when device identity is already known and a person record exists).

Device Key ↔ Peer ID mapping and deployment implications

The chain of dependencies from enrollment to deployment is:

ntkDrive device ──generates──► Enrollment request (Peer ID + fingerprint)
        │
        ▼ (approve)
Person record ──has──► deviceKeyFingerprints[]  ◄── linked at approval
        │
        ▼
Ownership Mapping ──satisfies──► Connectivity Gate preflight check
        │
        ▼
Artifact deployment ──succeeds for──► target UNC path

Breaking any link in this chain blocks deployment:

  • Missing person record → no Peer ID to approve enrollment against → create the person first.
  • Rejected or never-approved enrollment → fingerprint not linked → re-initiate enrollment on the device.
  • Person disabled (status: disabled) → excluded from policy evaluation → re-enable via the People tab.
  • Required attribute missing or expired → preflight blocks → add/renew the attribute in the Attributes tab.

Next Steps