How to Troubleshoot ControlUp Monitor Script Actions Not Firing

A user encountered an issue with script actions not firing as expected on a ControlUp Moniter. This led to a discussion on potential solutions and troubleshooting steps, including checking the script location and examining monitor logs. The user ultimately decided to look into the issue further when they have access to the customer environment. Troubleshooting steps and suggestions were provided by other members in the Slack discussion.

Read the entire ‘How to Troubleshoot ControlUp Monitor Script Actions Not Firing’ thread below:

Crosspost from #

https://controlupcommunity.slack.com/archives/C0467CKR0MC/p1741952075464069

Trigger won’t fire script action: "The specified action which was supposed to run automatically doesn’t exist." EventID 5005 ControlUp Monitor

Maybe OSI-Layer 8 but at a customer I cannot get script actions to run as action in triggers.

We used tested with built-in "AAS_Session State – Disconnected" and "AAS_Session Sate – Active" triggers (and scripts) and also created a trigger which should fire ALD if LogonDuration is greater than 30s.

The triggers are firing as expected but the actions won’t run.

On the monitor which is supposed to run the script is throwing an EventID 5005 (see screenshot) with the error message:

The specified action which was supposed to run automatically doesn’t exist.

"Automation Admins" role is allowed executing the scripts.

Manually executing the scripts via Realtime Console are working fine.

OrgMembers role is allowed to "Run shared Script Actions".

Maybe I forgot a crucial step but…but….Its Friday 🙂

Are you able to post screenshots of the trigger or the json?

I have to request it at the customer.

But what do you expect to see?

The trigger is firing like it should.

If I add "send email" as action the email arrives successfully after the trigger kicked in.

So the issue is "just" when I add a script as action…

Ok, thats something I havent made clear in the original posting! Sorry for that 😄

ok, thx. that helps

maybe the endpoint cant access the script location?

If I am not mistaken the monitor "pushes" the script to the machine into the "AppData" location of the agent based if its a user or system session.

If user its somewhere in $env:appdata\ControlUp\Scripts and if its machine its in "C:\Windows\System32\config\systemprofile\AppData\Roaming\ControlUp\Scripts"!?

I have to indeed check if the script got pushed to the agent…

Anyways, if running the scripts manually is doing fine…

The agent writes the script when it is asked to run the script. There won’t be a repository of scripts. The files only exist very briefly.

Your monitor is saying you have a trigger that has action XYZ configured to run. But it isn’t aware of any action with ID XYZ.

Is this cloud or on-prem?

Its cloud and the actions were installed via activating the trigger (in the last step it downloads the script actions) if that its worth to note.

As said, running the script action manually working fine so the console sees the scripts…

Do you want to fix the immediate issue or do you want to dig a bit to potentially find the underlying issue?

To immediately resolve:

1. Stop the affected monitor(s)
2. Wait for cumonitor.exe to be gone from the list of running processes
3. Copy C:\Windows\ServiceProfiles\NetworkService\AppData\Roaming\ControlUp\cuMonitor.log and any cumonitor.log.x files
4. Delete or rename the C:\Windows\ServiceProfiles\NetworkService\AppData\Roaming\ControlUp\Configuration folder.
5. Delete or rename the C:\Windows\ServiceProfiles\NetworkService\AppData\Roaming\ControlUp\ControlUp Store folder.
6. Start the monitor.

NOTE that if you are doing this to all monitors, you will need to re-enter shared credential passwords. If you intend to do this to all monitors I’d actually recommend you do one, wait for it to be fully online/running. Then do another.

If you want to dig into why this happened, steps are a bit more involved. Typing those out below.

“`$monpath = ((Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Services\cuMonitor").imagepath).replace("\cuMonitor.exe",$null).replace(‘"’,$null)

Get-Item "$monpath\powershell.dll"|import-module

Invoke-CUQuery -Table ConfigurationModels -Scheme Runtime -take 5000 -Fields * -where "ModelName = ‘sba’"| select -ExpandProperty data | ogv

Invoke-CUQuery -Table RunTimeSBA -Scheme Runtime -take 5000 -Fields * -Where "Name = ‘Analyze Logon Duration’" | select -ExpandProperty data | ogv“`

Change Analyze Logon duration in the last line for your script name.

This will show the monitors representation of the configuration modules. Specifically the SBA configuration. Note that in my case my monitors are aligned on the model version (and timestamp).

This does assume that only 1 monitor has the problem. But it will at least help figure out what is going on

If they are aligned, check the 2nd invoke-cuquery output. It shows the specific script actions metadata. In my case Analyze Logon Duration. The SBA ID, the status, etc.

One line for each monitor.

Last but not least. The logs mentioned above (C:\Windows\ServiceProfiles\NetworkService\AppData\Roaming\ControlUp\cuMonitor.log and any cumonitor.log.x files) would list why a monitor wasn’t able to process a configuration update

Send me a DM or open a ticket with the information and we can take it from there

Wow… Okay… 🙂 I need to let that sink. 😄

Thanks Dennis.

I will check when I have access to the customer environment.

Continue reading and comment on the thread ‘How to Troubleshoot ControlUp Monitor Script Actions Not Firing’.  Not a member? Join Here!