Abstract
The trigger catalog covers four scenarios: New Device, Schedule, Manual, and Restart. Two scenarios are missing, and both involve features I’d like to carry over from my previous RMM:
When a user logs in. Anything that affects the user profile needs to happen at this point. A schedule won’t trigger it.
When a check triggers. I want to react to a detected state, not check every minute to see if it has occurred.
I’m requesting two additional triggers: UserLogin and CheckStateChanged. The first one is the more important one to me.
What octoja can do today
Four triggers, clearly separated from the execution context—that’s the right setup and it works well:
For each step , executionContext: "User" or "System. " So the user context is already there—I just need to know when it actually takes effect.
Where the problem lies
1. User Login
On managed Windows workstations, there are a number of settings that must be configured specifically during login. Four typical examples:
I can’t get this to work properly with Schedule. A cron job every 30 minutes runs about 15 times a day per workstation—for a setting that changes exactly once per login. If there’s a gap in the schedule, the user sees the ad tiles until the next run. Shorter intervals make it worse, not better.
OnBoot doesn’t help: the login happens afterward, and on shared computers and terminal servers, users switch accounts without a reboot.
The workaround using a scheduled Windows task triggered by login works, but it shifts the logic exactly where I don’t want it: onto the device. As a result, octoja no longer reflects what’s actually happening, and the task is excluded from reporting.
2. Response to a Check
Two typical cases:
Today, I have a schedule for this that runs on all devices and almost always determines that nothing needs to be done. For software with a target version, this takes care of software distribution for me—and that’s where octoja actually has an advantage. But as soon as the status isn’t “Package X in version Y,” but rather “Registry key present,” “Service not running,” or “File remnant found,” all I have is the schedule.
The check already knows this. It’s running anyway, it knows the result, and it’s listed in the alert log. What’s missing is the path from there to automation.