Skip to content

ADR adopt discovered device

Jump to bottom
Pola, Sudhir edited this page Nov 13, 2026 · 4 revisions

ADR: Adopt ("Manage") an already-activated Discovered device

1. Current Behaviour

Console discovery (rpc-go v3) finds AMT-capable devices on the network. The Devices page already has two console-only tabs, Managed and Discovered (devices.component.ts). The tabs are backed by GET /api/v1/devices?activated=true and ?discovered=true (devices.service.ts), and the counts come from DeviceStats.activatedCount / discoveredCount.

  • When discovery finds a device that is already activated, Console places it in the Managed tab automatically. Activation does not mean the user chose to manage the device through Console. This is Console-side behaviour (item 5), not UI, but the UI work in this ADR depends on it.
  • Users can see discovered device details (item 3), but there is no action to move a device from Discovered to Managed.

2. Expected Behaviour

  • Every device found by discovery appears in the Discovered tab, regardless of activation state.
  • A device moves to Managed only when the user explicitly chooses to manage (adopt) it.
  • Only eligible devices (already activated, and supporting ISM or vPro) can be managed. For the others, the Manage action is disabled and the UI explains why.

Fleet example (from the issue discussion)

Group Count State Expected after discovery Manage action
vPro, activated (ACM/CCM) 2 Activated, possibly via MEBx or another tool Discovered Enabled
vPro, pre-provisioning 3 Not activated Discovered Disabled, with reason
non-vPro 5 No AMT/ISM/vPro support Discovered Disabled, with reason

3. What "adopt" means (definition for this ADR)

Adopt = register an already-activated device with Console using its existing Intel AMT admin credentials. No activation and no profile are involved.

  • It is not the activation flow, and it does not use a Console/RPS profile.
  • Console stores the credentials, validates them by connecting to AMT, and flips the device from Discovered to Managed.
  • It works regardless of how the device was activated (MEBx, another tool, or an older RPS).

This matches the existing enterprise "add device" path (POST /api/v1/devices with username/password, see addDevice() in the service).

4. Wireframes

4.1 Devices page, Discovered tab (row action)

image

4.2 Discovered device details (side pane), eligible device

image

4.3 Discovered device details (side pane), not eligible

image

4.4 Manage dialog

image

4.5 After success

image

