Scope
Solution Manager 7.1 SP05 and higher.
Context
Each Diagnostics Agent is establishing a (P4) connection to the Solution Manager Java stack. Up-to Solution Manger 7.1 SP05 this connection was a "standard" authenticated connection, in general with user SMD_ADMIN.
This approach had the disadvantage that in case the password of the SMD_ADMIN user changed or the user was locked (for whatever reason), the Diagnostics Agents stopped trying to establish this connection to avoid locking again that system user. This way the operator was able to stabilize the situation. But this approach had as a downside, on large scale landscape, to imply quite some extra work as a lot of these Agents had to be restarted or connected again via the "Agent Candidate Management tool" in order to make them again trying to reconnect to the Solution Manager system.
This approach had the disadvantage that in case the password of the SMD_ADMIN user changed or the user was locked (for whatever reason), the Diagnostics Agents stopped trying to establish this connection to avoid locking again that system user. This way the operator was able to stabilize the situation. But this approach had as a downside, on large scale landscape, to imply quite some extra work as a lot of these Agents had to be restarted or connected again via the "Agent Candidate Management tool" in order to make them again trying to reconnect to the Solution Manager system.
Concept
Starting with Solution Manager 7.1 SP05 the Diagnostics Agents, which have been connected at least once to the Solution Manager system so that they patch themselves, are keeping their connection alive. Therefore in case the authentication (via username/password or certificate) is failing, the impacted Agents are placed in a so called "Non-authenticated Agents" list.
As a consequence the Diagnostics Agent is no longer available from a functional point of view, whereas it could be still operated remotely, in order to give the opportunity to that Agent to authenticate again successfully with up-to-date credentials.
Once the Agent is again authenticated it becomes again available from a function point of view and thus visible in the standard Connected Diagnostics Agents list.
In any case it will be the responsibility of the Solution Manager system Administrator to decide which Agents should receive again the up-to-date credentials which have been maintained in solman_setup -> System Preparation -> Create Users -> SMD_ADMIN user.
As a consequence the Diagnostics Agent is no longer available from a functional point of view, whereas it could be still operated remotely, in order to give the opportunity to that Agent to authenticate again successfully with up-to-date credentials.
Once the Agent is again authenticated it becomes again available from a function point of view and thus visible in the standard Connected Diagnostics Agents list.
In any case it will be the responsibility of the Solution Manager system Administrator to decide which Agents should receive again the up-to-date credentials which have been maintained in solman_setup -> System Preparation -> Create Users -> SMD_ADMIN user.
Use case example
- One Diagnostics Agent is currently connect to a Solution Manager system
- The dedicated system user SMD_ADMINxx which is used in this example by the Agent to connect to Solution Manager is locked intentionally. Therefore the Agent is getting no longer "available", from a functional perspective, and is no longer listed in the "Connected Agents" list...
- ... but the Agent is now instead listed under the "Non-authenticated Agents" tab, also called "Isolated Agents". To "repair" this situation, the system user has to be fixed (unlock) and in the "Isolated Agents" UI, select the Agent with the checkbox and press the "Push Credentials" button to repair the Agent remotely.
- The Agent is connecting again with the appropriate credentials and therefore usable as before.
No comments:
Post a Comment