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...
Physical Desktops Related Training & Support Archives
Physical Desktops training and support-related archives from inside the ControlUp Community on Slack.
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 Use ControlUp Workflows to Add Devices to Groups and Tagging Devices Efficiently
A new user of ControlUp sought guidance on building workflows to manage device organization, specifically adding devices to groups and tagging them. The user was attempting to create a workflow starting with a "List Devices" step, filtering devices by an ID pattern containing "HR," followed by a "Set Group" step intended to assign those devices to an "HR" group. However, uncertainty arose over what value to enter in the "Device ID" field within the "Set Group" step.
A key insight provided by community members clarified that the "List Devices" action returns multiple device records, each representing a unique device. Consequently, the "Set Group" step cannot directly accept multiple device IDs at once in a simple field. Instead, it requires isolating each device's ID through iteration. This can be accomplished by using an array to collect the IDs and then looping through the array to apply the group assignment individually to each device. This approach ensures that each device is addressed correctly when setting group membership.
Further advice noted that an alternative and potentially more streamlined approach is to assign the group at the time of agent deployment. According to ControlUp's official documentation on agent installation and distribution (https://support.controlup.com/docs/edge-dx-agent-distribution-and-installation-for-windows#installation-methods), groups can be set during the agent installation process itself, which might simplify workflows where initial grouping is critical.
For complex or specific setup requirements, it is recommended to consult your ControlUp Customer Success Manager (CSM), who can provide tailored support based on your environment and goals. This guidance should help new users effectively automate device grouping and tagging using ControlUp workflows while leveraging best practices outlined in the official resources.
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...
Setting Up Alerts for Mac Devices in Edge DX
A user requested help setting up an alert in Edge DX to be notified when a macOS device shuts down or goes offline. They specifically asked for the exact Data Index, Field, and Condition to use. Instructions were given to navigate to Events → Alert Rules → Add Alert, set Product to Devices, and use the following settings: Method: Static Threshold, Category: Select the _devices data index, Field: last_communication, Operator: Contains, Time Window: 600 seconds (10 minutes minimum), Hits Required: 1, Retrigger Delay: 3600 seconds (1 hour). They were also reminded to add platform=2 for MacOS only.
Read the entire article here...
Read the entire article here...
Installing ControlUp Desktop Agent in VDI Setup
A discussion was had about how to install the ControlUp Desktop agent in a VDI setup without having it auto update when users log off. One solution suggested was to create a special device group for the VDI desktops and set a fixed version control rule for that group. Links to instructions and relevant downloads were also shared. It was also mentioned that using the Sip agent instead could be the best option in this scenario. No issues were reported with the web portal.
Read the entire article here...
Read the entire article here...
Partial Visibility for Windows 365 Cloud PC Via BYOD
A team member needed partial visibility from a BYOD connecting to a Windows 365 Cloud PC. The Cloud PC had Device Agent installed, but not the BYOD. The solution was to install the Remote Client plug-in on the BYOD Windows PC. More information can be found at https://support.controlup.com/docs/windows-365-edge-dx.
Read the entire article here...
Read the entire article here...
Choosing the Right ControlUp Agent for Virtualized Domain Controllers
The question was raised about which ControlUp agent to install on virtualized Domain Controllers for monitoring purposes. It was recommended to install the ControlUp VDI Agent due to its merging of agent and Hypervisor data, while the Desktops agent is not as hypervisor aware. Both agents offer different features such as remote control, alerts, script actions, and historical data length. Preferences and technical reasons are discussed.
Read the entire article here...
Read the entire article here...
Can you Monitor Linux for Instant Clones with ControlUp?
A customer had an issue with configuring ControlUp for Linux instant clones. It was determined that Linux support for VDI is not currently available. The agent can be installed directly from the command line, but currently there is no option to register by device name. ControlUp for Desktops (CU4D) is used for monitoring Linux devices, but not for master image or instant clones scenarios. The customer was informed that this is a feature question on the roadmap, but no timeline is available yet.
Read the entire article here...
Read the entire article here...