5. Decision

  1. Add a Manage button to the read-only discovered device side pane (PR #3670) and to the Discovered tab row actions.
  2. Show Manage only in the console build, and only on devices in the Discovered state.
  3. Eligibility is evaluated client-side for display and re-validated by the backend on submit:
    • Eligible: activated and (ISM or vPro/Corporate SKU).
    • Otherwise the button is disabled, not hidden, with a tooltip and an inline reason (see the table below). Disabled plus an explanation was chosen over hiding so users can tell why a device they can see is not actionable.
  4. Clicking Manage opens a dialog asking for the AMT username and password. Whether to also expose TLS, self-signed and cert-hash options is open (Q5).
  5. On submit the UI calls the adopt endpoint. The backend validates the credentials by connecting to the device.
    • Success: snackbar, then navigate to /devices?tab=managed. The device appears in Managed and the counts update.
    • Failure: the dialog stays open with an inline error and the user can retry. Nothing moves tabs.
  6. The existing ?tab=managed|discovered query param (already implemented) is reused to land the user on the correct tab.

Ineligibility reasons

Condition Message (en)
Not activated (pre-provisioning) "This device is not activated yet. Activate it first, then it can be managed."
No AMT/ISM/vPro support "This device does not support Intel vPro or Intel Standard Manageability, so it cannot be managed."
Capability unknown or not reported "Device capabilities could not be determined. Re-run discovery."

All strings go through ngx-translate in en.json plus the other 11 locale files.

6. Behaviour flow

Run discovery
     |
     v
All devices -> DISCOVERED tab      (regardless of activation state; item 5)
     |
     v
Open details -> [Manage]
     |
     +-- not eligible --> disabled button + reason
     |
     +-- eligible -----> dialog: username / password
                              |
                              v
                      POST adopt (backend connects to AMT with creds)
                              |
                +-------------+--------------+
                | success                    | failure (401, unreachable, timeout)
                v                            v
        device -> MANAGED            inline error, dialog stays open
        navigate ?tab=managed

7. Open questions

Q-A. Where should a device added from the UI be listed?

Current flow: a device added from the UI (Add Device wizard, POST /api/v1/devices with username/password, or activated through a profile) is stored as a regular device and therefore falls under Managed. It never appears in Discovered.

Proposed flow: Managed now means "the user explicitly chose to manage this device", and Discovered means "found on the network, not yet adopted". This raises two cases:

Case Question
Device added from the UI that was never discovered Managed or Discovered?
Device added from the UI that discovery later finds (same GUID) Duplicate in Discovered?
Device in Discovered that the user then adds through Add Device (same GUID) Move or duplicate?

Review Feedback

Feedback from Sudhir ( 03-Nov-2026)

  1. Today, RPC-GO 3.x with profile-based activation can add a device to Console using the command below. Console then holds the device credentials, so OOBM operations (inventory, KVM, SOL and others) work immediately. Because the user explicitly added the device through RPC-GO, it should go directly to the Managed tab and never appear in Discovered.
$RPC_BINARY activate --url "https://$CONSOLE_IP:8181/api/v1/admin/profiles/export/$PROFILE_NAME?domainName=$DOMAIN_NAME"  --auth-username $CONSOLE_USER  --auth-password $CONSOLE_PASS -n --skip-amt-cert-check

Please see the table below for the expected behavior of rpc-go commands in relation to the Discovered and Managed tabs in Console.

# rpc-go command GUID in Console before What rpc-go sends Tab after
1 amtinfo --sync --url .../api/v1/devices Not present POST with discovered=true, no password Discovered, whatever the activation state
2 amtinfo --sync Already Discovered PATCH, no discovered, no password Stays Discovered, info refreshed
3 amtinfo --sync Added by the user through a curl call to POST /api/v1/devices (username and password) with the real GUID, so already Managed Same PATCH as case 2 Stays Managed: the sync cannot move it back, because the PATCH does not send discovered and the flag is write-once
4 amtinfo --sync Added by the user from the UI without a GUID (IP, username and password only), so Console generated a random GUID POST with the real AMT GUID, discovered=true, no password (the GUID does not match, so this is a new record) The UI record stays Managed, and a second record for the same device appears in Discovered (duplicate)
5 activate --url .../profiles/export/... with --auth-username/--auth-password (Console login) Not present POST with discovered=false and the AMT admin password from the profile Managed
6 Same activate command Already Discovered (from case 1) Same POST Managed: the existing record is updated and the flag cleared, so there is no duplicate and no 409
7 Same activate command Already present with the same GUID, Managed (for example added through a curl call that supplied the real GUID) POST returns 409, then PATCH with the AMT password and no discovered Stays Managed, credentials updated
8 Same activate command Added by the user from the UI without a GUID (Console generated a random GUID) POST with the real AMT GUID, discovered=false and the AMT password (the GUID does not match, so no 409) The UI record stays Managed, and rpc-go creates a second Managed record for the same device (duplicate)
9 Same activate command, post-activation sync step Any PATCH for TLS settings and device info, no AMT password No change
10 activate without --url (local only) Any Nothing is sent to Console No change, and no record is created

Notes:

  • Case 1 for a device that is not activated or not supported lands in Discovered with the Manage action disabled (notActivated or unsupported). Running case 6 later moves it to Managed.
  • activate --url registers the device in Console before activating it. If activation then fails, the device is already Managed with the profile's AMT password, which may not have been set on the device. Open: should rpc-go or Console clean this up?
  • --url with missing or wrong Console credentials fails before anything is sent to Console.
  • The UI Add Device request provides neither a GUID nor a deviceInfo object. Console generates the GUID, and discovered stays unset, so the device shows as Managed (the Managed filter is discovered IS NOT TRUE). Only a curl (REST) call can supply the real GUID or deviceInfo:
    • curl with the real GUID: the GUID matches a later rpc-go record (cases 3 and 7).
    • curl with deviceInfo and a password, no deviceInfo.discovered: Insert sets discovered=false, so Managed.
    • curl with deviceInfo and no password: discovered is derived from deviceInfo.currentMode ("Not Activated" gives Discovered, admin or client control mode gives Managed), unless deviceInfo.discovered is set explicitly, which is honoured as given.
  • Duplicates (cases 4 and 8): Console generates a random GUID when the UI Add Device request has none, while rpc-go always sends the real AMT GUID. The schema only enforces UNIQUE (guid), so nothing links the two records for the same IP or device, and the adoptExisting check in Insert matches on GUID only. This also applies to Q-A, row 2 ("device added from the UI that discovery later finds"): in practice the GUIDs differ, so GUID matching alone does not prevent the duplicate.

Console Wiki

ADRs

Clone this wiki locally