In a recent discussion among ControlUp community members, the capability of passing output from the "Run System Command" node directly into the next step of a workflow was explored. The specific use case involved reading a device’s Organizational Unit (OU) from Active Directory (AD) and using that information to dynamically assign tags through the "Update Tags" node in a workflow. The question centered on whether the result of a command or script executed by the "Run System Command" node could be piped directly to the subsequent node for immediate processing.
The response clarified that currently, ControlUp's "Run System Command" or script execution nodes do not support the direct output transfer or piping of command results into subsequent workflow steps. This limitation means that you cannot directly feed command or script output into another node like "Update Tags" within the same workflow step sequence.
A recommended workaround involves using a data index alongside a script. The script, executed by the "Run System Command" node, can write the needed output (such as device OU information) to a ControlUp data index. The "Update Tags" node or any subsequent workflow step can then query and apply data from this index, thereby indirectly passing the information through the workflow with a slight delay compared to direct piping. Another mentioned option involves invoking a new flow via a REST API call from the script once execution completes, which offers a programmatic way to chain operations but also introduces additional complexity.
While there is no current timeline for enabling direct output passing from the "Run System Command" node, the ControlUp team acknowledged the usefulness of this feature and indicated plans to add it in the future to streamline workflows by eliminating the need for external data storage steps or additional scripts.
For further guidance on automating tags based on device attributes, workflows, and data indexing in ControlUp, users may refer to the official ControlUp documentation at https://docs.controlup.com and the ControlUp Academy at https://cuacademy.controlup.com, where detailed instructions and best practices for workflow automation and integrating Active Directory data can be found.
Read the entire article here...
ControlUp Community Training & Support Archives
All training and support-related archives from inside the ControlUp Community on Slack.
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...
Troubleshooting Missing Description Field in ServiceNow Tickets Created by ControlUp Templates Due to ACL Permissions
When using ControlUp's built-in templates for creating ServiceNow tickets, such as the Battery/Hardware Replacement Request, users may encounter an issue where the ticket is generated correctly with the appropriate short description, priority, and assignment group, but the detailed description field (result) is not populated. While the description input is visible during the creation process, the corresponding field in ServiceNow remains empty despite the ticket's successful creation.
This symptom typically indicates a permissions-related issue rather than a problem with the template or ControlUp’s integration logic. Specifically, the root cause is often related to Access Control List (ACL) settings in ServiceNow. The integration user account configured in the ControlUp-ServiceNow connection might have the necessary permission to create records but lacks write access for certain fields, such as the Description field on the Incident table. When ServiceNow receives the ticket creation request, it accepts the record creation but silently skips the fields that the user cannot update, leading to the description field being omitted without any error message.
To resolve this, verify that the user configured for the ServiceNow integration has full write permissions to all the required fields on the Incident table, including the Description field. This may involve adjusting ACL rules and permissions in ServiceNow’s user roles and security settings. Testing with an account verified to have full write access confirmed that the Description field populated correctly, indicating the problem indeed lies in ServiceNow’s ACL settings rather than ControlUp itself.
For further troubleshooting, gathering detailed logs from the ServiceNow side and submitting a support ticket along with this diagnostic information can help ControlUp support investigate more complex cases. More information on configuring and troubleshooting ServiceNow integration permissions can typically be found on official ControlUp resources and ServiceNow documentation.
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...
How to Correctly Reference Form Variables in ControlUp Workflows to Retrieve Device IDs
A user developing their first custom workflow in ControlUp encountered difficulty retrieving a specific device ID based on a machine name entered through a form trigger. The intended workflow started with an admin entering the machine "name" value from the _devices index into a form. This form submission was meant to trigger a workflow step that queries and returns only the device_id corresponding to the given machine name.
The user configured the "List Device ID" step to filter devices with the condition name = {{Start.DeviceName}}, expecting to receive one device_id as output. Instead, the query either returned a complete list of around 1200 device IDs or an empty array, failing to isolate the single target device.
The key to resolving this issue was understanding the correct variable reference syntax in ControlUp custom workflows. The user was incorrectly using {{Start.DeviceName}}, but the proper syntax for accessing form input data from the workflow trigger is {{Start.Form.DeviceName}} (or similar, using the start.form series of variables). Updating the filter condition to name = {{Start.Form.DeviceName}} enabled the workflow to correctly narrow down to the exact device and return only its device_id without extraneous results.
This highlights the importance of accurate variable referencing in ControlUp workflows, particularly when using custom form triggers to filter data. When filtering on form inputs, the recommended practice is to use the start.form variables to access form fields. For additional guidance on custom workflow variable usage, referencing ControlUp’s official workflow and automation documentation is advisable: https://docs.controlup.com/controlup-workflows.
Read the entire article here...
Read the entire article here...
Troubleshooting Missing Updated Templates in ControlUp Due to Page Caching
A community member reported an issue with the ControlUp platform where only 11 templates were visible instead of the expected, larger list of templates. The user noted they would wait to see if the issue resolved later in the day.
A ControlUp expert clarified that this situation should not occur as there were 23 new templates recently added, meaning the list should be significantly larger. The expert suggested that the most likely cause of the limited visibility was a temporary caching issue on the page displaying the templates. They advised the user to verify if the problem persisted and assured that if it did, the issue would be further investigated to determine the root cause.
Subsequently, the user confirmed that after some time, they could see all the templates as expected. This indicates that the caching issue resolved itself, restoring full access to the updated template list.
This example highlights that when newly added templates or updates do not immediately appear in the ControlUp interface, it is often due to temporary caching of the page content. Users encountering a similar discrepancy are advised to wait briefly and refresh the page to allow the cache to update. If the problem continues beyond this, contacting ControlUp support for deeper investigation is recommended.
For further details on managing templates in ControlUp or troubleshooting display issues, refer to ControlUp’s official documentation at https://docs.controlup.com.
Read the entire article here...
Read the entire article here...
Managing Unassigned Machines in Citrix Cloud Connections for MSP Environments with ControlUp
When setting up a Citrix Cloud connection in ControlUp within an MSP environment, an issue can arise where unassigned machines—those not part of any Delivery Group—are still appearing in client views even when the "Include Unassigned Machines" checkbox is unchecked. This behavior can cause security and privacy concerns, especially in a Citrix CSP (Cloud Solution Provider) model where multiple clients share the same CSP tenant but must not see each other’s resources.
The key insight is that the "Include Unassigned Machines" checkbox does not control whether unassigned machines are collected in ControlUp; rather, it controls ownership assignment. Unchecking this box only indicates that a particular connection does not own those unassigned machines. If no other connection claims ownership, ControlUp will assign all unassigned machines for that customer ID to the last available Citrix Cloud connection by default, causing them to appear in that connection’s view regardless.
Since filtering by Delivery Group names (for example, using exclusion rules like "*") does not affect unassigned machines—which by definition have no Delivery Group—this method is ineffective for hiding these machines from clients.
The recommended solution is to use a dedicated MSP-only Citrix Cloud connection for unassigned machines. This involves adding a second Citrix Cloud connection using the same Customer ID but naming it something clearly internal, such as "CSP-Unassigned." On this connection, the "Include Unassigned Machines" checkbox is checked, while on all client-facing connections it remains unchecked. By placing this MSP-only connection in a folder or with permissions that clients cannot access, unassigned machines are effectively segregated and hidden from end clients. This setup ensures clients only see Delivery Groups and connectors specific to them, while unassigned machines remain visible only to the MSP’s internal team.
In rare cases where the connector setup itself does not behave as expected—such as when unassigned machines do not show even when the "Include Unassigned Machines" box is checked—it may be necessary to contact ControlUp support for assistance.
For more details on configuring Citrix Cloud connections and collection rules, refer to ControlUp official documentation at https://docs.controlup.com and the ControlUp Academy at https://cuacademy.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...
Troubleshooting the “Something went wrong” error on the ControlUp Unified Communications Dashboard Device Count Widget
A user reported an issue on the ControlUp Unified Communications Dashboard, specifically with the "Amount of devices" metric displaying an error message stating "Something went wrong." The problem was identified within the dashboard gallery, not a customized or private dashboard.
Investigation revealed that the user's environment involved Teams integration only, without Zoom integration. Other users confirmed the feature worked correctly in their setups, suggesting the issue might be isolated or related to specific configuration parameters.
One recommended troubleshooting step was to review and reselect the data index used by the widget, as this action had previously resolved a similar issue with another widget. The suggestion included taking screenshots of the current configurable settings to restore them if necessary since reselecting an index can reset other dashboard settings. This resolution approach highlights the importance of verifying the correct data source or index selection when dashboard widgets fail to display expected information.
Although the issue was not fully resolved within the discussion, the key takeaway is ensuring the widget’s data index aligns properly with the intended source. Administrators encountering similar errors on the Unified Communications Dashboard are advised to confirm their integration settings and, if problems persist, reconfigure the widget's data index while preserving current configuration parameters.
For further guidance, see ControlUp’s official documentation on dashboard configuration and index management at https://docs.controlup.com.
Read the entire article here...
Read the entire article here...
Troubleshooting FSLogix Profile Lock Event Triggers with ControlUp’s New Windows Event Log Monitoring in DEX
A common issue arises when configuring ControlUp triggers for FSLogix profile event handling, particularly with the new Windows Event Log Monitoring feature in ControlUp Digital Employee Experience (DEX). A user setting up a trigger based on FSLogix event ID 999 (ControlUp-FSLogixProfileLocked) noticed that although the event appeared in the local Windows event log, the associated trigger action (such as running a script on profile lock) did not execute. After enabling the new Windows Event handling and creating a corresponding filter for event 999 in the ControlUp web console, the event was correctly detected, and the action was attempted but failed with the error: "Script execution failed: CUTriggerObject is not available. This script must be run from a ControlUp trigger."
The root cause relates to how the new DEX Windows Event Log Monitoring selectively forwards events based on collection rules. By default, custom events like event 999 are not included in these rules and thus remain only in the local event log, preventing real-time triggers from detecting them. When such events are collected through DEX, the script execution context differs—in particular, the `$CUTriggerObject` scripting object (which provides event details like username and machine name) is not available in scripts run through DEX event filters. This causes the script failure because it expects this object to be populated.
The solution is to add a DEX rule that explicitly collects event 999 to allow monitoring and alerting, but continue using the imported Real-Time trigger for executing the FSLogix logoff script. This trigger runs in the correct context and has access to `$CUTriggerObject`, allowing the script to function as intended. The presence of the event in the web console and receiving email notifications after adding the DEX rule demonstrate that events are collected, but only the real-time trigger can correctly handle the associated script action. Also, users should verify their scripts have the "Execute with.NET engine" option enabled to ensure proper script execution.
This issue does not stem from permissions or account misconfiguration but from the distinct operational contexts between DEX event filtering and real-time triggers. For detailed guidance, users can consult the ControlUp blog article on fixing FSLogix profile attach issues at https://www.controlup.com/blog/how-to-fix-the-fslogix-issue-the-user-profile-failed-to-attach/. Additional troubleshooting tips and best practices for script and trigger setup can be found in the ControlUp Knowledge Base and Academy resources at https://docs.controlup.com and https://cuacademy.controlup.com respectively.
Read the entire article here...
Read the entire article here...