Troubleshooting FSLogix Profile Lock Event Triggers with ControlUp’s New Windows Event Log Monitoring in DEX

A common issue arises when configuring ControlUp triggers for FSLogix profile event handling, particularly with the new Windows Event Log Monitoring feature in ControlUp Digital Employee Experience (DEX). A user setting up a trigger based on FSLogix event ID 999 (ControlUp-FSLogixProfileLocked) noticed that although the event appeared in the local Windows event log, the associated trigger action (such as running a script on profile lock) did not execute. After enabling the new Windows Event handling and creating a corresponding filter for event 999 in the ControlUp web console, the event was correctly detected, and the action was attempted but failed with the error: “Script execution failed: CUTriggerObject is not available. This script must be run from a ControlUp trigger.”

The root cause relates to how the new DEX Windows Event Log Monitoring selectively forwards events based on collection rules. By default, custom events like event 999 are not included in these rules and thus remain only in the local event log, preventing real-time triggers from detecting them. When such events are collected through DEX, the script execution context differs—in particular, the `$CUTriggerObject` scripting object (which provides event details like username and machine name) is not available in scripts run through DEX event filters. This causes the script failure because it expects this object to be populated.

The solution is to add a DEX rule that explicitly collects event 999 to allow monitoring and alerting, but continue using the imported Real-Time trigger for executing the FSLogix logoff script. This trigger runs in the correct context and has access to `$CUTriggerObject`, allowing the script to function as intended. The presence of the event in the web console and receiving email notifications after adding the DEX rule demonstrate that events are collected, but only the real-time trigger can correctly handle the associated script action. Also, users should verify their scripts have the “Execute with.NET engine” option enabled to ensure proper script execution.

This issue does not stem from permissions or account misconfiguration but from the distinct operational contexts between DEX event filtering and real-time triggers. For detailed guidance, users can consult the ControlUp blog article on fixing FSLogix profile attach issues at https://www.controlup.com/blog/how-to-fix-the-fslogix-issue-the-user-profile-failed-to-attach/. Additional troubleshooting tips and best practices for script and trigger setup can be found in the ControlUp Knowledge Base and Academy resources at https://docs.controlup.com and https://cuacademy.controlup.com respectively.

Read the entire ‘Troubleshooting FSLogix Profile Lock Event Triggers with ControlUp’s New Windows Event Log Monitoring in DEX’ thread below:

Does the new event handling feature affect triggers in ControlUp for VDI? Specifically extracting data/parameters from Windows events?

I am attempting to setup an FSLogix triggered action according to this document (for the first time) – controlup.com/blog/how-to-fix-the-fslogix-issue-the-user-profile-failed-to-attach

After setup & logging in with a locked profile I confirmed that I was seeing the events in the local event log for the event 999 but the event action was not triggered.

At this point I remembered that we recently activated the new Windows Event handling so I created a filter for event “999” – “ControlUp-FSLogixProfileLocked” in the web console. Now I see the event/failure in the web console & also received an email output confirming that the script for logoff of sessions ran. Unfortunately it is giving the error:

“Script execution failed:
CUTriggerObject is not available. This script must be run from a ControlUp trigger.”

It seems that although the script is running with the trigger now, it isn’t correctly passing the parameters with the username & machine name. Does this seem related to the new event handling or is it more likely a misconfiguration with account, permissions etc?

The new Windows Event Log Monitoring in DEX does affect this setup, but not by corrupting event parameters. With that feature on, the agent only forwards events that match a DEX collection rule. Your custom Event 999 (`ControlUp-FSLogixProfileLocked`) is not in the default rules, so it stayed in the local System log and the Real-Time trigger never saw it.
The FSLogix logoff script is written only for a Real-Time DX trigger. It reads username and machine from `$CUTriggerObject.Event.EventFullMsg` (comma-separated), not from the web console User field (`N/A` is normal here). DEX filters can collect the event and even run a script, but they do not inject `$CUTriggerObject`, which is exactly that error.
Add a DEX rule so Event 999 is collected, but keep the imported Real-Time trigger as the thing that runs the script. Confirm the trigger in the Incidents pane. This is not an account/permissions issue.

check your script Josh. Does it have the “Execute with.NET engine” checkbox checked?

Continue reading and comment on the thread ‘Troubleshooting FSLogix Profile Lock Event Triggers with ControlUp’s New Windows Event Log Monitoring in DEX’.  Not a member? Join Here!