In ControlUp, when executing scripts for Compliance monitoring, it is crucial that the system correctly recognizes and respects the exit codes of these scripts to avoid false positive or false negative compliance reports. One common issue reported involves ControlUp failing to honor the exit codes returned by compliance scripts, which can lead to inaccurate compliance status being displayed.
To address this, users should ensure that their compliance scripts are properly configured and that ControlUp is set up to interpret script exit codes correctly. ControlUp's official guidance on integrating scripts for compliance purposes includes instructions on how to add scripts correctly and manage their execution and return values. This documentation explains how ControlUp evaluates the success or failure of compliance scripts based on the exit codes, and how improper scripting or configuration can cause misinterpretation of compliance results.
The primary resource for resolving issues related to script exit code recognition in ControlUp Compliance is the official support article available at: https://support.controlup.com/docs/how-to-add-scripts-to-controlup-for-compliance. This article provides explicit steps and examples for adding scripts into ControlUp for compliance checks, including how scripts should signal their outcomes through exit codes, which in turn informs the compliance reporting mechanism.
Users experiencing false positive compliance alerts should verify that their scripts are designed to return proper exit codes — typically, an exit code of zero indicates success (compliant state), whereas any non-zero exit code indicates failure (non-compliant state). Correctly following the official scripting guidelines and ensuring scripts adhere to these conventions will help ControlUp generate accurate compliance reports without the issue of false positives due to unrecognized or improperly handled exit codes.
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.
Managing FSLogix Profile Size: Best Practices with ControlUp Monitoring and Profile Cleanup Automation
A community member transitioning from eG Enterprise to ControlUp in a virtual desktop infrastructure (VDI) or remote desktop services (RDS) environment inquired about managing FSLogix profile size through logon or logoff scripts executed by ControlUp. The goal was to reduce profile bloat by deleting specific files within user profiles during session start or end. It was clarified that ControlUp does not support traditional logon or logoff scripts in the classical sense, although it can trigger scripts on events such as "User logged On." This functionality, however, is not ideally suited for the described profile cleanup use case.
Regarding FSLogix profile management, the conversation highlighted that VHD disk compaction is enabled by default in recent FSLogix releases, which automatically helps reduce profile size. However, disk compaction alone may not be sufficient. A practical approach mentioned involved setting up ControlUp alerts to monitor profile conditions—such as low disk space—triggering notifications through ServiceNow tickets for manual intervention by the VDI team. Although automation was still a work in progress, this method added a layer of proactive management.
Another critical recommendation was the use of the FSLogix redirections.xml configuration file. This file allows administrators to exclude certain paths or folders within the user profile—such as temporary files or application cache—from being saved. By strategically excluding these locations, profile bloat can be effectively reduced before it accumulates. The official Microsoft documentation on VHD Disk Compaction (https://learn.microsoft.com/en-us/fslogix/concepts-vhd-disk-compaction) and the redirections.xml configuration (https://learn.microsoft.com/en-us/fslogix/concepts-redirections-xml) provide authoritative guidance on these techniques.
For scripted profile cleanup during user logoff, the community recommended leveraging traditional Group Policy Object (GPO) or Citrix Workspace Environment Management (WEM) tools. One valuable resource shared was Aaron Parker’s Profile Cleanup script (https://stealthpuppy.com/fslogix/profilecleanup/), which is widely used for automating the removal of unwanted files in FSLogix profiles.
In summary, while ControlUp offers monitoring and alerting capabilities that can assist in managing FSLogix profile size, tasks like cleaning profile contents on logon or logoff are better handled by existing scripting mechanisms triggered outside of ControlUp, such as GPO or WEM. Employing FSLogix’s built-in disk compaction and profile exclusion features forms the foundation of efficient profile size management complemented by monitoring workflows for remediation alerts.
Read the entire article here...
Read the entire article here...
Best Practices for Low Disk Space Alerting Using ControlUp Advanced Triggers
A common challenge in managing disk space alerts in ControlUp arises when disk space percentages hover near a critical threshold, causing redundant or false-positive alerts. One user described a scenario where they used two separate triggers: one to alert when disk space dropped below or equal to 10% for 30 minutes, and a second trigger to fire an "all clear" alert when disk space rose above 10% for 30 minutes. This setup, however, resulted in frequent false positives, especially with the "all clear" alert, due to disk space fluctuating near the 10% boundary.
The root of the problem lies in the independent nature of these two triggers and their durations. For example, if disk space dips below 10% briefly and then recovers, the separate all-clear trigger fires independently, which is often unnecessary or too noisy. The discussion clarified that ControlUp triggers do not chain, meaning one trigger cannot wait for another to fire before acting. Because of this limitation, managing disk space alerts effectively requires a different approach.
The recommended solution is to use a single Advanced Trigger that monitors logical disks rather than entire computers, applying a filter such as free space less than 10%, capacity above 10 GB (to exclude system or recovery partitions), and optionally focusing on specific volumes like the C: drive for operating system disks. This Advanced Trigger should be set with a duration of around 30 minutes, where the incident opens only after disk space has been below 10% continuously for that period. Importantly, the incident only closes automatically when disk space has been above 10% continuously for 30 minutes. This approach eliminates false positives caused by short dips or recoveries because no alert is generated unless the threshold is crossed for the full time duration, and the all-clear condition is represented by the incident resolution—no separate "all clear" trigger is necessary.
Additionally, setting a minimum time between incidents (such as 1 to 4 hours) can help prevent repetitive alerts for the same disk volume oscillating near the threshold. This strategy ensures alerts are meaningful and actionable, reducing alert noise in environments where disk space fluctuates near critical levels.
For more details on configuring Advanced Triggers and alert management in ControlUp, users can refer to the official ControlUp documentation and the ControlUp Academy: https://docs.controlup.com and https://cuacademy.controlup.com.
Read the entire article here...
Read the entire article here...
Automating Device Group Assignment in ControlUp Workflows Using Registry Key Data
A community member inquired about automating device group assignment in ControlUp based on a specific registry key value. The initial approach discussed involved writing a PowerShell script to read the registry key and create a custom index in ControlUp, which could then feed into a workflow for moving devices to the appropriate device group. This method also opened possibilities for using the data in dashboards, creating alerts for registry changes, and triggering remediation workflows.
A practical PowerShell script example was shared to demonstrate how to write, read, and output a registry key value under the current user (HKCU). This script was integrated with ControlUp’s Device Events by printing the output between defined event markers. Subsequently, a more detailed script was contributed, which collects registry information along with system and timestamp metadata, outputs it as a compressed JSON object, and supports error handling if the registry key access fails. This script is intended to run periodically to populate ControlUp’s data index, providing the basis for alerting and workflow triggers.
The recommended implementation steps include adding the script to the environment to gather registry data regularly, setting up alerts to trigger on specific registry values, and using ControlUp workflows with webhooks to move devices to the correct device groups based on the registry data. While alerts were initially used for this purpose, the community acknowledged the drawback of proliferation—needing many alerts for multiple groups—and expressed a preference to rely more on workflows for automation, preserving alerts for genuine issues.
To advance beyond alerts, the suggestion was made to leverage ControlUp’s API to retrieve custom data directly, enabling workflows to act on this real-time data without spawning numerous alerts. This approach supports scalable device management workflows, automating group assignments effectively. A recommendation was offered to engage ControlUp Customer Success Management (CSM) or Professional Services for further assistance with complex workflow setups integrating API data extraction. The discussion underscores the evolving use of ControlUp’s scripting, alerting, and workflow capabilities to streamline device group management based on registry key states.
For further reference, ControlUp’s official documentation on custom data scripting, workflows, and alerts can be found at https://docs.controlup.com, and detailed learning modules are available via ControlUp Academy at https://cuacademy.controlup.com.
Read the entire article here...
Read the entire article here...
How to Pass Command Output Between Workflow Steps in ControlUp Using Data Index as a Workaround
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...
Read the entire article here...
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...