In a recent discussion among ControlUp community members, the capability of passing output from the "Run System Command" node directly into the next step of a workflow was explored. The specific use case involved reading a device’s Organizational Unit (OU) from Active Directory (AD) and using that information to dynamically assign tags through the "Update Tags" node in a workflow. The question centered on whether the result of a command or script executed by the "Run System Command" node could be piped directly to the subsequent node for immediate processing.
The response clarified that currently, ControlUp's "Run System Command" or script execution nodes do not support the direct output transfer or piping of command results into subsequent workflow steps. This limitation means that you cannot directly feed command or script output into another node like "Update Tags" within the same workflow step sequence.
A recommended workaround involves using a data index alongside a script. The script, executed by the "Run System Command" node, can write the needed output (such as device OU information) to a ControlUp data index. The "Update Tags" node or any subsequent workflow step can then query and apply data from this index, thereby indirectly passing the information through the workflow with a slight delay compared to direct piping. Another mentioned option involves invoking a new flow via a REST API call from the script once execution completes, which offers a programmatic way to chain operations but also introduces additional complexity.
While there is no current timeline for enabling direct output passing from the "Run System Command" node, the ControlUp team acknowledged the usefulness of this feature and indicated plans to add it in the future to streamline workflows by eliminating the need for external data storage steps or additional scripts.
For further guidance on automating tags based on device attributes, workflows, and data indexing in ControlUp, users may refer to the official ControlUp documentation at https://docs.controlup.com and the ControlUp Academy at https://cuacademy.controlup.com, where detailed instructions and best practices for workflow automation and integrating Active Directory data can be found.
Read the entire article here...
Automation & Alerting Related Training & Support Archives
Automation & Alerting training and support-related archives from inside the ControlUp Community on Slack.
How to Fix 400 Errors Caused by Using _id Sorting in ControlUp Edge API Queries
A PowerShell script that queries device data from the ControlUp Edge API using paginated search_after calls experienced failures starting Sunday, returning a 400 Bad Request error. The error message indicated that sorting or aggregations on the _id metadata field were no longer supported, specifically stating that "Using the _id metadata field in aggregations, sorts, scripts, or top-level field loads... is not supported because it loads fielddata into the heap." This change caused calls sorting by the internal OpenSearch/Elasticsearch document _id to fail.
The root cause was an upstream change implemented over the weekend by ControlUp. The API now blocks the use of the _id metadata field in queries to prevent severe OpenSearch JVM issues such as Out of Memory (OOM) conditions, which were observed when sorting or aggregating on large indexes by _id. This protective measure was applied after discovering more widespread usage of _id sorting than previously expected. In response to the problem and customer impact, ControlUp temporarily disabled this restriction for affected tenants, including the user’s tenant, to restore functionality while addressing the underlying stability concerns.
The resolution for the user’s scripts was to update their pagination logic to sort and search_after using a real mapped field, such as device name, instead of the internal _id metadata field. This change immediately restored proper API operation without requiring further modifications. The user’s initial script had been generated with assistance from a language model but required this adjustment due to the updated API behavior.
The discussion also raised the topic of API change notifications. ControlUp has yet to provide advance announcements or subscription-based alerts for breaking API changes, which users expressed interest in receiving. ControlUp may consider this feedback to improve communication about future updates.
For users facing similar errors, it is essential to avoid using the internal _id metadata field for sorting or pagination in ControlUp API queries. Instead, rely on indexed, mapped fields to ensure compatibility with recent security and stability improvements to the ControlUp Edge API backend built on OpenSearch.
Relevant ControlUp resources include the official documentation on the Edge API and pagination techniques, available at https://docs.controlup.com, and the ControlUp Academy at https://cuacademy.controlup.com for learning best practices with API integration.
Read the entire article here...
Read the entire article here...
How to Correctly Reference Form Variables in ControlUp Workflows to Retrieve Device IDs
A user developing their first custom workflow in ControlUp encountered difficulty retrieving a specific device ID based on a machine name entered through a form trigger. The intended workflow started with an admin entering the machine "name" value from the _devices index into a form. This form submission was meant to trigger a workflow step that queries and returns only the device_id corresponding to the given machine name.
The user configured the "List Device ID" step to filter devices with the condition name = {{Start.DeviceName}}, expecting to receive one device_id as output. Instead, the query either returned a complete list of around 1200 device IDs or an empty array, failing to isolate the single target device.
The key to resolving this issue was understanding the correct variable reference syntax in ControlUp custom workflows. The user was incorrectly using {{Start.DeviceName}}, but the proper syntax for accessing form input data from the workflow trigger is {{Start.Form.DeviceName}} (or similar, using the start.form series of variables). Updating the filter condition to name = {{Start.Form.DeviceName}} enabled the workflow to correctly narrow down to the exact device and return only its device_id without extraneous results.
This highlights the importance of accurate variable referencing in ControlUp workflows, particularly when using custom form triggers to filter data. When filtering on form inputs, the recommended practice is to use the start.form variables to access form fields. For additional guidance on custom workflow variable usage, referencing ControlUp’s official workflow and automation documentation is advisable: https://docs.controlup.com/controlup-workflows.
Read the entire article here...
Read the entire article here...
ControlUp Community Meetup #17 — ControlUp AI: How It Works, Where It Helps, and What’s Coming
Our latest ControlUp Community Meetup recording is live. Shay Dezaldety breaks down the ControlUp AI Assistant: how it picks the right tools and data from your environment, how RBAC and approval gates keep admins in control, and a live demo troubleshooting poor digital experience, memory and Wi-Fi issues, and BSOD remediation. Copilot, not autopilot.
Read the entire article here...
Read the entire article here...
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 article here...
Read the entire article here...
Support for Boolean Fields in ControlUp Indexes via PowerShell Scripts
A community member inquired about the official support for Boolean columns in ControlUp when written to via a PowerShell script. They noted that their script was functioning as expected, showing a dropdown with options for "true" and "false" instead of a plain text box for the Boolean field. This behavior indicates that Boolean fields are recognized and handled appropriately within the ControlUp system's indexing and UI.
The confirmation came from multiple users, including a ControlUp expert, that Boolean fields are indeed supported. ControlUp's platform supports defining columns with Boolean data types, enabling users to interact with these fields through dropdown selectors for true/false values, which enhances data consistency and ease of use.
This means that scripts or automation workflows that write Boolean values into ControlUp indexes can rely on native support for true/false states. This feature is useful for scenarios where binary states need to be tracked and toggled directly from the ControlUp interface without requiring manual text input.
For more detailed information on supported data types and scripting integration with ControlUp indexes, users can refer to the official ControlUp documentation at https://docs.controlup.com, and consider the ControlUp Academy (https://cuacademy.controlup.com) for deeper learning resources on scripting and data management in ControlUp.
Read the entire article here...
Read the entire article here...
How to Configure AND vs OR Logic with Device Tags in ControlUp Alerts
When configuring alerts in ControlUp based on device tags, a frequent question arises regarding whether selecting multiple device tags in the alert conditions operates as an OR or AND logic. It was clarified that in the current ControlUp alert configuration interface, when multiple device tags are selected, the alert triggers if the device has any one of the specified tags. This means the condition acts as a logical OR between the tags rather than an AND.
The user interface presents these tag selections as checkboxes, limiting the direct ability to express compound AND logic (such as requiring both tags to be present simultaneously). There is no built-in switch or toggle to explicitly select AND versus OR behavior for device tag conditions. While the idea of combining tags using expressions like "tag1&&tag2" was discussed, this is not supported directly within the tag selection box, and typing such expressions does not function as a filter in the UI.
However, a workaround approach involves leveraging multiple alert conditions, which are inherently ANDed together by ControlUp. For instance, instead of trying to combine two tags in one condition, you can create two separate conditions that must both be true, effectively achieving an AND between device tag criteria. Since tags are treated as string fields in the system, operators such as "contains" or "=" can be used in these conditions. Using "contains" is useful but may lead to partial matches, which requires careful tag naming conventions to avoid unintended matches (e.g., "reboot_device" matching both "reboot_device" and "no_reboot_device").
To address this, users have adapted by modifying their tagging strategies to use more distinctive and unambiguous tag names like "device_reboot_yes" and "device_reboot_no," which helps ensure that the use of "contains" or equality checks does not overlap between conflicting tags. Some users also explored adding exclusion conditions (e.g., conditions that exclude devices with certain tags), but these might not cover all scenarios adequately.
The community suggested it would be valuable for ControlUp to enhance alert configuration with explicit AND/OR toggles or support for string operations like "starts with" to improve flexibility for tag-based alerting. Meanwhile, using multiple conditions combined with clear tag naming conventions is the recommended practical approach for achieving AND logic with device tags in alerts.
For more detailed information on alert condition configuration and tag-based filtering, refer to the official ControlUp documentation at https://docs.controlup.com. This includes guidance on condition operators, tag management, and best practices for alert configurations.
Read the entire article here...
Read the entire article here...
Automating Detection and Remediation of Stuck BitLocker Encryption on Windows 11 Endpoints with ControlUp Real-Time Automation Engine
When deploying hundreds of Windows 11 endpoints managed by Intune, a common issue with BitLocker encryption is that the process sometimes becomes stuck at a certain percentage completion. While manually pausing and restarting the encryption process resolves the issue within minutes, automating this detection and remediation can save considerable time and ensure consistent endpoint security.
Using ControlUp Real-Time Automation Engine (CU4D), such automation is achievable by leveraging scripted detection and remediation. One approach is to create a single script that both detects the encryption status and initiates a restart of the encryption process if it remains stuck at the same percentage. This script can be deployed across all affected devices and scheduled to run periodically, for example, once per day, to identify any stuck BitLocker jobs and resolve them promptly.
A more modular approach involves creating two separate scripts: a detection script and a remediation script. The detection script would check the current encryption percentage, and if it identifies a stuck state, it writes the status to a custom index attribute within ControlUp. An alert can then be configured based on the value of this custom attribute. When the alert triggers due to a stuck encryption status, the remediation script executes automatically to restart the BitLocker encryption, ensuring a timely resolution without manual intervention.
This method harnesses ControlUp's ability to store custom scripted outputs in custom indices and link those to alert triggers, thus providing a robust, automated way to handle encryption stalls on Intune-managed Windows 11 devices. For further details on configuring custom scripts, custom indices, and alerts in ControlUp, administrators can refer to ControlUp's documentation at https://docs.controlup.com and explore automation capabilities in the ControlUp Academy at https://cuacademy.controlup.com.
Read the entire article here...
Read the entire article here...
How to Report Horizon Client Versions Across User Sessions Using ControlUp
A common requirement for managing VMware Horizon environments is the ability to report on the endpoint client versions—referred to as "HZ Client Version"—used by users to connect to the Horizon infrastructure. This need becomes particularly important in hybrid environments where users connect from both managed internal devices and unmanaged BYOD (Bring Your Own Device) endpoints. Tracking client versions helps administrators identify devices running outdated Horizon clients that require upgrades to ensure security, compatibility, and optimal performance.
Within ControlUp, the Horizon client version information can be accessed via several mechanisms. The VDI - Details view in the ControlUp console displays the HZ Client Version associated with each session, providing a straightforward way to see the current client version used. For programmatic or historical data extraction needs, ControlUp also offers a real-time data API (https://api.controlup.io/reference/gettables) which can retrieve live session details including client versions. Additionally, the "initial HZ client version" field recorded in the Session Activity report captures the client version that was used to start the session. This field, although labeled as "initial," effectively serves as a snapshot of the client version at session start.
However, because users in hybrid scenarios may connect multiple times throughout the week from different devices or update their Horizon client between sessions (for example, by disconnecting, updating, and reconnecting), it is important to consider that the client version can vary across sessions. The "initial HZ client version" is tied to each individual session start, so accumulating this information over a period allows administrators to identify all versions in use and target users on outdated clients. Pulling session activity reports over time and correlating the client versions used enables identification of BYOD devices needing updates even if the same user connects from multiple endpoints.
In summary, the "initial HZ client version" contained in ControlUp’s Session Activity reports is the key field for tracking Horizon client versions across user sessions. The ControlUp real-time data API further facilitates custom querying and automation for this reporting. For detailed exploration of session data, the VDI - Details view complements these options with an at-a-glance interface. Using these tools, administrators in hybrid environments are able to efficiently monitor and manage Horizon client versions on both managed and BYOD devices, ensuring compliance and performance consistency.
Read the entire article here...
Read the entire article here...
ControlUp Community Meetup 16: From DEX to Autonomous IT: A Fireside Chat with ControlUp CEO Jed Ayres
In this ControlUp Community Meetup, host Douglas Brown sits down with Jed Ayres, CEO of ControlUp, to discuss the growing complexity of IT, the evolution of Digital Employee Experience, and how AI is changing the way technology teams identify and resolve problems.
Read the entire article here...
Read the entire article here...