Several ControlUp community members discussed how to configure a trigger to automatically log off idle users from Azure Virtual Desktop (AVD) hosts using the ControlUp Agent for Virtual Desktop Infrastructure (VDI). One common solution is to leverage existing trigger packs within ControlUp, which include triggers designed to log off a user session after a specified period of inactivity. These triggers can be customized based on time thresholds that fit the organization’s session management policies.
An example script and detailed guidance were shared from ControlUp’s official script library, which provides automation for disconnecting or logging off idle sessions. This script can be adapted and deployed within ControlUp's automation policies to monitor session activity and log off users automatically when idle thresholds are met. The relevant resource is available at https://www.controlup.com/script-library-posts/disconnect-or-log-off-idle-sessions/.
Additional insights were shared from a ControlUp blog post that focuses on session resource optimization through automation. This post outlines best practices and practical examples of using ControlUp automation to manage session states efficiently, including auto-logout for idle sessions. The blog can be found here: https://www.controlup.com/blog/controlup-automation-session-resource-optimization/.
While native solutions like DaaS IQ might offer built-in functionality for auto-logging off idle users, many organizations have adopted ControlUp triggers as a practical workaround until formal approval or integration of native options is completed. The combination of ControlUp’s flexible triggers and scripting capabilities allows administrators to enforce session timeout policies effectively within AVD environments, optimizing resource utilization and enhancing security.
Read the entire article here...
Scripts Related Training & Support Archives
Scripts training and support-related archives from inside the ControlUp Community on Slack.
How to Create CPU Usage Alerts in ControlUp That Exclude Restart and Boot Spikes
A common challenge in monitoring CPU usage is avoiding false alerts during system restarts or boot periods, when CPU spikes are normal but typically short-lived. One effective method to address this in ControlUp is to configure an alert rule targeting the device_status data index with specific conditions to filter out these transient spikes.
To create a CPU alert that excludes restart or boot-phase spikes, set up a static threshold alert on Devices with a condition such as cpuload > 80 (adjust the threshold based on your environment). The key element is applying a time window and hit count that accommodates short bursts without triggering alerts. For example, use a time window of 600 seconds (10 minutes) and require 5 hits within that period before the alert fires. Additionally, a retrigger delay of 3600 seconds (1 hour) helps reduce repeated alerts for sustained high CPU usage.
This configuration works because CPU usage during boot or restart typically spikes briefly and does not persist long enough to meet the hit criteria within the time window, thereby filtering out most false positives without complex logic. For situations where CPU remains elevated for longer periods during boot—due to updates, login scripts, or heavy startup applications—it is recommended to implement an uptime check or guard. This further refines alerting by ensuring the system has been running beyond a certain uptime threshold before alerts activate.
These steps provide a practical approach to balancing sensitivity and noise in CPU alerting, improving monitoring accuracy in environments where restarts cause predictable, short-term CPU spikes. For more detailed guidance on creating and tuning alert rules, consult the ControlUp documentation at https://docs.controlup.com/alert-rules and consider exploring uptime monitoring techniques available in ControlUp's device health metrics.
Read the entire article here...
Read the entire article here...
Troubleshooting Access Denied Errors When Upgrading ControlUp Monitor Servers Using PowerShell
When upgrading a ControlUp monitor server from version 9.0.0.1680 to 9.2.0.733 using the PowerShell commandlet Invoke-CUMonitorUpdate, the process may fail with an "Access is denied" error. This failure occurs after the installation steps "Install Verify Service already installed" and "Install Copy Files" complete successfully, specifically at the step involving stopping the `cuMonitor` service. The error indicates that Windows denied access during the attempt to stop or control this service, despite running PowerShell as an administrator and having folder-level access to the monitor installation directory.
The root cause is typically related to security settings or interference by antivirus (AV) or endpoint detection and response (EDR) software, which can block the service from stopping. Alternatively, a restrictive service Access Control List (ACL) can prevent the upgrade from proceeding. When attempting to upgrade through the ControlUp Console, a similar failure occurs silently because the console relies on remote commands (via admin share or WMI) that suffer the same permissions restrictions.
To resolve this issue, manually stopping the `cuMonitor` service with elevated privileges is required. Running `sc.exe stop cuMonitor` on the monitor host as an administrator can successfully stop the service. If this command fails, it is necessary to configure AV/EDR exclusions for the ControlUp monitor executable and folder (`C:\Program Files\Smart-X\ControlUpMonitor\` and `cuMonitor.exe`) or adjust the service's ACL using `sc.exe sdshow cuMonitor` to inspect and modify permissions. Once the service is stopped, re-running the Invoke-CUMonitorUpdate commandlet completes the upgrade successfully.
When upgrading through the ControlUp Console, ensure the account used has local administrator rights on the monitor host; otherwise, upgrade via the PowerShell commandlet locally on the machine is recommended for reliability. This approach has been verified to resolve the access denied error and enable the upgrade to proceed without interruption.
For more details on managing ControlUp monitor services and upgrade procedures, refer to the official ControlUp documentation at https://docs.controlup.com or consult ControlUp support resources.
Read the entire article here...
Read the entire article here...
How to Calculate Time Saved from Automation Runs in ControlUp Dashboards Using Calculated Metrics
A user sought to create insights on time saved through automations by modifying the existing scripting and automation dashboard in ControlUp. Their goal was to add a calculated column that multiplies the number of successful script runs by a fixed value (such as 5 or 10) to estimate the total minutes saved. The user attempted to apply a mathematical transformation—specifically multiplying the "success-runs" metric by 10—via the dashboard's JSON transformation editor. However, they encountered difficulties as the table widget was built using the advanced JSON builder, which does not support switching to the basic editor mode where simple calculated columns can be added or modified directly.
ControlUp's community and support experts explained that the particular widget in question is created through the advanced JSON editor and does not support adding custom calculated columns directly on individual tables. The system currently does not allow adding a calculated column that multiplies existing columns in the advanced editor since it applies transformations to each column rather than enabling column-to-column calculations.
A recommended workaround is to use the associated "stat" widget found elsewhere on the same dashboard. This widget provides basic aggregated metrics and allows users to add simple calculations, such as multiplying the total number of successful script runs by a fixed number to calculate total time saved. By performing the multiplication in the stat widget rather than modifying the complex JSON table, users can achieve their insight goal effectively.
This limitation highlights that for advanced dashboards created via JSON editing in ControlUp, calculated columns that depend on arithmetic of existing columns must be created through simpler widgets or by recalculating the data outside the table visualization. Users aiming to customize time-saving metrics based on script run counts should consider leveraging stat widgets or other summary-level visualizations that support straightforward calculated metrics. For further guidance, ControlUp's official documentation on the dashboard widgets and calculations can provide additional instructions: https://docs.controlup.com/display/DOCS/Dashboards and https://docs.controlup.com/display/DOCS/Data+Transforms.
Read the entire article here...
Read the entire article here...
Troubleshooting Script-Based Action Visibility Delays Between ControlUp Console and Web App
When a Script-Based Action (SBA) is created in the ControlUp Real-Time Console, it typically becomes available in the ControlUp web app almost immediately. The synchronization between the console and the web app occurs through the ControlUp store configuration, which is propagated via the monitor cluster. Generally, no additional manual steps are necessary for the new script action to appear in the web app interface.
However, in scenarios where the script action does not immediately show up in the web app, several troubleshooting steps can help resolve the issue. The first recommended approach is to simply refresh the web console page to ensure the interface updates with the latest configuration changes. If the script action still does not appear, verifying user permissions is crucial, as lack of appropriate access often causes visibility problems. An explicit save of the configuration from the console using the File -> Save Configuration option may also accelerate the propagation process. As a last resort, restarting the monitor cluster can force synchronization across components.
The most common root cause for delays or failures in SBA availability in the web app is permission settings. Ensuring users have the necessary rights to access and execute the script actions is essential. This sequence of steps—refresh, check permissions, save config, restart the cluster—provides a structured approach to troubleshooting SBA visibility issues across ControlUp environments.
For further details on managing Script-Based Actions and permission configurations, refer to the official ControlUp 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...
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...
Troubleshooting PowerShell Script Execution Failures in User Context with Ivanti Application Control and ControlUp
A user encountered an issue when attempting to run PowerShell scripts on endpoint machines using ControlUp (CU) in the user context. While executing scripts in the system context was successful, running them as the user failed with an error code -1. The environment included Ivanti Application Control, a security solution similar to Windows Defender Application Control (WDAC) or AppLocker, which enforces application execution policies. The user had configured a process rule allowing SipAgent.exe to launch PowerShell.exe, which was confirmed to function correctly via Process Monitor and Process Explorer, as PowerShell.exe briefly appeared. However, the actual PowerShell script never executed, even a simple command like ‘Start-Sleep 1000’ failed to run.
Disabling the Ivanti Application Control service restored the ability to run scripts, indicating a conflict with the security controls. Interestingly, no block events were logged by Ivanti, suggesting the issue was not a straightforward deny event at the application control layer. The user inquired about which processes and system files ControlUp uses during script execution to better understand the interaction.
The root cause was identified as an Ivanti configuration rule that elevated PowerShell processes for the test user account. This elevation interfered with the ControlUp execution mechanism, preventing the script from running properly in user context. The resolution involved creating an exception within the Ivanti elevation rule: PowerShell processes launched with the ‘-file’ parameter were excluded from elevation. This adjustment allowed the scripts to run successfully while maintaining the intended elevation policy for other PowerShell instances.
This case highlights the importance of carefully managing application control and elevation policies in security products like Ivanti when deploying user-context scripts via ControlUp. Explicitly excluding ControlUp-launched PowerShell processes that run script files from elevation can prevent execution failures without compromising security. Users facing similar issues should review their application control and elevation configurations, particularly any rules that modify or elevate PowerShell, and test exclusions for script execution parameters. For more details on ControlUp’s script execution methods and related settings, users can consult the official ControlUp documentation at https://docs.controlup.com.
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...
Automating VDI Registration in ControlUp Console
Automating the addition of Virtual Desktop Infrastructure (VDI) machines to the ControlUp console upon agent installation can streamline management and monitoring processes. While ControlUp for Desktops offers a command-line installation method that automatically registers machines, a similar approach for VDIs requires specific configuration.
To achieve automated registration of VDIs, you can utilize the Install-CUAgent PowerShell cmdlet, which is part of the ControlUp Automation module. This cmdlet allows for the download and installation of the ControlUp Agent on local machines, including VDIs. By providing the necessary authentication key during installation, the agent registers the machine with your ControlUp environment. For non-domain-joined machines, an API authentication token is required. ([support.controlup.com](https://support.controlup.com/docs/install-cuagent-install-an-agent?utm_source=openai))
For non-persistent VDIs, such as those created from a master image, it's essential to configure the agent to handle these scenarios appropriately. By setting the agent as a master image, it ensures that new VDIs created from this image will automatically register with the ControlUp console, preventing duplicate entries and maintaining an accurate device inventory. ([support.controlup.com](https://support.controlup.com/v1/docs/agent-outbound-communication?utm_source=openai))
Additionally, enabling folder synchronization with your VDI infrastructure can further streamline management. This feature ensures that VDIs are correctly registered and prevents stale machines from cluttering the interface. By integrating with your VDI environment, ControlUp can automatically detect and manage VDIs, enhancing the efficiency of your monitoring and management processes. ([support.controlup.com](https://support.controlup.com/docs/connecting-to-your-vdi-infrastructure?utm_source=openai))
By implementing these methods, you can automate the addition of VDIs to the ControlUp console, ensuring accurate device registration and efficient management of your virtual desktop environment.
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...