Menu Close

Agent Pending Actions can get out of sync between the Console, and the database

When you look at your agent pending actions in the Administration pane of the console…. you will see pending actions for things like approving a manual agent install, agent installation in progress, approving agent updates, like from a hotfix, etc.

This pending action information is also contained in the SQL table in the OpsDB – agentpendingaction

It is possible for the agentpendingaction table to get out of synch with the console, for instance, if the server was in the middle of updating/installing an agent – and the management server Healthservice process crashed or was killed.

In this case, you might have a lingering pending action, that blocks you from doing something in the future.  For instance – if you had a pending action to install an agent, that did not show up in the pending actions view of the console.  What might happen, is that when you attempt to discover and push the agent to this same server, you get an error message:

“One or more computers you are trying to manage are already in the process of being managed.  Please resolve these issues via the Pending Management view in Administration, prior to attempting to manage them again”

ss2

The problem is – they don’t show up in this view!

To view the database information on pending actions:

select * from agentpendingaction

You should be able to find your pending action there – that does not show up in the Pending Action view in the console, if you are affected by this.

To resolve – we should first try and reject these “ghost” pending actions via the SDK… using powershell.  Open a command shell, and run the following:

get-agentpendingaction

To see a prettier view:

get-agentpendingaction | ft agentname,agentpendingactiontype

To see a specific pending action for a specific agent:

get-agentPendingAction | where {$_.AgentName -eq “servername.domain.com”}

To reject the specific pending action:

get-agentPendingAction | where {$_.AgentName -eq “servername.domain.com”}|Reject-agentPendingAction

We can use the last line – to reject the specific pending action we are interested in.

You might get an exception running this:

Reject-AgentPendingAction : Microsoft.EnterpriseManagement.Common.UnknownServiceE
xception: The service threw an unknown exception. See inner exception for details
. —> System.ServiceModel.FaultException`1[System.ServiceModel.ExceptionDetail]:
Exception of type ‘Microsoft.EnterpriseManagement.Common.DataItemDoesNotExistExc
eption’ was thrown.

If this fails, such as gives an exception, or if our problem pending action doesn’t even show up in Powershell…. we have to drop down to the SQL database level.  This is a LAST resort and NOT SUPPORTED…. run at your own risk.

There is a stored procedure to delete pending actions…. here is an example, to run in a SQL query window:

exec p_AgentPendingActionDeleteByAgentName ‘agentname.domain.com’

Change ‘agentname.domain.com’ to the agent name that is showing up in the SQL table, but not in the console view.

6 Comments

  1. Jammy

    Hello,

    I have a server that stays Not Monitored/Uninitialized in my SCOM 1801 console. I’ve checked the Administration/Pending Management and it isn’t there. Checking the Operations Manager log on the server shows event ID 20070 “Not approved to connect”. And the Operations Manager log on the SCOM server shows event ID 20000 “A device which is not part of this management group has attempted to access this Health Service.”.

    Google searches lead me to this post but when I run the SQL query “select * from agentpendingaction” against the DB I don’t see the server listed. And when I run the PowerShell query “Get-SCOMPendingManagement” it doesn’t show there either.

    But if I run PowerShell query “Get-SCOMClassInstance -DisplayName ******” it comes back with 5 lines worth of info:

    HealthState InMaintenanceMode DisplayName
    ———– —————– ———–
    Uninitialized False *****
    Error False *****
    Uninitialized False *****
    Uninitialized False *****
    Uninitialized False *****

    So it appears like it has 5 copies of my server and none of them are working. How do I clear out the bad info so it will approve my server?

    • Kevin Holman

      First, I’d want to make sure SCOM is healthy, and SCOM management servers all have a recent 21025 event in their logs (showing that config is working on all management servers)

      Next, you should not “have” to ever do this…. but sometimes an agent gets “stuck” and you have to nuke the Base Managed entities. I don’t recommend doing this generally, without a support case…. because if you do it wrong, you could end up with corruption. Take a SQL backup of the OpsDB and the DW immediately before attempting.

      https://kevinholman.com/2018/05/03/deleting-and-purging-data-from-the-scom-database/

      You can find the BaseManagedEntities relating to that computer, and nuke them, then let it come back in and see if it discovers ok.

  2. Jammy

    Thanks for the info, since it involved running commands against the SQL database I went ahead and opened a ticket with Microsoft and the tech ran pretty much the same commands you listed in your purge post and all is well now.

  3. Andy

    So I just had exactly the same issue with a gateway where the tech installed the gateway and certs before running the gateway approval tool, then deleted it using the gateway tool with the agent object in agent pending. This left a hidden pending approval. To fix , stop the gateway , powershell to delete the hidden pending approval, remove the gateway with the tool, nuke the BME as per above , then gateway approve , restart gateway.

  4. Stevan

    I just upgraded 2019 to 2022, when I went to update my agent in pending there was nothing there. Ran the command select * From agentpendingaction and it is blank too. Ran check on patch list, and all agent show as 2019 update 3. Tried setting security to automatic, closed console, restarted services, no joy. Any other ideas? (two heads are always better than one)

Leave a Reply

Your email address will not be published.