Skip to content

Managing Device Groups

A Device Group is a named collection of Windows deployment targets, each identified by a target path — either a UNC Path on a Windows network share or a local absolute Windows path. When you assign a Profile to a device group, ntkDeploy deploys the resulting Artifact to every path in that group.

This tutorial covers creating and deleting groups, managing target paths, configuring destination rules, running preflight checks, and understanding the device ownership grid.

Prerequisites

  • ntkDeploy installed and configured — see Installation and First Launch.
  • At least one Profile created — see Creating a Profile.
  • SMB/UNC network shares or local absolute paths accessible from the machine running ntkDeploy — for example \\fileserver\configs or C:\DeployConfigs.

1. Navigate to Device Groups

Click Device Groups in the left navigation sidebar. The screen splits into two panels:

  • Left panel (320 px) — The Device Groups list, with an inline New Group Name / Description form at the top.
  • Right panel — Shows the paths and quick-add form for the selected group, or a prompt to select a group.

2. Create a Device Group

  1. In the left panel, type a name in the New Group Name field (for example, Building-A-Workstations).
  2. Optionally add a Description (optional) for context.
  3. Click Create Group.

The new group appears in the list below and is automatically selected, revealing the paths panel on the right.

Validation: If New Group Name is left empty, the create action is blocked and a snackbar reads "Enter a group name."

3. Add Target Paths to a Group

Target paths are the individual deployment targets within a group (UNC network shares or local absolute Windows paths).

  1. Select a group from the left panel.
  2. In the right panel's path-entry row, type a UNC path (e.g. \\server\share\dept-configs) or a local path (e.g. C:\DeployConfigs) in the path entry field.
  3. Optionally add a human-readable Label (optional) such as Building A – Floor 2.
  4. Click Add (or press Enter).

The path appears in the list below with a folder icon and its optional label.

Path validation errors

Error Cause Fix
Invalid UNC path: … Path does not start with \\ or is otherwise malformed Ensure the path begins with \\ and follows the format \\server\share[\subpath].
Invalid local path: … Local path is missing a drive letter, colon, or backslash Ensure the path uses the format C:\folder\path with a drive letter and backslash separator.
Snackbar with error detail Path field is blank or only whitespace Enter a valid path before clicking Add.

Local and USB Paths

In addition to UNC/SMB shares, device group paths accept local absolute Windows paths — for example, a USB drive or a locally-mounted deployment destination.

Format Example
UNC share \\fileserver\configs\dept-a
Local drive C:\DeployConfigs\dept-a
USB/removable D:\ntkDeploy\profiles

Path type classification: Each path is classified as either UNC or Local and the type is displayed as a chip next to the path in the Device Paths tab. The type is determined automatically from the path format when the path is added.

Validation rules for local paths:

  • Must begin with a drive letter followed by :\ (e.g. C:\, D:\)
  • No network UNC syntax (\\) is accepted as a local path
  • Directory traversal sequences (..) are rejected
  • The same reachability and write-permission checks apply as for UNC paths — run a Preflight Check to confirm the path is accessible before deploying

Connectivity checks: The preflight reachability and write-permission checks work identically for local paths and UNC paths. A local path that the running user cannot write to will produce a permission_denied result just as a UNC share would.

Mobile profiles: Local and USB paths are the primary delivery mechanism for mobile .ntkprofile files. See Mobile Profiles for the full delivery workflow.

Remove a path

Click the ✕ icon on the right of any path card to remove it immediately. There is no confirmation dialog — removal takes effect at once.

4. Configure a Group (Detail View)

For advanced configuration, click the Configure button (⚙️) in the group's paths-panel header. This opens the Device Group Detail screen with three tabs:

  • Device Paths
  • Destination Rules
  • Pre-Flight Checks

Tab 1: Device Paths

This tab lists all configured target paths with full ownership and status detail.

Path properties

Property Description
Status icon Shows the last-known reachability state. Grey (schedule) = never checked; green ✅ = reachable; red ❌ = unreachable or failed; orange 🔒 = permission denied.
UNC Path The path displayed in monospace font.
Label Optional human-readable label set when the path was added.
Last checked Relative time since the last preflight check (Just now, 5m ago, Never checked).
Ownership badge Displays one of: Assigned (a person is linked), Assigned – person unavailable (person record no longer resolvable), or No owner (unassigned).
Deploy blocked chip A red warning chip labelled Deploy blocked appears when a path has no owner. Deployment to this path is blocked until an owner is assigned — see Device Enrollment.
Owner display The display name and Peer ID of the assigned person, or Unassigned.

