Agent cannot be installed: not manually nor pushed from a MS - rectified

Thanks to input from the community I have rectified this posting. It seems that the recommended practice by Microsoft is not to delete lines from the DB but to use the stored procedure for it. Kevin Holman has a posting about it which can be found here. It covers in detail what steps have to be taken.

It is good to get input like this from the community since I can't possibly know everything and therefore I am prone to error. So please send feedback and keep me sharp.

At a customer’s site I bumped into this situation where one couldn’t install a SCOM Agent on a particular server. No matter what they tried, it just didn’t work. It took me some time to figure it out but I solved it. (the wrong way, but hey, I got it working...)

Situation
When one tries to install an Agent on a server it fails. A manual installation seems to go right but when one approves or rejects the installation this error is being shown:

The service threw an unknown exception. See inner exception for details

The OpsMgr eventlog of the RMS shows EventID 26319 with a content like this:

An exception was thrown while processing ApproveAgentPendingActions for session id uuid

When one tries to push the Agent this error is being shown:

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.

The OpsMgr eventlog of the RMS shows EventID 33333 with a content like this:

~ Request: AgentPendingActionProcessChange -- (AgentName=), (PendingActionType=1), (AgentPendingActionId=11536ed1-29bc-d397-5396-2e6fb1e20fdc),~

Cause
It seemed that the server was an Agentless managed system before. So the system was already present in the OpsMgr database.

Before the Agent was installed on the very same server, they had forgotten to remove it from the Agentless Managed systems.

When the installation of the SCOM Agent failed (manually or pushed) they removed the system from the Agentless Managed systems.

But from that point on it was already 'too late': the OpsMgr database did have entries about this particular server which didn’t match with the real situation.

Solution
Instead of my previous information where one had to delete lines from the OpsMgr database, it is better to use the stored procedure as described by Kevin Holmans blogposting, found here