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...
ControlUp for Desktops Training & Support Archives
ControlUp for Desktops (Edge-DX) training and support-related archives from inside the ControlUp Community on Slack.
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...
Understanding the Absence of Window Title Data in ControlUp’s app_focus Index with End User Activity Module Enabled
In ControlUp's app_focus index, users may notice that the Window Title column does not populate any data despite the End User Activity module being enabled. This was raised by a community member whose security team was interested in accessing window title information for monitoring purposes. The inquiry sought to clarify whether this behavior is expected or if the Window Title should be displaying active window titles as part of its collected data.
Upon investigation, it appears that this behavior reflects a current limitation within the product rather than a configuration issue. The absence of window title data in the app_focus index under the End User Activity module is identified as a gap in functionality. No special settings or additional steps are needed to enable this feature presently because it is not yet supported.
ControlUp's support team acknowledged this shortfall after a preliminary check and initiated the process to address it via a support ticket, indicating the company's commitment to enhancing the module to meet user needs in the future. For now, users requiring detailed window title data for security or monitoring purposes will need to consider this limitation.
For further insights on the End User Activity module and its current capabilities, users can consult the official ControlUp documentation at https://docs.controlup.com or reach out to ControlUp support for updates on feature enhancements.
Read the entire article here...
Read the entire article here...
How to Fix 400 Errors Caused by Using _id Sorting in ControlUp Edge API Queries
A PowerShell script that queries device data from the ControlUp Edge API using paginated search_after calls experienced failures starting Sunday, returning a 400 Bad Request error. The error message indicated that sorting or aggregations on the _id metadata field were no longer supported, specifically stating that "Using the _id metadata field in aggregations, sorts, scripts, or top-level field loads... is not supported because it loads fielddata into the heap." This change caused calls sorting by the internal OpenSearch/Elasticsearch document _id to fail.
The root cause was an upstream change implemented over the weekend by ControlUp. The API now blocks the use of the _id metadata field in queries to prevent severe OpenSearch JVM issues such as Out of Memory (OOM) conditions, which were observed when sorting or aggregating on large indexes by _id. This protective measure was applied after discovering more widespread usage of _id sorting than previously expected. In response to the problem and customer impact, ControlUp temporarily disabled this restriction for affected tenants, including the user’s tenant, to restore functionality while addressing the underlying stability concerns.
The resolution for the user’s scripts was to update their pagination logic to sort and search_after using a real mapped field, such as device name, instead of the internal _id metadata field. This change immediately restored proper API operation without requiring further modifications. The user’s initial script had been generated with assistance from a language model but required this adjustment due to the updated API behavior.
The discussion also raised the topic of API change notifications. ControlUp has yet to provide advance announcements or subscription-based alerts for breaking API changes, which users expressed interest in receiving. ControlUp may consider this feedback to improve communication about future updates.
For users facing similar errors, it is essential to avoid using the internal _id metadata field for sorting or pagination in ControlUp API queries. Instead, rely on indexed, mapped fields to ensure compatibility with recent security and stability improvements to the ControlUp Edge API backend built on OpenSearch.
Relevant ControlUp resources include the official documentation on the Edge API and pagination techniques, available at https://docs.controlup.com, and the ControlUp Academy at https://cuacademy.controlup.com for learning best practices with API integration.
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...
How to Update Records Without Duplication and Manage Retention in Custom ControlUp Edge Data Indexes
When writing records to a custom ControlUp Edge data index via the REST API (POST to edge/api/data/), users may encounter an issue where repeated writes of the same record result in duplicate entries rather than updates to existing records. Additionally, there is a desire to prevent these records from expiring after the default 28 days of inactivity. This discussion sheds light on both the mechanics of record updating and the association of records with the endpoint running the write operation.
The key to controlling whether a record is created anew or updated lies in the uniqueness of the "key" field or primary identifier used in the data index schema. When writing data via a PowerShell script—whether executed inside ControlUp or externally—the operation will create a new record if the key value is not recognized. To update an existing record, the key must remain consistent and the write must explicitly target that key. The official ControlUp scripting guide provides useful guidance for writing data to an index, outlining how to structure the payload and use keys: https://support.controlup.com/docs/scripting-guide#writing-to-a-data-index. Running the script inside ControlUp offers the advantage of on-demand execution with local file availability, but it is not strictly necessary; scripts can also run externally.
A practical complication arises from the fact that data written to the index often becomes associated with the endpoint where the script executes, as seen when the computer name appears linked to each record. This behavior stems from ControlUp’s design, where data sources are tied to machine endpoints to facilitate monitoring and troubleshooting. In scenarios where building information needs to be stored independently of endpoint context, some organizations have implemented custom solutions such as storing building data locally on endpoints (e.g., in registry or Active Directory properties), then running scripts on each endpoint to gather and send this data to ControlUp. While this approach inherently associates data with those endpoints, it maintains up-to-date building information across the environment.
Controlling record expiration beyond the default 28 days typically requires adjusting settings on the data index or implementing regular writes to keep the record active. Without ongoing updates, ControlUp’s retention policy will remove inactive records. Users are also encouraged to explore ControlUp Workflows for automating data collection and writing processes, which can streamline operations despite a learning curve. The ControlUp support team and community forums remain valuable resources for addressing specific scripting and data index challenges.
For additional details and sample scripts, the ControlUp scripting guide is recommended: https://support.controlup.com/docs/scripting-guide#writing-to-a-data-index.
Read the entire article here...
Read the entire article here...
How to Identify and Manage Duplicate Devices in ControlUp Desktops Due to Reimaging and Agent Re-registration
A common challenge with ControlUp's Desktops product arises when IT teams test new device models by repeatedly reimaging machines, causing multiple instances of the same device to register with unique device IDs but identical hostnames. This scenario leads to an inflated license count, as each registration consumes a license until the devices are flagged inactive and subsequently removed from the system.
To identify these "duplicate" devices, one effective method involves querying the ControlUp `device_status` data index. While leveraging ControlUp Dashboards can help visualize this data, caution is advised when running queries based solely on device IDs without applying appropriate filters to avoid misleading results. Advanced options in the dashboard allow adding additional metrics that can pinpoint such duplicates by hostname or device name, which is particularly helpful since the root issue is not duplicate device IDs but duplicate device names retained after reimaging.
In practice, customizing dashboard widgets with additional filters and metrics can enable teams to monitor and isolate devices that have been repeatedly reimaged and registered, streamlining license management. For devices already deployed, it is possible to run a script that forces re-registration of devices with a new unique ID to prevent license count inflation. This step may be beneficial where device IDs need to be refreshed or reset in the ControlUp environment.
Another important factor involves deployment parameters. For example, the `REGISTERWITHNAME=1` flag, if set during agent deployment, can cause devices to register under the same name, exacerbating duplicate name issues. However, in many cases, the default setting with the `ALLUSERS=1` flag, used in ControlUp's standard installer from the Downloads pane, is sufficient and does not trigger duplicate registrations unless devices are repeatedly reimaged and reset by users.
Overall, the underlying cause of the inflated license usage is the repeated device reimaging and agent re-registration under the same hostname but with unique IDs. Proper use of the `device_status` index for querying, cautious dashboard configurations, potential scripting to reset device IDs, and awareness of deployment flags can effectively manage and mitigate "duplicate" device issues within the ControlUp Desktops product.
Read the entire article here...
Read the entire article here...
How to Configure AND vs OR Logic with Device Tags in ControlUp Alerts
When configuring alerts in ControlUp based on device tags, a frequent question arises regarding whether selecting multiple device tags in the alert conditions operates as an OR or AND logic. It was clarified that in the current ControlUp alert configuration interface, when multiple device tags are selected, the alert triggers if the device has any one of the specified tags. This means the condition acts as a logical OR between the tags rather than an AND.
The user interface presents these tag selections as checkboxes, limiting the direct ability to express compound AND logic (such as requiring both tags to be present simultaneously). There is no built-in switch or toggle to explicitly select AND versus OR behavior for device tag conditions. While the idea of combining tags using expressions like "tag1&&tag2" was discussed, this is not supported directly within the tag selection box, and typing such expressions does not function as a filter in the UI.
However, a workaround approach involves leveraging multiple alert conditions, which are inherently ANDed together by ControlUp. For instance, instead of trying to combine two tags in one condition, you can create two separate conditions that must both be true, effectively achieving an AND between device tag criteria. Since tags are treated as string fields in the system, operators such as "contains" or "=" can be used in these conditions. Using "contains" is useful but may lead to partial matches, which requires careful tag naming conventions to avoid unintended matches (e.g., "reboot_device" matching both "reboot_device" and "no_reboot_device").
To address this, users have adapted by modifying their tagging strategies to use more distinctive and unambiguous tag names like "device_reboot_yes" and "device_reboot_no," which helps ensure that the use of "contains" or equality checks does not overlap between conflicting tags. Some users also explored adding exclusion conditions (e.g., conditions that exclude devices with certain tags), but these might not cover all scenarios adequately.
The community suggested it would be valuable for ControlUp to enhance alert configuration with explicit AND/OR toggles or support for string operations like "starts with" to improve flexibility for tag-based alerting. Meanwhile, using multiple conditions combined with clear tag naming conventions is the recommended practical approach for achieving AND logic with device tags in alerts.
For more detailed information on alert condition configuration and tag-based filtering, refer to the official ControlUp documentation at https://docs.controlup.com. This includes guidance on condition operators, tag management, and best practices for alert configurations.
Read the entire article here...
Read the entire article here...