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 Agent Related Training & Support Archives
ControlUp Agent training and support-related archives from inside the ControlUp Community on Slack.
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...
Resolving macOS Network Extension Approval Prompts During ControlUp Agent Deployment
When deploying the ControlUp macOS agent via ControlUp for Digital Experience (CU4D), users may encounter a system prompt asking for approval related to a Network Content Filter extension. This prompt is legitimate and a standard security feature of macOS. Apple requires explicit user or Mobile Device Management (MDM) approval for network extensions because they run in the background and have the capability to inspect network traffic.
The specific prompt appears due to the agent’s use of a network extension to facilitate Unified Communications and Collaboration (UC&C) live monitoring. While the agent itself continues functioning without this approval, enabling the extension is necessary to capture and provide real-time UC&C data, which is vital for comprehensive digital employee experience monitoring focused on communication tools and services.
Deployment of the ControlUp macOS agent often involves using remote control utilities like ScreenConnect, and configuration of these network extension approvals can be managed through MDM solutions such as Jamf or Microsoft Intune. By applying configuration profiles through MDM, administrators can reduce or prevent these approval prompts from appearing to end users, streamlining the deployment process and improving user experience.
For further details and step-by-step instructions on deploying the macOS agent and handling configuration profiles in MDM environments, refer to ControlUp’s official documentation at https://support.controlup.com/docs/configuration-profiles-for-mdm-deployment. This article has been validated with recent versions of Jamf and Intune, ensuring compatibility and applicability in modern macOS management setups.
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...
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...
How to Update Device Registration Codes for Existing ControlUp Agents After Code Expiration
ControlUp has deprecated the old Device Registration Codes across all tenants, requiring a transition to new codes for agent deployment. While new agent installations using the latest Device Registration Code proceed without issues, existing devices that were registered prior to the code expiration retain the old registration code in the Windows registry. This persistence causes a problem when these devices become inactive and are removed from ControlUp. Upon attempting to re-register, the ControlUp Agent reads the outdated, expired Device Registration Code from the registry, which leads to a registration failure.
The recommended approach to resolve this for existing devices differs from the process for new installations. The latest Agent Manager deployment automatically uses the new Device Registration Code for fresh agent installs; however, it does not automatically update the registration code already stored in the registry of existing agents. Therefore, device re-registration fails if the persisted old code is expired. There is no official migration tool provided by ControlUp to update this registry value across existing installations en masse. The key registry path involved is `HKLM\SOFTWARE\Avacee\SIP` and the relevant value is `DeviceRegistrationCode`.
For an immediate workaround, ControlUp acknowledges that updating the registry manually or via script on affected devices is effective. This involves stopping the SIP Agent service, updating the `DeviceRegistrationCode` registry value to the current valid code, and restarting the service. Given that agent version auto-updates are managed separately (either by ControlUp version control or via user-managed software deployment like SCCM or Intune), it is the administrator’s responsibility to ensure deployment tools push such remediation scripts or silent Agent Manager reinstalls outfitted with the new Device Registration Code to devices at scale.
In practice, many organizations use deployment platforms such as Intune or SCCM to run remediation scripts that overwrite the expired registration code in the registry of existing agent installations, thereby preventing registration failure without full reinstallation. This approach balances efficiency and scale, allowing smooth transition without requiring large-scale agent removal and fresh installation. Administrators should plan to deploy these registry updates proactively to avoid disruptions caused by automatic agent attempts to re-register post device inactivity cleanup.
For further details on Agent Manager deployment and registry settings, consult the ControlUp documentation at https://docs.controlup.com/.
Read the entire article here...
Read the entire article here...
Managing ControlUp’s CoreAgent on macOS without a Bundle ID
ControlUp's C4Desktop for macOS utilizes the CoreAgent process to collect and transmit inventory data to the ControlUp platform. This agent is responsible for maintaining device registration, managing credentials, and facilitating communication between the device and ControlUp services. Additionally, CoreAgent oversees scheduled tasks such as periodic device reporting, license checks, and configuration updates. It also monitors and manages supporting modules that gather specific data, including CPU usage, Wi-Fi status, process information, crash reports, location data, and collaboration application activity. In the event that any of these supporting modules cease functioning, CoreAgent is designed to restart them to ensure continuous data collection. Furthermore, CoreAgent serves as the central hub for data transmission, securely uploading collected information to ControlUp and facilitating features like remote control and file browsing.
The CoreAgent binary is located at `/usr/local/com.controlup.edgedx.agent/Bin/CoreAgent` on macOS systems. It's important to note that CoreAgent is a signed binary and not an `.app` bundle, which means it does not have a `CFBundleIdentifier` and, consequently, lacks a bundle ID. This absence can present challenges when integrating with Mobile Device Management (MDM) solutions like Jamf, which typically rely on bundle IDs for application management. ControlUp does not publish a bundle ID for CoreAgent, and there is no documented `CFBundleIdentifier` for it in the Jamf or MDM documentation. Instead, for CU4Desktop on macOS, MDM profiles target other agent components by bundle ID. The main one tied to the core agent stack is:
This approach allows MDM solutions to manage and configure the necessary components of the ControlUp agent effectively, even in the absence of a bundle ID for CoreAgent itself. For detailed instructions on deploying ControlUp for Desktops with Jamf, including the creation of configuration profiles and deployment scripts, refer to the official ControlUp documentation. ([support.controlup.com](https://support.controlup.com/docs/deployment-with-jamf?utm_source=openai))
In summary, while CoreAgent is integral to the functionality of ControlUp's C4Desktop for macOS, its lack of a bundle ID requires alternative methods for management and deployment, particularly when using MDM solutions like Jamf. By targeting other agent components with known bundle IDs, organizations can effectively deploy and manage the ControlUp agent on macOS devices.
Read the entire article here...
Read the entire article here...