Assign a person to a path

Click Assign person… under any path to open the Assign person dialog. Use the Person Picker to search and select the responsible owner, then click Assign.

Bulk path operations

Use the toolbar buttons at the top of the Device Paths tab:

Button Action
Bulk Import Import a list of target paths from a file.
Assign People (bulk) Opens the Assign People (bulk) menu with three options: Assign selected/all (pick a person for all checked paths, or all paths if none are selected); Assign by label (match paths by exact label, assign one person); Import ownership CSV (upload a .csv mapping device keys to Peer IDs).
Check All Paths Runs a preflight reachability and write-permission check on every path in the group sequentially.

Select individual paths using the checkbox on the right of each card before using Assign selected/all.

Tab 2: Destination Rules

Destination rules are stored with each device-group path, but the current encrypted deployment pipeline applies only the target path itself. Desktop deployment now writes appconfig.ntkd at the selected path root, and managed mobile deployment writes {profileId}.ntkprofile under profiles\.

The Destination Folder and Destination Filename fields remain visible in the UI for compatibility and planning, but they are not currently applied to encrypted desktop output.

Field Description Example
Destination Folder Stored with the path, but encrypted desktop rollout currently writes at the target path root. Managed mobile rollout always uses profiles\. \configs or profiles\
Destination Filename Stored with the path, but encrypted desktop rollout currently writes appconfig.ntkd regardless of the saved value. Managed mobile rollout always writes {profileId}.ntkprofile. The UI may still show the legacy appconfig.json default. appconfig.ntkd
Backup Strategy Stored with the path for future rollout policy. Current deployment services create timestamped .bak backups automatically when overwriting an existing artifact. appconfig.ntkd.bak.<timestamp>
Overwrite Strategy Stored with the path for future rollout policy. Current deployment services overwrite the fixed artifact path when deployment proceeds. appconfig.ntkd

After adjusting the fields for a path, click Save Rules on that card. A snackbar confirms "Destination rules updated".

Note: Destination rule values are still saved on the path record, but encrypted desktop rollout currently ignores the saved folder and filename fields.

Tab 3: Pre-Flight Checks

Preflight checks verify that each path is accessible and writable before deployment. Running these checks before a rollout prevents partially-completed deployments caused by network or permission issues.

Running preflight checks

  • Click Run All Checks (top-right of the tab) to test every path in the group sequentially.
  • Or click the ↻ (refresh) icon on an individual path card in the Device Paths tab to check that path alone.

Each check performs two steps:

  1. Reachability — Confirms the target path is accessible (for UNC paths, resolves on the network; for local paths, confirms the directory exists).
  2. Write permission — Confirms ntkDeploy can write a test file to the path.

When all checks complete, a snackbar reads "All preflight checks completed".

Interpreting results

Status value Icon Meaning
reachable / success ✅ green Path is accessible and writable — deployment can proceed.
unreachable / failed ❌ red Path is not accessible. For UNC paths check network connectivity and share availability; for local paths verify the directory exists.
permission_denied 🔒 orange Path is accessible but the running user lacks write access. For UNC paths review SMB share and NTFS permissions; for local paths check folder ACLs.
(never checked) ⏱ grey No check has run yet. Run a check before scheduling a deployment.

For persistent reachability failures see Connectivity Issues. Note that the connectivity gate must also be open before any deployment can proceed.

5. Edit a Group Name or Description

Group names and descriptions are set at creation time through the inline form. To rename a group:

  1. Delete the existing group (see below).
  2. Re-create it with the new name.
  3. Re-add the target paths.

Note: In-place rename is not currently available. Deletion and re-creation is the supported workflow.

6. Delete a Device Group

⚠️ Deletion removes the group and all its associated target paths. Existing Assignments referencing this group may be affected.

  1. In the left panel, click the Delete icon (🗑️) on the group card.
  2. A confirmation dialog reads:

    Delete Device Group
    "Are you sure you want to delete <name>? This will remove N UNC path(s) associated with this group."

  3. Click Delete to confirm or Cancel to abort.

Next Steps