Recently, some users have reported an issue where the ControlUp Agent Manager does not automatically install the SIP agent on clients when deployment is done via SCCM or Intune. Although the Agent Manager installs and communicates as expected, the clients do not proceed to download and install the SIP agent themselves. This problem was noted because affected clients were not appearing in the ControlUp console until the SIP agent was installed manually on each machine.
The troubleshooting process included verifying that the deployment codes configured in SCCM and Intune were correct, with confirmed successful manual installations of the SIP agent. Despite the automatic deployment process working previously, the behavior changed starting last Wednesday, and no known recent changes to the ControlUp agent registration process have been identified that could explain this new issue.
A key insight from the community was the importance of confirming whether the feature allowing automatic agent installation via the Agent Manager is properly configured. If it is not active or set up correctly, this would directly cause the failure of automatic SIP agent installations. In this case, however, the configuration was verified as correct, so the root cause remains unclear at this point.
Given that this issue was new and had not been encountered before, the recommended next step was to log a support case with ControlUp. This would allow their support team to review detailed logs and provide a deeper analysis. As of the last update, resolution had not been confirmed, and ControlUp support engagement is needed to identify any underlying changes or bugs affecting the automatic SIP agent deployment process in the current environment.
For more information on managing agent installation and push deployment methods, consult the ControlUp documentation on agent installation at https://docs.controlup.com/wiki/agent-installation and related deployment best practices.
Read the entire article here...
ControlUp Agent Related Training & Support Archives
ControlUp Agent training and support-related archives from inside the ControlUp Community on Slack.
Conditional Script Execution in ControlUp: Reducing Unnecessary Remediation Runs Through Compliance Custom Issues and Scheduling Improvements
A common challenge in large IT environments is running remediation scripts efficiently across thousands of devices. Typically, scripts are scheduled to run daily or on another regular interval to enforce compliance or perform necessary changes, such as modifying a registry key or folder structure. However, this approach results in many unnecessary script executions on devices that are already compliant, leading to wasted resources and longer execution times.
One proposed solution is conditional script execution based on the actual state of each endpoint—running a script only if remediation is required. For example, if a device’s registry value meets the desired state, the script should be skipped for that device. This would allow the scheduled remediation to remain active while minimizing needless runs on already compliant machines. Without this capability, administrators often build checks into the script itself to exit early if no remediation is needed, but the script still needs to run on every device each time, causing inefficiency.
ControlUp already supports a similar concept through its Compliance Custom Issues feature, which enables creation of conditions to detect compliance status and trigger remediation scripts only on devices flagged as non-compliant. This method, though effective, operates as a two-step process: one to detect the compliance issue (writing to the compliance index) and another to run the remediation via alerts triggered by the compliance state. While this approach works well for security and compliance scenarios, there is interest in applying it to broader desktop management use cases, including non-security remediation tasks.
The key limitation is that the initial detection and remediation are decoupled, requiring two processes (condition detection and remediation execution) rather than a single conditional script execution embedded within the scheduling engine. Users have suggested enhancing the ControlUp scripting and scheduling functionality to integrate conditional execution directly—essentially embedding “if this condition is true, then run this script” logic at the scheduling level. This would allow scripts to run only when truly needed without separate detection steps, providing more efficient, self-healing capabilities across desktops and endpoints.
ControlUp’s existing resources on Custom Issues, adding custom remediations, and integrating scripts for compliance illustrate the current approach:
- https://support.controlup.com/docs/custom-issues
- https://support.controlup.com/docs/adding-custom-remediations-to-built-in-issues
- https://support.controlup.com/docs/how-to-add-scripts-to-controlup-for-compliance
These documents guide users on setting up compliance checks and scripts, but the underlying model still involves separate detection and remediation phases. The ongoing community discussion highlights demand for a deeper integration of conditional execution in scheduling scripts directly, which would optimize large-scale remediation efforts by running scripts strictly on endpoints that need them without running redundant checks or remediations daily.
Read the entire article here...
Read the entire article here...
Troubleshooting ControlUp Endpoint Installation Issues: Logs, Version Control, and Deployment Guidance
When troubleshooting issues with ControlUp endpoint installations where the Agent Manager installs correctly but additional components like SIP, EdgeDX, or Remote DX do not, the primary locations for diagnostic information include the Windows Event Viewer (Application logs) and the folder at C:\ProgramData\ControlUp\Logs. However, users have reported that this logs folder might sometimes exist but be empty, making Event Viewer logs the primary source for troubleshooting.
One potential root cause identified is related to the Version Control settings in the ControlUp portal. These settings can delay or prevent the deployment of additional components beyond the Agent Manager. Verifying and adjusting the Version Control configuration is recommended to ensure it is not interfering with installation timing.
Besides configuration settings, antivirus or endpoint security solutions frequently interfere with ControlUp installations. It is important to check that all ControlUp-related folders and files are excluded from real-time scanning and quarantine, as security software blocking these files can halt installation progress without clear error messages.
Another consideration is the deployment method used for Remote DX, which differs from the Agent Manager and may require separate deployment steps or tools. This factor should be verified, especially in complex or staged deployments.
While there is an MSI installer log that could provide more detailed insights and may reside under the ControlUp program data path, its location and availability may vary based on setup. Users are advised to consult the ControlUp documentation on Version Control and agent deployment for the latest guidance. If further help is needed, providing Event Viewer logs, any available installation logs, and screenshots of Version Control settings to ControlUp support will facilitate resolution.
For more details on controlling agent versions and deployment, see the official ControlUp documentation at https://support.controlup.com/docs/agent-version-control.
Read the entire article here...
Read the entire article here...
How to Query Wi-Fi Adapter Driver Versions Using Custom PowerShell Scripts and Data Indexes in ControlUp
A first-time ControlUp user sought help generating a report or dashboard to query Wi-Fi adapter drivers across devices. They had PowerShell scripts producing the desired output but struggled to implement these within ControlUp. The root challenge involved correctly transforming and sending the script output to ControlUp’s custom data index for dashboard visualization.
The recommended approach required modifying the PowerShell script to wrap the output in specific markers—`### SIP DATA BEGINS ###` and `### SIP DATA ENDS ###`—and present the data as a JSON array. This enables the ControlUp agent to parse and ingest the data into a custom data index, which can then be queried in dashboards. A sample script was provided illustrating how to query Wi-Fi drivers using `Get-CimInstance` filtered by device name and manufacturer, then constructing a JSON array with device name, manufacturer, driver version, and driver date properties. This script output was wrapped in the SIP markers for ControlUp Data (CU4D) to capture the information.
Configuration instructions detailed how to add this script inside ControlUp for Desktops by navigating to Configuration > Scripts and creating a new script entry. Important options included setting the platform to Windows, language to PowerShell, enabling data sending to a specifically named custom data index (e.g., `wifi_adapter_drivers`), and choosing a trigger such as "Once Per Day" to optimize resource use since Wi-Fi driver info changes infrequently. They also noted enabling "Overwrite Existing Data" to maintain the current driver state without historical data buildup. After running the script on targeted devices, users could verify data ingestion under Configuration > Data and use or import JSON to visualize in dashboards.
During deployment, an error involving a positional parameter indicated character encoding issues with the script on some devices, despite the command working via remote shell. This highlighted the importance of script formatting and encoding handled within ControlUp’s execution environment. Further enhancements included correcting the PowerShell property name for the device name field (switching from `device_name` to `devicename`) due to how the data was read, ensuring accurate output reflecting the adapter’s actual name rather than the computer name.
A community member also shared a ready-made script and dashboard JSON import, tested on their ControlUp fleet, to streamline adoption. This example underscored ControlUp’s flexibility in integrating custom scripted data sources for tailored visibility into hardware driver versions via dashboards.
This case demonstrates how ControlUp’s scripting and custom data indexing framework can extend monitoring and reporting capabilities beyond built-in metrics, supporting complex, field-specific queries through simple PowerShell integration and well-structured JSON output. Users should ensure proper script structure with SIP markers, configure triggers and data indexes thoughtfully, and validate script encoding to avoid runtime errors. Detailed guidance is available in ControlUp’s scripting guide at https://support.controlup.com/docs/scripting-guide and broader dashboard how-to resources in their knowledge base.
Read the entire article here...
Read the entire article here...
Troubleshooting ControlUp Monitor Error: Disconnected from Cluster, Coordinator Not Available
A user reported a recurring error affecting nearly all their ControlUp monitors, showing the message "Disconnected from cluster, coordinator is not available." They had already followed the troubleshooting steps outlined on the official ControlUp support page regarding this error, including running TCP connectivity tests, which passed successfully. Despite these measures, the issue persisted, and rebooting the servers hosting the monitors was not an option due to operational constraints. However, restarting the ControlUp services on the affected machines was performed.
Upon further investigation, it was discovered that although one monitor appeared active, it was actually detached from the cluster and not functioning properly. This suggested a deeper connectivity or network issue affecting cluster coordination. Community experts advised opening a formal support ticket to enable more detailed diagnosis and direct assistance from ControlUp engineers. It was also noted that no widespread issues were detected in other customer environments, indicating the problem was likely specific to the user's setup.
Support engagement began with the user relaying that most monitors had their services restarted, except for the cluster master monitor which was seemingly stuck. Once the service on the cluster master was also restarted, all monitors returned to normal operation. The support engineer recommended creating a dedicated cluster master host, especially for environments with eight or more monitors, to improve stability and performance of the ControlUp monitoring cluster. Setting up cluster masters in a designated site (such as the default site) is a best practice to avoid similar coordination issues.
Finally, the user was advised to open a formal support ticket to receive tailored guidance on configuring and optimizing their monitoring architecture. They proceeded to contact ControlUp support for case creation. This case underscores the importance of monitoring service health on cluster master monitors and the value of dedicated master nodes in larger ControlUp environments. For detailed troubleshooting steps related to this error, consult ControlUp’s official support article at https://support.controlup.com/docs/monitor-error-disconnected-from-cluster-coordinator-is-not-available.
Read the entire article here...
Read the entire article here...
How to Refresh Service and Application Data On-Demand in ControlUp
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...
Read the entire article here...
Compatibility and Installation Improvements in ControlUp Mac Agent Manager 2.18 for macOS 26 and 27
ControlUp recently released an update to the Mac Agent Manager with version 2.18.4.4107, officially supporting macOS 27. This release introduces the Mac Agent version 2.18, which addresses installation issues specific to macOS 27. One notable change is the distribution format of the Mac Agent Manager installer; it has shifted from a.dmg file to a.pkg file. This update resolves a problem where the tenant information step failed to appear during manual fresh installations on macOS 27.
A common question during this update rollout was whether the new.pkg installer is compatible exclusively with macOS 27 or if it also supports earlier versions, such as macOS 26.x.x and below. The confirmation from the ControlUp team clarified that the new.pkg installer works with macOS 26 as well, ensuring backward compatibility with previous macOS versions. This means that organizations using macOS 26 or earlier can upgrade their ControlUp Mac Agent to leverage the improvements without needing to alter their operating system environment.
For users managing ControlUp deployments in mixed macOS environments, this installer update simplifies the installation process by standardizing on the.pkg format while maintaining support for multiple macOS versions. It also enhances installation reliability on macOS 27, which may have encountered issues with the previous.dmg-based installer.
For detailed instructions and additional deployment considerations, refer to the official ControlUp documentation and resources 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 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 Release Remote Control Session Guard in ControlUp During Network Issues
A common issue encountered by Support Teams when using ControlUp for remote session management is the challenge of releasing the session control guard when a user's device experiences network issues. In such scenarios, the support agent is often disconnected and attempts to reconnect to the remote session can fail or be significantly delayed, especially during active phone support sessions. This delay can hinder timely assistance and prolong user downtime.
The root cause stems from the remote control session remaining locked or guarded by the ControlUp client process, preventing immediate reconnection or takeover of the session. To resolve this, a practical workaround involves terminating the ControlUp Remote Control process associated with the session on the support agent's device. Specifically, killing the process named CU_RC.exe frees the control of the remote session, allowing the agent to reconnect without the usual delays caused by the locked session state.
This method has been verified by multiple users within the community as an effective way to release the session control guard promptly. It is recommended as a quick and straightforward action in cases where network instability disrupts remote control continuity. Teams are advised to share this approach as a standard troubleshooting step to minimize downtime during remote support sessions.
It should be noted that forcibly terminating the CU_RC process might interrupt an ongoing session and should be performed with clear communication to the end-user. Additionally, this technique is applicable in environments using current versions of the ControlUp Remote Control feature and may need adaptation if underlying product updates change process names or behaviors.
For more detailed information on managing remote control sessions in ControlUp and handling connectivity issues, users can refer to ControlUp’s official documentation and knowledge base at https://docs.controlup.com or explore training resources at https://cuacademy.controlup.com.
Read the entire article here...
Read the entire article here...
Troubleshooting FSLogix Profile Compression Event Log Collection in ControlUp Agents
A community member aimed to monitor FSLogix profile compression activity on shared desktops by creating a custom event log rule in ControlUp, cloned from an existing rule. Despite confirming the session hosts had relevant event log entries locally and that the ControlUp agent on those machines was active and sending other data, the new rule failed to pull in the FSLogix compression events.
Initial troubleshooting confirmed that all relevant ControlUp monitors and agents were updated to version 9.2.5.686. Since the setup appeared correct, the next step suggested was to open a support ticket for deeper investigation. However, another community member pointed out a similar known issue documented in a prior Slack thread, referencing an upcoming ControlUp software version (9.2.5.776) release scheduled for September 10, 2026, that reportedly addressed such event log collection problems.
Further clarification noted that while version 9.2.5.776 was available, the specific fix for this FSLogix event collection issue might not have been included in that release yet but expected in the next version update. To verify functionality, one member created a nearly identical event log collection rule targeting informational events with ID 57 (typical of FSLogix profile compression logs), derived from ControlUp's built-in FSLogix rules. This rule successfully captured multiple events from the VDI event logs, indicating the method itself was functional and suggesting that upgrading to version 9.2.5.776 might resolve the issue.
The consensus recommendation was to attempt the upgrade to version 9.2.5.776 first, as this could potentially fix the event log collection problem. Users encountering similar difficulties with FSLogix event gathering should ensure their ControlUp agents and monitors are updated to this or a later version and may benefit from revisiting built-in FSLogix templates for rule creation. For unresolved cases, opening a support ticket with ControlUp is advised to facilitate a resolution.
For further reference on creating and managing event log rules, see the ControlUp documentation at https://docs.controlup.com or ControlUp Academy at https://cuacademy.controlup.com.
Read the entire article here...
Read the entire article here...