When IP Restrictions are enabled in a ControlUp organization, they apply not only to user sign-in at app.controlup.com but also to REST API calls that use API keys or tokens for authentication. Initially, there was confusion about this behavior, with one party assuming that IP Restrictions only affected user sign-ins via the web application and would not restrict API calls. However, further investigation clarified that IP Restrictions do indeed apply to API requests.
The key issue encountered was that reporting workflows that fetch machine statistics via the REST API started returning "Unauthorized" errors after IP Restrictions were enabled. Although the API tokens used for authentication were verified as valid and not expired, the requests failed due to the IP restriction settings.
The resolution involves adding the public egress IP addresses of the systems making the API calls (such as those running the reporting workflows) to the organization's IP Allow List in ControlUp. This setting is accessible under Settings → Security → IP Allow List in the ControlUp management console. Once the calling system’s IP addresses are added to the allow list, API calls from those IPs will be authorized, provided a valid API token is also used.
For more detailed guidance, official ControlUp documentation and references include the API endpoint for managing IP allow lists (https://api.controlup.io/reference/orgipallowlistpubliccontroller_create) and the knowledge base article on IP Allow Lists (https://support.controlup.com/docs/ip-allow-list). These resources offer comprehensive instructions for configuring the IP Allow List to control API access securely.
Read the entire article here...
Reporting Related Training & Support Archives
Reporting training and support-related archives from inside the ControlUp Community on Slack.
NEW ControlUp Disk cleanup script that actually asks the user what to delete
Chris Twiest demos a new interactive disk cleanup utility built by Sebastien Perusat and now baked into the product. Instead of silently cleaning from the system context, it prompts the end user with what can be reclaimed and lets them choose — recycle bin, temp files, browser cache. Works on Windows and macOS, can be triggered manually or from an alert, writes results to a data index and a device event, and is fully editable. Available in the script library now.
Read the entire article here...
Read the entire article here...
How to Preserve Static Filters When Copying ControlUp Dashboards
In ControlUp dashboards, users may desire to create copies of a dashboard with pre-set filters that remain consistent and "locked" across multiple instances or devices. However, a limitation exists in that filters on copied dashboards reset to default values rather than preserving the original filter settings. This is because filter states are saved within the URL, allowing users to copy or bookmark filtered views.
At the time of the inquiry, a reported bug prevented these filters from automatically restoring when a dashboard was copied or opened from a saved URL. This issue affected workflows where multiple dashboard copies were needed with static filter criteria for consistent monitoring or reporting. ControlUp acknowledged the bug and targeted a resolution by mid-August.
The issue has since been resolved, enabling filters to properly restore from the URL when duplicating or accessing dashboards. While users can facilitate quick filter selection with variables, the fix now ensures filter states remain persistent as intended when copying dashboards, thus supporting more effective and static customized dashboard scenarios.
For further details on dashboard filter functionality and managing variables, users can refer to the ControlUp Knowledge Base and related documentation available at https://docs.controlup.com. The ability to save and restore filter states enhances dashboard usability, particularly in environments requiring consistent monitoring views across multiple devices or team members.
Read the entire article here...
Read the entire article here...
Troubleshooting “Detect Workspace” Stuck Prompt for Citrix Cloud Synthetic Monitors on Public Hives
Some users running synthetic monitors to test Citrix Cloud connections from public hives reported that a few monitors become stuck at the "Detect Workspace" prompt. This behavior was inconsistent, with some monitors seemingly configured the same way functioning normally while others encountered this issue.
The root cause was identified as related to the Citrix Workspace store’s launch method settings. The "Detect Workspace" screen corresponds to the Citrix client detection page, which is controlled on the store side rather than by Scoutbees or the synthetic monitors themselves. Specifically, when the store is configured with the "Launch virtual apps and desktops" setting set to either "Open in Citrix Workspace app" or "Let the user choose," this page appears. On public hives, where the browser environment is fresh and does not retain prior user choices, the prompt recurs on every run, causing the monitors to stall at this screen.
To resolve this, it is necessary to verify and compare the launch settings in Citrix Cloud under Workspace Configuration (or the targeted StoreFront store). Monitors stuck on the detection prompt typically point to stores configured with "Open in CWA" or "Let the user choose," while those that bypass the prompt are connected to stores set to "Use web browser to access apps and desktops." Changing the store’s launch setting to "Use web browser" bypasses the native Citrix Workspace app detection page, allowing the synthetic monitors on public hives to proceed without interruption.
Before making any changes, administrators should confirm these settings by comparing the store configurations between monitors that are stuck and those that are working. This ensures an accurate diagnosis and prevents unintended side effects from changing the launch mode. Since this is a store-level configuration, it requires adjustments within the Citrix Cloud management console, specifically under Workspace Configuration. If the issue persists or if the public hive environments themselves seem problematic, submitting a support ticket for those specific hives is recommended.
For additional guidance on managing Citrix Cloud Workspace configurations and optimizing monitor setups, see the ControlUp Knowledge Base and Citrix documentation on Workspace Configuration: https://docs.controlup.com and https://docs.citrix.com/en-us/citrix-cloud/workspace-configuration.html.
Read the entire article here...
Read the entire article here...
ControlUp Community Meetup 15: How to: Connecting MCP AI to your Real-Time Data
Learn how to connect AI to live enterprise data using the ControlUp MCP Server. In this session, Chris Twiest explains the fundamentals of Model Context Protocol (MCP), including LLMs, prompts, system prompts, tool calling, and retrieval, before demonstrating how to connect Claude Desktop to ControlUp. Watch a live walkthrough of configuring the MCP Server, querying real-time endpoint data, visualizing application crashes, comparing results against historical baselines, and using system prompts to dramatically improve AI accuracy. The session also explores practical use cases, including upgrade planning, combining multiple MCP servers, building custom AI interfaces, and the future of autonomous endpoint management.
Read the entire article here...
Read the entire article here...
Investigating Historical Network Usage Spikes and Setting Alerts with ControlUp for Desktops
A user reported a network performance issue at one of their offices where a single computer had downloaded and uploaded several gigabytes of data within approximately the last four hours. They sought a way to determine exactly what data was downloaded and where it was uploaded to after the fact.
ControlUp experts clarified that while ControlUp for Desktops can provide detailed network usage volume information retrospectively, it does not store historical data about the specific destination addresses or detailed process-level network activity. The device’s Performance tab includes historical charts such as Network Usage (MB/s) and Hourly Network Usage (MB), which show the volume of data sent and received over time. This helps confirm the timing and magnitude of a network spike but only at the overall device level, not by specific process or destination.
For live, real-time network connection details—including which process is communicating with which remote IP address—the Network tab and TCP Connections Map can be used. This tab shows detailed, process-to-destination connections but does not retain historical data, so it only helps monitor ongoing network activity. Consequently, if the large data transfer activity occurred several hours ago and is no longer ongoing, ControlUp itself cannot provide retrospective insights into the process or endpoints involved.
To investigate historical transfers of this nature, network security and monitoring should be supplemented with firewall logs, proxy logs, or netflow data, which retain detailed connection records over time. This approach is recommended for network administrators with access to those tools.
For prevention and proactive detection, users can configure static threshold alerts in ControlUp to notify them immediately if network usage exceeds a predefined value in the future. This allows administrators to catch high-volume transfers as they happen and investigate using real-time detail from ControlUp. The documentation for setting static threshold alerts can be found here: https://support.controlup.com/docs/devices-static-threshold-alerts.
Additional guidance on real-time network analysis is available at https://support.controlup.com/docs/live-network-analysis.
Read the entire article here...
Read the entire article here...
How to Implement Native macOS and Windows Self-Service Disk Cleanup via ControlUp Edge DX Without External Tools
A ControlUp community member developed a native self-service disk cleanup solution for macOS and Windows users, designed to be triggered via ControlUp Edge DX without requiring IT intervention or external tools. The goal was to allow users to safely free disk space through a simple, native dialog that displays current disk usage and offers a checklist of safe-to-clean areas such as Trash, application caches, container caches, logs, Xcode build cache, and old temporary files. Each item is described in plain language and sorted by the space it occupies, allowing users to select and confirm the cleanup themselves.
On macOS, the dialog is implemented using only built-in osascript capabilities—no additional tools like swiftDialog or extra installations are necessary. For both macOS and Windows, the solution emphasizes safety by running a dry-run by default, excluding critical system folders and personal directories such as Documents, Downloads, Keychains, and SSH keys from cleanup. The cleanup operates within the context of the logged-in user, not root, ensuring user-specific data protection. After cleanup, the system verifies the amount of space reclaimed against the actual free volume.
Triggering this cleanup from an Edge DX alert, either automatically due to disk usage thresholds or on-demand, enables a small dashboard that reports on reclaimable and freed disk space, all without requiring elevated permissions, Intune writes, or admin consent. One of the more challenging technical aspects was delivering the cleanup dialog from a root-level agent into the user’s session, given the restrictions of macOS and Windows environments.
The community member shared that while the script could likely be optimized or shortened by more experienced developers, this version works reliably and safely. Detailed setup documentation is available by request. Additionally, to complement the cleanup tool, the developer created an analytics dashboard to track the cumulative space saved by the script. This solution offers a practical way for organizations using ControlUp Edge DX to empower their end users with safe, controlled disk cleanup capabilities, minimizing helpdesk workload without compromising disk security or user privacy.
For more on creating and managing custom alerts and actions within ControlUp Edge DX, consult the official documentation at https://docs.controlup.com/edge and explore ControlUp Academy at https://cuacademy.controlup.com for training on extending ControlUp functionality.
Read the entire article here...
Read the entire article here...
Analyzing Windows Client Boot Time Delays: Using External Scripts to Generate Boot Performance Reports in ControlUp Environments
A community discussion sought an effective method to analyze Windows client boot times with detailed insights into the causes of any delays. The original inquiry focused on whether there was an existing script or dashboard capable of breaking down boot delays, as the environment faced issues with slow client startups. Such diagnostics would provide valuable information to address client performance problems.
In response, a community member shared a beta script designed as a boot analyzer, which generates an HTML report summarizing boot performance. This script creates an output that visually breaks down boot times, helping identify the components or processes causing delays. However, the script does not currently save boot information within the ControlUp platform because the ControlUp agent is not active during the Windows boot phase, preventing direct integration of boot data into ControlUp's indexes.
While the script is substantial and complex, it offers a practical starting point for environments needing detailed boot-time diagnostics. The contributor noted the lack of time to fully test writing the boot data to the ControlUp index but confirmed the HTML report format is functional and aesthetically clear. The shared approach highlights the current workaround for boot analysis within ControlUp environments: external data collection and report generation rather than native ControlUp indexing, due to agent limitations during system startup.
For users seeking to monitor boot performance in Windows clients using ControlUp, this solution involves running external scripts to analyze boot metrics and then reviewing detailed offline reports. Until ControlUp supports native boot-time data collection via its agent during the startup phase, such scripts provide the most direct method to diagnose and troubleshoot boot delays.
Read the entire article here...
Read the entire article here...
How to Alert on Added Storage Devices by Drive Letter in ControlUp Using os_disk_configuration Filters
A community member sought assistance with creating a ControlUp trigger or alert to detect when storage devices are added to a physical endpoint and assigned a drive letter or mounted. The data relevant to this event is visible in the ControlUp 4D (CU4D) Performance tab under the Operating System location and stored in the *_devices* index. Specifically, the data is found in the os_disk_configuration field, which contains a JSON array showing details about mounted drives, including drive letters. The user’s challenge was to configure an alert that could detect any newly mounted drive except the system drive C:\ without having to set multiple alerts for every potential drive letter (e.g., D:\, E:\, etc.). They noted the lack of regex support in the filter queries limited their options.
The issue arises because the os_disk_configuration field holds a JSON array with multiple drive entries, and filtering out drive_letter "C:\" naively removes all entries due to the structure of the array. Attempts to use a “does not contain” filter eliminated all Windows devices, only showing macOS devices, complicating detection on Windows endpoints. The user also tried to narrow the focus to removable media but learned that their security team's use case requires alerting on any disk, mounted by drive letter, which remains the best indicator available.
Advice provided during the discussion included adding filters for platform or OS to ensure the alert targets only Windows devices (e.g., platform set to 1 or OS equals Windows). This helped reduce irrelevant results but did not completely solve the filtering problem. Suggestions included playing with additional filters such as combining conditions to exclude drive_letter "C:\" while explicitly including removable devices, though this required trial and error. A recommendation was to test filter configurations in the CU4D index view, including setting the platform to 1 to target Windows devices specifically.
Ultimately, the thread highlights the challenge in using ControlUp’s current filtering capabilities on complex JSON arrays like os_disk_configuration for dynamic drive letters without regex support. The workaround involves narrowing the scope by platform/OS filters and experimenting with composite negation filters, although a straightforward out-of-the-box solution for this specific alert scenario is limited. Users needing comprehensive coverage for any drive letter other than C:\ must create a series of alerts or await enhanced filter features. For now, leveraging the detailed disk configuration data in the *_devices* index with strategic filter layering is the best approach.
For further reading on creating and troubleshooting alerts and filters in ControlUp, users can consult official documentation at https://docs.controlup.com and explore ControlUp Academy resources at https://cuacademy.controlup.com.
Read the entire article here...
Read the entire article here...
How to Diagnose Microsoft Teams SlimCore Optimization in Citrix and Other VDI Environments Using PowerShell Scripts
This discussion highlights two PowerShell scripts developed to aid tracking and diagnosing Microsoft Teams SlimCore Optimization specifically within Citrix environments, with potential applicability to Azure Virtual Desktop (AVD), Windows 365 (W365), and VMware Horizon sessions. SlimCore is an optimized media stack used in virtual desktop infrastructure (VDI) scenarios to enhance Teams call performance by offloading audio and video processing to the client side.
Read the entire article here...
Read the entire article here...