
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-01-2018 10:14 AM
I am trying to register my secondary node on my ISE 2.4 solution. The nodes can ping eachother's hostnames and have each other's certificates. Is there a log that will tell me why they are erroring out?
Solved! Go to Solution.
- Labels:
-
Identity Services Engine (ISE)
Accepted Solutions

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-01-2018 02:57 PM
Usually this is quite straightforward
The secondary node must be in STANDALONE mode.
The secondary node must be at identical patch level as the Primary.
DNS resolution must resolve the FQDN of both nodes.
PAN must trust the secondary node's cert
Firewalls between the nodes? Install Guide lists all the ports ...
Failing all that, something strange is going on. The ise-psc log should reveal cause.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-01-2018 09:04 PM - edited 11-01-2018 09:07 PM
Beyond what was already mentioned above me, two potential issues come to mind which we don't have enough information to rule out.
There is an odd bug if you were using an older patch on 2.4 and upgraded from 2.3.
https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvj44088
The second thing I have seen on a freshly installed node joining to an existing deployment. The deployment had a different admin password than the fresh node. During registration, the new node would fail to register, further investigation showed an alarm for admin lockout. I disabled admin lockout on the new node, registered fine after. Something I only found on 2.4 without patches.
If you can't figure it out from the logs hslai shared, you can work with TAC and they will debug the issue.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-01-2018 01:21 PM
I would start with the application log ise-psc.log and the system log ade/ADE.log first.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-01-2018 02:57 PM
Usually this is quite straightforward
The secondary node must be in STANDALONE mode.
The secondary node must be at identical patch level as the Primary.
DNS resolution must resolve the FQDN of both nodes.
PAN must trust the secondary node's cert
Firewalls between the nodes? Install Guide lists all the ports ...
Failing all that, something strange is going on. The ise-psc log should reveal cause.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-01-2018 09:04 PM - edited 11-01-2018 09:07 PM
Beyond what was already mentioned above me, two potential issues come to mind which we don't have enough information to rule out.
There is an odd bug if you were using an older patch on 2.4 and upgraded from 2.3.
https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvj44088
The second thing I have seen on a freshly installed node joining to an existing deployment. The deployment had a different admin password than the fresh node. During registration, the new node would fail to register, further investigation showed an alarm for admin lockout. I disabled admin lockout on the new node, registered fine after. Something I only found on 2.4 without patches.
If you can't figure it out from the logs hslai shared, you can work with TAC and they will debug the issue.
