Endpoint Manager troubleshooting

Endpoint Manager has a small number of failure modes because its surface area is narrow — it’s a delegated-admin layer on top of Cisco ISE’s APIs. This page walks the symptoms you’re most likely to see and the ISE-side or platform-side check that usually resolves them.

Symptom — the API Status table shows at least one Down

You saved API Configuration; one or more rows in the Cisco ISE API Status table read Down. Nothing in the Context works until every row reads Up.

Check in this order:

1. Is the API family enabled on Cisco ISE? Each of ERS, Open API and Monitoring (MnT) has its own enablement switch in ISE’s Administration → System → Settings area. A freshly- installed ISE often ships with one or more of them off. If the row that’s Down is Endpoint Groups API → ERS needs enabling; Endpoint API → Open API; Monitoring API → MnT.
2. Does the API user have the right permissions? All three API families require per-user authorisation. A user that can hit one API doesn’t automatically get the others.
3. Is Cisco ISE reachable from the egress FQDN? The platform’s outbound FQDN (shown on the API Configuration card) must be allowed by every firewall, proxy or ACL in front of ISE. If ERS is enabled but unreachable, the status row still reads Down.
4. Has the password changed? Re-enter the password and save. Leaving the field blank on a re-save keeps the current password in place; that’s usually what you want, but if the ISE-side password changed out-of-band, a blank field means stale credentials.

Fix the underlying ISE-side issue, then click Update API Configuration to re-exercise the credentials.

Symptom — a group sticks at Not Connected after Connect this Group

You clicked Connect this Group on an existing ISE group and confirmed, but the row still reads Not Connected.

Usually means:

• A transient error while recording the connection. Connecting an existing group records the binding on the platform side; it does not write into Cisco ISE. A short-lived hiccup recording or verifying that binding can abort it. Re-click Connect this Group — the second attempt almost always succeeds.
• The API user lost permission after API Configuration was saved. If the status table was Up earlier but is no longer, re-check the API user’s role. See the symptom above.
• The group was deleted on the ISE side. A group that existed when the list was cached but has since been deleted can’t be connected. Refresh the Groups list; the group will have vanished.

Symptom — a group is Connected but no endpoints appear

The group is Connected, Cisco ISE reports endpoints in it (you can see them in ISE’s own admin UI), but the platform’s ISE Endpoints tab is empty.

Check:

1. The Endpoint API row in API Status. If it’s Down, endpoint reads are blocked. See the first symptom.
2. The page of endpoints. The list is paginated — increase Per page to 50 or 100, or hit the next page.
3. Any active MAC search. Clear the search filter if one’s set.
4. ISE-side caching. Cisco ISE’s Open API occasionally returns a stale page on very fresh endpoint additions. Wait a minute and refresh the tab.

Symptom — Perform CoA returns no session on an endpoint you know is online

The endpoint looks online (icon green, session data filled in) and the row action menu shows Perform CoA, but triggering it reports that no session could be used.

Usually means:

• The session dropped between list-load and action-click. Refresh the tab; the Status icon will now show offline. Wait for the endpoint to re-authenticate, then retry.
• The session has no ACS server to target. This happens when an endpoint authenticated a long time ago and ISE pruned the full session metadata. CoA needs the ACS server field to target the right NAS; without it the action is still offered but fails because there’s nothing to send the CoA to. Wait for the endpoint to re-authenticate.
• Monitoring API is Down. Perform CoA depends on MnT. See the first symptom.

Symptom — batch import rejected a row that looks valid

The preview table in step 3 flagged a row in red.

Most common causes:

• MAC is not 12 hex characters. Separators are ignored but the underlying MAC must decode to 12 hex chars (a normal 48-bit MAC address). A typo or a stray character in the MAC cell trips the validator.
• Device Type isn’t one of the allowed values. The wizard accepts a fixed set of Device Type values. Anything else — including a trailing space — fails validation.
• CSV encoding surprises. BOM characters or UTF-16 encoding can confuse the parser. Save the CSV as plain UTF-8 without BOM.

Fix the CSV on disk and re-run the wizard from step 1. There’s no partial-import path.

Start here — the Integration Log

Before working through the symptoms below, open the Context’s Integration Log. It lists the outbound calls to Cisco ISE that failed, with the reason and an explanation written to be acted on. Most of what follows is faster to diagnose from there. See Integration Log.

Symptom — attribute changes don’t reach Cisco ISE

You defined an attribute at the Context level, set its value at the group level, but Cisco ISE’s endpoint records don’t show it.

Check:

1. The attribute exists in ISE under Administration → Identity Management → Endpoint Custom Attributes. If it doesn’t, create it there first — the platform writes values for every defined attribute, but ISE silently drops values for attributes it doesn’t know about.
2. The attribute types match. If the platform says vendor-owner is String and ISE says it’s Integer, the values won’t stick. Align the types on both sides.
3. The attribute is at the level you think. A group level attribute takes its value from the group, so confirm you set it on the group the endpoint actually belongs to. An endpoint level attribute takes its value from the device, and only on groups that have opted in to it on the Endpoint Custom Attributes sub-tab.
4. The Integration Log. If ISE refused the write outright, the reason is there rather than in any of the above.

Symptom — a Wi-Fi key can be seen but not changed

A Self-Service User can reveal a device’s key but has no Update PSK or Regenerate button.

Usually means: the attribute is exposed as Display rather than Editable, or the user doesn’t hold the group’s device-administration role. Both are required to change a key; revealing needs only group membership.

Symptom — the key is gone from the platform but devices still connect

Someone removed the key attribute from the group.

What happened: removing it discards the platform’s copy of the key, but does not remove it from the endpoints in Cisco ISE. The devices keep connecting and the platform can no longer show or rotate the key. Adding the attribute back generates a new key, which will disconnect every device still using the old one. See Identity PSK.

Symptom — a Self-Service User can’t sign in

They clicked the email invitation link or tried SAML and landed on an error page.

Check:

• The invitation is still valid. Click Resend Invitation on the user’s row to mint a fresh token.
• Email typos. The address the invite went to must match exactly — case-insensitive, but otherwise verbatim.
• For SAML sign-in: the Organization’s SAML settings are correctly configured for the Self-Service portal. See Organization SAML authentication.

When to reach out

If the API Status table reads Up, the underlying ISE APIs respond normally from another tool (for example a curl against the same Base URL), and something on the platform side still isn’t behaving, open a support ticket with your Netgraph contact. Include:

• The Organization and Context names (not IDs — humans find names faster in our logs).
• The exact failing action (connect group X, add endpoint Y).
• The timestamp of the attempt, to five-minute accuracy.
• Anything relevant from the Context’s Audit Log around that time.

Related

Cisco ISE connection

Base URL, API user, three API families.

Managing endpoints

CRUD and Change of Authorization.

Managed Attributes

Context-level definition, group-level values.

Audit Log

Every operation recorded, with timestamps.