A common challenge faced by ControlUp users involves timely updating of endpoint data, especially when tracking specific services or applications. In one case, a user wanted to confirm the removal of a service on endpoints but found that ControlUp still reported the service as running despite manual removal. This discrepancy occurs because the ControlUp agent updates different types of metrics at varied intervals. Core system metrics typically refresh every 60 seconds, but certain metrics such as service status and installed applications are updated less frequently—services refresh hourly (and shortly after a system reboot), while installed applications update only once per day.
This update schedule means that relying solely on on-demand refresh within ControlUp for some metrics is limited, as there is no built-in immediate refresh capability for services or installed apps. To overcome this, users can create a Custom Action script to gather the needed data on-demand. By scripting, users can query the current service status or application state directly from the endpoints and write the results to a custom data index in ControlUp. This approach provides a precise and immediate reflection of endpoint conditions without waiting for the default agent update cycle.
ControlUp’s scripting capabilities are documented in detail in the official scripting guide, available at https://support.controlup.com/docs/scripting-guide. This guide helps users build custom scripts that integrate into ControlUp workflows, enabling on-demand data collection tailored to specific monitoring or troubleshooting needs.
As of now, no direct feature exists within ControlUp to force an on-demand refresh of hourly or daily metrics such as service and installed app status, but leveraging Custom Action scripts offers an effective workaround. Users looking to improve real-time monitoring of endpoint services should consider implementing these custom scripted solutions until such features potentially appear on future ControlUp development roadmaps.
Read the entire article here...
ControlUp Community Training & Support Archives
All training and support-related archives from inside the ControlUp Community on Slack.
Understanding and Configuring the Location Field for Citrix Cloud Sessions in ControlUp
In ControlUp's Sessions view, the Location field may appear blank even when session information like Client IP is correctly populated. This is because the Location column is specifically linked to Citrix Cloud environments and represents the "resource location" of Citrix Cloud Sessions, not the client's geographic location or data coming from Remote DX. The field corresponds to the `CitrixCloudColumns.Location` attribute in the ControlUp schema, which pulls its data from Citrix Monitor OData through the ControlUp Citrix Cloud EUC connection.
For Citrix Cloud users, ensuring the Location field populates requires that resource locations be properly configured and assigned within the Citrix Cloud administrative portal. Administrators should verify that their resource locations are defined in the Citrix Cloud admin portal under Resource Locations and that these are correctly associated with their sessions and resources. Without proper resource location assignment, ControlUp cannot display this information in the Location column.
This functionality is specific to Citrix Cloud and does not apply to on-premises Citrix deployments or other remote services. It also does not derive from ControlUp Remote DX or other integrations; rather, it depends strictly on the integration between ControlUp and Citrix Cloud session data via the Citrix Monitor OData feed.
To summarize, if the Location field is blank in ControlUp for Citrix sessions, the key step is to confirm that resource locations are configured and assigned within the Citrix Cloud portal. Proper configuration ensures that ControlUp can retrieve and display the location data as intended.
Read the entire article here...
Read the entire article here...
Changes to Default Filters for Synthetic Monitoring Scouts in ControlUp and How to Manage Disabled Scouts
ControlUp made a recent change to the default filter behavior for synthetic monitoring scouts within their platform. Previously, scouts that were disabled via workflows, such as those scheduled to run only certain times of the day, still appeared in the default Scouts view. With the update, disabled scouts no longer show up under the default filter, effectively narrowing the default display to only active scouts. This change was implemented to provide users with a clearer and less cluttered view focused on currently running synthetic monitoring instances.
As a result, users with scouts enabled and disabled dynamically through workflows may need to manually adjust their filters to locate and manage disabled scouts. Specifically, to view scouts that are currently disabled, users must explicitly apply a filter that includes non-active scouts since they will no longer appear by default.
This adjustment aims to improve user experience by reducing confusion and improving table clarity when managing synthetic monitoring. Users are encouraged to provide feedback to ControlUp if this change affects their workflow or if they have suggestions for further improvements. For additional configuration tips about synthetic monitoring scouts and filters, users can refer to the ControlUp official documentation and knowledge base at https://docs.controlup.com.
Read the entire article here...
Read the entire article here...
Overcoming the 100-Device Limit in ControlUp Workflow’s List Devices Node
The ControlUp Workflow *List Devices* node has a built-in limit of returning only 100 device records per query. This limitation affects workflows attempting to process larger device inventories, such as fetching or looping through over 100 devices. The loop node itself does not have a limit and processes all records provided by the *List Devices* node. Therefore, the root cause of the problem is the *List Devices* node restricting the dataset to 100 devices, not the loop processing.
Users trying to obtain results for 500 or more devices found that the *List Devices* node response capped at 100, blocking workflows from scaling to larger environments. Currently, no filters or tags applied change this default limit on the *List Devices* node response. This cap is separate from volume limits related to data size, such as the 1GB flow size limit.
As a recommended workaround to bypass this 100-device limit, users can employ the *Get Custom Data* node to execute custom Data Access Layer (DAL) queries. By enabling the "Get all records" option in this node, workflows can retrieve all devices in the organization without the 100-device limitation. This method was tested successfully with over 400 tagged devices, confirming its viability for larger inventories.
ControlUp representatives acknowledged the 100-device limit in the *List Devices* node and indicated plans to consider removing or adjusting this restriction in future updates. Until then, users needing to work with more than 100 devices in workflows should use custom DAL queries via *Get Custom Data* as the primary method to retrieve full device lists.
For further details, users may consult the ControlUp Knowledge Base and official documentation on Workflows and DAL queries at https://docs.controlup.com. The *Get Custom Data* node and its "Get all records" feature provide a powerful alternative for advanced workflow scenarios that require comprehensive device data beyond the standard node limits.
Read the entire article here...
Read the entire article here...
Troubleshooting Missing Usernames and Metric Data in ControlUp Process Monitoring Dashboards and Stat Widget Limitations
A common issue encountered with ControlUp dashboards involves inaccurate reporting of process start times and user counts, specifically with high numbers of users and processes that initiate immediately after login. In a troubleshooting case, a community member observed that the Netskope client was not routing traffic to on-premises file shares for 5 to 10 minutes post-login. They wished to confirm through a dashboard or report that the service in question (stAgent process) started almost immediately after user login. However, the dashboard filtered to this process was showing many "N/A" values for relevant metrics, and the total user count was about 900 fewer than expected.
The core technical challenge was identified as a data collection nuance related to where process data originates and the timing of process starts relative to the SIP (Session Initiation Protocol) agent. It was clarified that the metrics came from "process stops" indices. Users noted that usernames were sometimes missing from these entries because the process starts before the SIP agent logged the user identity, leading to incomplete user data capture. Additionally, the "app_launch_time_ms" metric was missing for some process start events, likely due to this timing discrepancy. Differences were highlighted between two different data sources, "process_stops" (Windows-focused) and "builtin_process_stop" (Mac-focused), explaining variations in available metric details.
Another topic discussed was the limitation encountered when interacting with Stat widgets in ControlUp dashboards. When clicking on a stat card representing many devices (e.g., 2000 unique device IDs), the drill-down view only displayed up to 500 devices, causing confusion and incomplete visibility. This limitation was acknowledged as potentially unintentional and slated for further investigation. The community debated the practical need for disabling this drill-down feature in some dashboards, with consensus that although direct action on large device sets might be unusual, users still expect full visibility matching the dashboard summary counts.
From a solution perspective, filtering widgets by exact username with a negation filter was suggested to show only entries with recorded usernames, assisting in troubleshooting user data completeness. The issue with incomplete metric values related to early-starting processes remains a technical limitation tied to data collection timing, without an immediate fix but with suggested workarounds for filtering and interpreting available data.
In summary, to troubleshoot processes that start immediately after login but show incomplete metrics or user data in ControlUp dashboards:
- Understand the difference between the Windows "process_stops" and Mac "builtin_process_stop" indices and their data characteristics.
- Recognize that processes starting before the SIP agent registers the user can result in missing usernames and launch time metrics.
- Use filtering techniques to isolate entries with valid usernames.
- Be aware of drill-down limits on Stat widgets (currently capped at displaying 500 devices), which affects visibility on large datasets.
- Monitor ControlUp updates for potential removal or adjustment of drill-down limits.
For more details on dashboards, filtering, and process monitoring in ControlUp, refer to the official documentation at https://docs.controlup.com, and for dashboard customization best practices, visit https://cuacademy.controlup.com.
Read the entire article here...
Read the entire article here...
How to Ensure ControlUp Compliance Scripts Correctly Return and Respect Exit Codes to Avoid False Positives
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...
Read the entire article here...
Resolving Data Conversion and Rounding Errors in ControlUp Out-of-the-Box Dashboards
A community discussion surfaced an issue regarding inaccurate data conversions and rounding errors observed in ControlUp's out-of-the-box (OOB) dashboards, particularly noticeable on a large screen dashboard but also present in other OOB dashboards such as the Employee Activity dashboard. The discrepancies appeared to be related to the way time values were displayed, potentially involving milliseconds that might require additional conversion or division to display correctly.
Upon investigation, this behavior was suspected to be isolated to a specific tenant, prompting others in the community to verify and confirm whether they were experiencing similar issues. The problem was quickly identified as a bug affecting these dashboards' data presentation.
The ControlUp support and development team acknowledged the bug and promptly worked to resolve it. Following their intervention, the dashboards were updated and fixed so that the data conversions and rounding errors no longer occurred.
This incident highlights the responsiveness of the ControlUp team in addressing data accuracy issues in real-time monitoring dashboards. Users encountering similar symptoms in OOB dashboards displaying time-related metrics should ensure their software is updated to the latest version where this bug fix is included. For additional troubleshooting or updates, consulting ControlUp’s official documentation at https://docs.controlup.com and the ControlUp community forums is recommended.
Read the entire article here...
Read the entire article here...
Introducing Blueprints for MSPs: Streamlining Multi-Tenant Configuration Management in ControlUp
ControlUp has launched Blueprints as a generally available feature specifically designed for Managed Service Providers (MSPs) to streamline the management of configurations across multiple customer tenants. Blueprints enable MSPs to create reusable configuration templates that can be applied consistently across various tenant environments. This approach helps reduce repetitive administrative tasks, standardizes deployments, and saves time in both onboarding new customers and maintaining existing tenant fleets.
The Blueprints feature supports creating templates for configurations that MSPs commonly use and allows for customization by adding or overriding specific settings to meet individual tenant requirements. Additionally, Blueprints includes version tracking and a diff preview function, which facilitates reviewing changes between different versions of configuration templates, ensuring accuracy and control over modifications.
MSPs with Tenant Manager access can now use Blueprints to efficiently roll out standardized configurations across their managed environments. This capability is particularly valuable for improving operational consistency and simplifying management workflows. Detailed documentation and guidance on using Blueprints are available at ControlUp’s support site: https://support.controlup.com/docs/blueprints.
MSPs adopting Blueprints can expect to save significant time and effort in tenant configuration processes, thus enhancing their service delivery efficiency and consistency.
Read the entire article here...
Read the entire article here...
Efficiently Combining and Processing Large Index Datasets in ControlUp Workflows Without Native Loop Constructs
A community member faced challenges building a workflow in ControlUp to combine two indexes dynamically for a nightly dashboard summarizing the previous day’s environment status. The primary difficulties arose from limitations in the workflow engine compared to PowerShell scripting, particularly related to looping constructs, array size management, and efficient data handling. Attempting to accumulate all data into a single large array caused performance degradation, and efforts to split data handling into groups of 100 records ran into issues because workflows lacked a traditional for-loop or the ability to reinitialize variables inside loops.
ControlUp experts clarified that appending to arrays in loops is generally inexpensive, but performance issues often stem from JSON modification or calculation nodes that operate on the entire array each iteration. Instead of keeping large arrays in memory, a recommended pattern is to flip the subflow logic: allow the subflow to write records directly to the target custom index and return no data to the main flow. The main flow can paginate data requests using Get Custom Data (which supports paging via from/size parameters), looping over pages where each subflow processes one page end-to-end, avoiding large in-memory arrays and reinitialization challenges.
To emulate traditional loop behavior, a “fake while loop” workaround was suggested by creating a dummy array representing the number of iterations desired (e.g., 20), then looping over that array. Combined with OpenSearch’s partitioning (`include > partitions` and `include > num_partitions`), this approach divides large datasets into manageable buckets processed in separate iterations. The configuration can be sized to match the environment—for example, capturing 4,000 records per iteration across 20 iterations to cover up to 80,000 results, adjustable as needed.
A practical example from the discussion involved combining device data from two ControlUp indexes: one filtering Windows devices by specific event logs, and the other fetching device information filtered by the extracted device IDs. Merging these on the device ID with the "Preserve structure from: both" option enabled results in a unified dataset ready for further processing or custom indexing. This workflow ran efficiently in about four seconds on test data. To control data volume, filtering steps were added to isolate devices exhibiting significant event counts (e.g., more than 5 events in 24 hours), which reduced processing load while focusing on impactful network issues.
The conversation highlighted the current lack of a native "for" loop feature in ControlUp workflows, but noted this capability is planned for future releases. Meanwhile, users can leverage paging, subflows writing directly to indexes, and OpenSearch partitions to manage large datasets effectively. Per-iteration writes to custom indexes are feasible if API rate limits and retry logic are properly handled. For large data reads, Get Custom Data is preferred over Get Data Index because of its paging capabilities. These insights provide a reliable framework for users needing to aggregate and analyze dynamic multi-index data in ControlUp workflows while balancing performance and complexity.
For additional guidance on ControlUp workflow nodes and custom data handling, refer to ControlUp’s official knowledge-base and documentation at https://docs.controlup.com and https://cuacademy.controlup.com.
Read the entire article here...
Read the entire article here...
How to Apply and Save Filters on ControlUp Dashboards and Widget Pages
ControlUp users seeking to filter dashboard results by specific criteria such as operating system or Delivery Group encounter a limitation in the product’s current functionality: while filters can be applied within a dashboard, these filter settings are not saved as part of the dashboard’s configuration. Instead, filters and time frame selections are temporarily stored within the URL. This means that users can preserve a filtered view by bookmarking or sharing the URL, but these preferences are not inherently saved or persist when navigating through the web user interface (UI) dynamically from one dashboard to another.
ControlUp has acknowledged this limitation and confirmed that a more user-friendly graphical interface (GUI) for saving dashboard views—including filters and time selections—is under development, with an anticipated release in the fourth quarter. Until this feature is available, the only practical method to save a filtered view involves using the URL, which has drawbacks in user navigation experience, especially for environments where multiple users need to explore dashboards dynamically and consistently see predefined filtered content.
A similar issue arises with VDI widget pages, which are distinct from dashboards but also involve filtering by Delivery Group. Filtering individual widgets to focus on specific Delivery Groups currently does not allow saving these filter states or drills down into more detailed views for specific groups. The “Focus on” feature can selectively highlight certain items via the UI’s left-hand column, yet these views cannot be saved or preconfigured to tailor environments for end users.
The ability to create and save predefined, filtered screens tailored to different audiences remains a highly requested feature for creating controlled, user-friendly environments. Users and administrators want to build customized views that persist across sessions and are easy to navigate, but currently must rely on URL-based workarounds. Until the upcoming GUI enhancements are released, best practice includes creating bookmarks with specific filter parameters encoded in URLs and educating users on navigating with these bookmarks for a more consistent experience.
For official updates on saving dashboard views and filters in ControlUp, monitoring release notes and the Knowledge Base at https://docs.controlup.com is recommended. Further learning resources are available through ControlUp Academy at https://cuacademy.controlup.com.
Read the entire article here...
Read the entire article here...