In ControlUp version 9.2.5.776, a significant issue was identified impacting Omnissa Horizon environments running versions 2412 and 2406. This release introduced a bug affecting the REST API integration used by these Horizon versions, causing disruptions in built-in SYNC functionality and monitoring, including problems with the new Unified Access Gateway (UAG) agentless monitor. The root cause lies in the incompatibility or improper support of REST API versions 3 and 4 by this ControlUp release. Horizon environments 2503 and above, which utilize REST API version 5, were not affected and continued to function correctly.
As a temporary workaround, users in affected Horizon 2412 and 2406 environments can revert their Collectors to use the older SOAP-based method by setting a new registry entry (Use Soap = 1). This older SOAP method, while more resource-intensive and anticipated to be phased out eventually, restores functionality until the bug is fixed. ControlUp has clarified that this is a bug rather than a planned deprecation of REST API support for these Horizon versions, and a fix is actively being developed and will be released promptly.
The issue was initially not reflected in the release notes or documentation, which generally specify Horizon version requirements starting at 2406 or higher for Omnissa Horizon integration. Users should be aware that Omnissa Horizon 8.2412 remains supported until January 28, 2028, underlining the importance of maintaining compatibility. ControlUp's development team is replicating the problem using different 2412 builds to understand the issue fully, noting that the bug seems reproducible with specific builds like 8.14.0 (build 14371628935).
Caution is encouraged for organizations running Horizon 2412 or 2406 environments on this ControlUp version to avoid unanticipated monitoring data loss, as was experienced in some community reports with prolonged missing metrics. ControlUp’s documentation team is preparing to add this issue as a known bug in the current release notes to inform users more effectively until a correction is deployed. For the most accurate and updated guidance, users should consult ControlUp’s official resources at https://docs.controlup.com and seek support if needed.
Read the entire article here...
ControlUp Community Training & Support Archives
All training and support-related archives from inside the ControlUp Community on Slack.
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...
How to Identify Java Process Executable Paths on VDIs Using ControlUp Real-Time Data and Recurring Exports
A common challenge among IT teams managing virtual desktop infrastructure (VDI) environments is identifying the exact executable paths of Java processes running on their VDI machines. In a recent inquiry, a ControlUp user sought to locate Java processes and determine the full execution path of these processes on their VDIs using ControlUp dashboards. Although they were able to create a dashboard widget that revealed the folder structure, they found no direct way to report the full executable path for historical data within ControlUp.
The root cause identified is that ControlUp does not retain the full executable path information as part of its historical data records. Instead, this level of process detail—specifically the executable path—is only available in live, real-time data monitoring. For those needing to track Java process paths over time, this limitation means historical analysis of full executable paths is not natively supported by ControlUp’s historical data collection.
Several users acknowledged that having the executable path data visible and reportable in a historical context would be highly valuable, especially for use cases such as identifying outdated Java runtime versions and understanding diverse Java process usage patterns across an organization’s VDI environment. While real-time data is sufficient for immediate troubleshooting, historical visibility would enhance trend analysis and proactive software management.
As a practical workaround, it was suggested to leverage ControlUp’s live monitoring capabilities combined with recurring data exports using the ControlUp PowerShell module command `Export-CuQuery`. By regularly exporting live process data—including executable paths—over time, teams can build their own longitudinal datasets outside of ControlUp. This approach allows filtering and analysis of Java process paths beyond what the platform currently stores in its historical database.
Regarding the broader context of Java monitoring integration into ControlUp for Azure Virtual Desktop (CU4A), current support remains focused on real-time visibility, with no confirmed release date for extending these capabilities to historical data or enhanced Java-specific monitoring features. Users are encouraged to stay updated through official ControlUp resources.
For further details on ControlUp capabilities, data export options, and dashboard customization, users may consult the ControlUp Knowledge Base at https://docs.controlup.com and the ControlUp Academy at https://cuacademy.controlup.com.
Read the entire article here...
Read the entire article here...
Troubleshooting macOS Agent Crashes with ControlUp 2.18 Release Candidate
ControlUp community members raised a question about the availability of a reference for macOS agent errors and resources for troubleshooting or triaging these errors. This inquiry specifically concerned a crash issue observed with the macOS agent in ControlUp environments. The discussion revealed that the reported crashes were linked to a beta or release candidate version of the macOS agent, specifically version 2.18.
ControlUp experts confirmed that the issue causing these agent crashes had been identified and a fix was underway. Although quality assurance (QA) testing was still in progress, a new release candidate (RC9) of the macOS agent 2.18, which addressed the crash problem, was available. Customers experiencing these issues were offered access to this updated version to prevent further crashes on their tenants.
To facilitate resolution, users were encouraged to share their organization name privately with ControlUp support or directly email support@controlup.com to have the macOS 2.18 RC9 agent enabled on their tenant. This direct support channel ensures that affected customers can quickly obtain the fixed version before a full official release. User feedback in the community was acknowledged as valuable input that helps ControlUp improve the quality and stability of their product.
For ongoing or future macOS agent error triage, users should monitor official ControlUp support channels and documentation, and reach out to support for prompt assistance. ControlUp’s knowledge base and ControlUp Academy (https://cuacademy.controlup.com) are recommended resources for learning about agent troubleshooting best practices. Additionally, emailing support@controlup.com remains the primary route to address specific macOS agent issues, especially during pre-release or fixed-release candidate phases.
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...
Troubleshooting Missing macOS Script Details in ControlUp Event Logs and Resolution via 2.18 RC Agent
Users managing macOS devices within ControlUp reported an issue where script execution events only displayed "script started" and "script completed" messages without showing which script was run or its output. This behavior was a departure from prior functionality, where script details and outputs were visible. Windows devices did not exhibit this problem, and macOS scripts continued to generate output as expected. The concern arose when verifying the actual execution of scripts on macOS devices became necessary, but the ControlUp console failed to surface detailed script information.
Further investigation revealed that ControlUp versions 2.17 and 2.18 for macOS, as well as the Windows version, should include script details in raw event data accessible either through developer browser tools or the ControlUp API endpoint at https://api.controlup.io/reference/get-system-events. However, in the normal device view within ControlUp, the description field showing script details was missing or blank, even though the event index properly contained the script output information. This suggested a user interface issue rather than a complete loss of the event data.
The root cause appeared to be tied to the macOS 2.18 release state. The 2.18 build available was a special release candidate (RC) version, not yet generally available (GA), and it contained fixes targeting this exact problem. Users running this 2.18 RC version (including builds like 2.18.301.5B9E7EB35 and RC9) reported that the issue was resolved in those builds, with script details properly displayed alongside event logs. ControlUp staff offered to enable this release candidate on affected tenants to restore full visibility of macOS script execution events.
In summary, the lack of script detail visibility on macOS devices in ControlUp event views was a recognized bug in releases prior to 2.18. The problem was fixed in the 2.18 RC macOS agent builds, which restored proper logging and display of script names and outputs. Users encountering this should verify their macOS agent version and upgrade to the 2.18 RC or later when it becomes generally available. Meanwhile, script event data can still be queried directly via the ControlUp API or found in event indices, offering a workaround until the UI fully reflects the script details. For more information on monitoring system events and interacting with the ControlUp API, consult the official documentation at https://docs.controlup.com/ and https://api.controlup.io/reference/get-system-events.
Read the entire article here...
Read the entire article here...
Understanding the Absence of Window Title Data in ControlUp’s app_focus Index with End User Activity Module Enabled
In ControlUp's app_focus index, users may notice that the Window Title column does not populate any data despite the End User Activity module being enabled. This was raised by a community member whose security team was interested in accessing window title information for monitoring purposes. The inquiry sought to clarify whether this behavior is expected or if the Window Title should be displaying active window titles as part of its collected data.
Upon investigation, it appears that this behavior reflects a current limitation within the product rather than a configuration issue. The absence of window title data in the app_focus index under the End User Activity module is identified as a gap in functionality. No special settings or additional steps are needed to enable this feature presently because it is not yet supported.
ControlUp's support team acknowledged this shortfall after a preliminary check and initiated the process to address it via a support ticket, indicating the company's commitment to enhancing the module to meet user needs in the future. For now, users requiring detailed window title data for security or monitoring purposes will need to consider this limitation.
For further insights on the End User Activity module and its current capabilities, users can consult the official ControlUp documentation at https://docs.controlup.com or reach out to ControlUp support for updates on feature enhancements.
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...
Troubleshooting Missing Description Field in ServiceNow Tickets Created by ControlUp Templates Due to ACL Permissions
When using ControlUp's built-in templates for creating ServiceNow tickets, such as the Battery/Hardware Replacement Request, users may encounter an issue where the ticket is generated correctly with the appropriate short description, priority, and assignment group, but the detailed description field (result) is not populated. While the description input is visible during the creation process, the corresponding field in ServiceNow remains empty despite the ticket's successful creation.
This symptom typically indicates a permissions-related issue rather than a problem with the template or ControlUp’s integration logic. Specifically, the root cause is often related to Access Control List (ACL) settings in ServiceNow. The integration user account configured in the ControlUp-ServiceNow connection might have the necessary permission to create records but lacks write access for certain fields, such as the Description field on the Incident table. When ServiceNow receives the ticket creation request, it accepts the record creation but silently skips the fields that the user cannot update, leading to the description field being omitted without any error message.
To resolve this, verify that the user configured for the ServiceNow integration has full write permissions to all the required fields on the Incident table, including the Description field. This may involve adjusting ACL rules and permissions in ServiceNow’s user roles and security settings. Testing with an account verified to have full write access confirmed that the Description field populated correctly, indicating the problem indeed lies in ServiceNow’s ACL settings rather than ControlUp itself.
For further troubleshooting, gathering detailed logs from the ServiceNow side and submitting a support ticket along with this diagnostic information can help ControlUp support investigate more complex cases. More information on configuring and troubleshooting ServiceNow integration permissions can typically be found on official ControlUp resources and ServiceNow documentation.
Read the entire article here...
Read the entire article here...