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...
Reporting Related Training & Support Archives
Reporting 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...
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...
Resolving Permission and Custom Field Issues When Creating ServiceNow Records via ControlUp Flows
When attempting to create an event in ServiceNow via a flow, a common issue encountered is the error message stating, "You don't have permission for this action(edit_ai_agent)." Despite this message, extra fields can be added in the flow, but these custom fields do not appear in the REST message received by ServiceNow. This issue is often accompanied by the problem where fields such as short description, description, or custom fields (e.g., "company") show up empty or without values on the created record, especially when the target is a custom table extended from the task table.
The root cause of the permission error "edit_ai_agent" was identified as a bug on the integration side, which was scheduled to be fixed in an upcoming release. Importantly, this error itself does not affect the actual payload sent to ServiceNow. Rather, the missing field values within ServiceNow are typically due to two main configuration issues on the ServiceNow instance side. First, custom fields must be referenced using their internal column names, which start with the prefix "u_" (for example, "u_company") rather than their field labels. ServiceNow ignores unknown or incorrectly named fields silently without showing an error. Second, the integration user account used by the flow requires proper Access Control List (ACL) permissions: specifically, it needs create ACL rights on the custom table and write ACLs on the individual fields. Without these permissions, ServiceNow will create the record but omit values for fields lacking write permissions, resulting in empty fields.
To validate what data is actually received by ServiceNow, administrators can use the inbound REST transaction logs (found under System Logs > Transactions) to inspect incoming requests. If there are errors like "ACL Exception Insert Failed" in the flow's run history, it confirms that ACL permissions need adjustment for the integration user. Ensuring these conditions—correct internal field names with the "u_" prefix and appropriate ACL permissions—will allow custom fields to populate correctly in ServiceNow records created via the flow.
Relevant documentation for working with ServiceNow's field naming conventions and ACL settings can be found in ServiceNow's official resources, and for troubleshooting integration issues, ControlUp's knowledge base and support channels offer further guidance. The fix for the "edit_ai_agent" permission bug was targeted for the next product release following this report.
Read the entire article here...
Read the entire article here...
Understanding Real-Time Access and Limitations of the TCP Connections Table in ControlUp
The TCP Connections table found under the Network Tab in ControlUp is accessible exclusively as a real-time data source. There is no indexed or historical storage of this table's data within ControlUp's platform. This means that the TCP Connections information is gathered and displayed dynamically at the moment of the query, providing a current snapshot of network connections, but it is not archived for later analysis or retrieval.
Users seeking to analyze TCP connection trends or historical network session data over a period would need to use alternative monitoring or logging tools designed for data retention and historical reporting. ControlUp focuses on real-time performance monitoring and diagnostics, and the design decision for the TCP Connections table reflects this emphasis.
For detailed information on what network-related metrics ControlUp captures and how to leverage them in troubleshooting or performance analysis, the ControlUp documentation and knowledge base offer comprehensive guidance at https://docs.controlup.com. Additionally, exploring ControlUp Academy at https://cuacademy.controlup.com can provide training on optimizing network monitoring within the ControlUp environment.
Read the entire article here...
Read the entire article here...
Understanding macOS Crash Reporting in ControlUp 2.18 through the Windows Event Log Data Source
Starting with version 2.18, the ControlUp agent introduced a new feature that captures macOS crash reports in a manner similar to how Windows crash events are reported. Specifically, macOS crash events are logged into the `win_event_log` data source. Despite the name suggesting Windows-specific logs, the `win_event_log` was retained for these macOS crash reports to maintain compatibility with existing dashboards, reports, and other analytics tools that use this data source.
In the `win_event_log`, macOS events can be identified by the `platform` column, which uses the value 2 to represent macOS. This mechanism allows users to distinguish between Windows and macOS crash events within the same log. It's important to note that prior to version 2.18, the `platform` column was either absent or not used for such differentiation because macOS crash reporting was not implemented in this way. If the `platform` column is missing in your index, it likely means no macOS crash reports from version 2.18 or later have been collected yet.
When creating dashboards or queries to analyze these logs, you cannot filter on `os_name` with the expectation that macOS events will appear under Windows Event Log sources. Instead, you should query the `win_event_log` but use the `platform` column to separate macOS crash events from Windows ones. This approach leverages the backward compatibility of the log source naming while correctly distinguishing between operating systems in your monitoring views.
For more detailed guidance on working with macOS crash reports and the implications of their integration in the `win_event_log`, refer to ControlUp’s official documentation and the release notes for version 2.18. These resources offer comprehensive information about this feature and best practices for its usage.
Read the entire article here...
Read the entire article here...
Troubleshooting AI Query Errors for Connection Failure Metrics and Using ControlUp Dashboards as an Alternative
A user encountered difficulties querying connection failure data within a specified time range using the ControlUp AI assistant. Despite attempting a straightforward query to count connection failures during a certain period, the AI repeatedly generated errors instead of delivering the requested information. This issue highlighted limitations or temporary glitches in the AI interface for composing complex filter criteria involving time intervals.
Upon reporting the problem to the ControlUp support team, it was acknowledged as potentially related to recent network issues, which may have contributed to the AI malfunction on the previous day. The team requested formal feedback submission to investigate the problem further and verify if it could be reliably reproduced under similar conditions.
In the meantime, a practical alternative was suggested from within the community: a pre-built Citrix connection failures dashboard created by a peer user. This dashboard presents connection failure metrics in an organized and visually accessible format, allowing administrators to monitor relevant data without relying solely on raw AI-driven queries. Such dashboards provide easier insights into connection issues and can be a more reliable solution for identifying failure trends over time.
For users experiencing similar problems with AI query errors related to connection failure data, exploring the ControlUp dashboard options is recommended as an effective workaround. Additionally, reporting such AI issues to ControlUp support ensures ongoing improvement of AI capabilities for querying monitoring data. More information on creating and customizing monitoring dashboards can be found in the ControlUp Knowledge Base at https://docs.controlup.com and tutorials at the ControlUp Academy https://cuacademy.controlup.com.
Read the entire article here...
Read the entire article here...
How to Report Horizon Client Versions Across User Sessions Using ControlUp
A common requirement for managing VMware Horizon environments is the ability to report on the endpoint client versions—referred to as "HZ Client Version"—used by users to connect to the Horizon infrastructure. This need becomes particularly important in hybrid environments where users connect from both managed internal devices and unmanaged BYOD (Bring Your Own Device) endpoints. Tracking client versions helps administrators identify devices running outdated Horizon clients that require upgrades to ensure security, compatibility, and optimal performance.
Within ControlUp, the Horizon client version information can be accessed via several mechanisms. The VDI - Details view in the ControlUp console displays the HZ Client Version associated with each session, providing a straightforward way to see the current client version used. For programmatic or historical data extraction needs, ControlUp also offers a real-time data API (https://api.controlup.io/reference/gettables) which can retrieve live session details including client versions. Additionally, the "initial HZ client version" field recorded in the Session Activity report captures the client version that was used to start the session. This field, although labeled as "initial," effectively serves as a snapshot of the client version at session start.
However, because users in hybrid scenarios may connect multiple times throughout the week from different devices or update their Horizon client between sessions (for example, by disconnecting, updating, and reconnecting), it is important to consider that the client version can vary across sessions. The "initial HZ client version" is tied to each individual session start, so accumulating this information over a period allows administrators to identify all versions in use and target users on outdated clients. Pulling session activity reports over time and correlating the client versions used enables identification of BYOD devices needing updates even if the same user connects from multiple endpoints.
In summary, the "initial HZ client version" contained in ControlUp’s Session Activity reports is the key field for tracking Horizon client versions across user sessions. The ControlUp real-time data API further facilitates custom querying and automation for this reporting. For detailed exploration of session data, the VDI - Details view complements these options with an at-a-glance interface. Using these tools, administrators in hybrid environments are able to efficiently monitor and manage Horizon client versions on both managed and BYOD devices, ensuring compliance and performance consistency.
Read the entire article here...
Read the entire article here...
Troubleshooting Missing Unified Access Gateway Metrics in ControlUp Due to Horizon API Version Limitations
When configuring the connection to VMware Unified Access Gateway (UAG) in ControlUp version 9.2.5.634, a common issue arises where the UAG appears connected but does not show any metrics or visibility under the EUC Environment or the DEX Connection Servers section. Although the initial connection test succeeds, UAG metrics are missing from the interfaces, leading to confusion about what might be incorrectly configured.
One critical root cause identified is related to the Horizon REST API version supported by the UAG and Connection Servers. ControlUp relies on Horizon’s Monitor Gateways API version 5 to retrieve UAG data, but many Horizon environments running version 2412 or earlier only support versions 3 or 4 of this API. This incompatibility prevents ControlUp from properly monitoring the UAG, resulting in the absence of UAG metrics despite a seemingly successful connection configuration. This limitation is not explicitly detailed in ControlUp’s documentation, making it an easy pitfall for users in older Horizon environments.
Users who upgraded their Horizon Connection Servers to version 2603 reported that after refreshing the UAG settings in ControlUp, UAG metrics became visible and functional, confirming that full UAG monitoring support requires Horizon environments with API version 5 or newer. For those in unsupported environments, the UAG section will fail to sync correctly, although some other synchronization data like "NIC" sync may still appear. This partial failure causes issues with automatic EUC syncs, which will fail on an hourly schedule unless UAG syncs are disabled. Manual syncs from the ControlUp Console, however, still function as a workaround until an official fix or workaround is provided by support.
In light of these findings, users experiencing missing UAG metrics should verify the Horizon API version compatibility and consider upgrading their Horizon environment if UAG monitoring is required. It is also advisable to coordinate with ControlUp support to analyze logs and explore potential short-term solutions. Additional monitoring configuration details can be found in ControlUp’s official documentation on monitoring OmniSaaS and UAG here: https://support.controlup.com/docs/monitor-omnissa-unified-access-gateway. This document clarifies the expected behaviors and limitations with UAG monitoring in various Horizon versions.
Read the entire article here...
Read the entire article here...
How to Deploy ControlUp Agent via GPO in VDI Environments with MSI Silent Install and PowerShell Automation
Deploying the ControlUp Agent for VDI environments via Group Policy Object (GPO) does not have a dedicated official knowledge-base article, as the installation approach aligns with generic MSI silent installs used in other deployment methods like SCCM or PDQ. The official ControlUp documentation regarding local machine connection and agent communication is the primary reference for deployment: https://support.controlup.com/docs/connect-to-your-machines-locally and https://support.controlup.com/docs/agent-outbound-communication.
For non-persistent VDI setups that use a gold master image, the recommended method is to install the ControlUp agent MSI directly on the master image with specific MSI properties: `MASTER_IMAGE=true`, along with the `AUTHKEY` and `RegistrationKey`. This avoids the need for repeated installations on cloned machines via GPO. For persistent, domain-joined virtual machines, using a GPO Computer Startup Script to run an msiexec command is preferred over GPO Software Installation because it allows passing required MSI properties. An example command line looks like this:
`msiexec /i \\share\ControlUpAgent-xxxx.msi /qn AUTHKEY="" RegistrationKey="" MASTER_IMAGE=true`
The authentication keys are retrieved from the Real-Time Console under Settings → Agent. The Registration Key is mandatory starting from version 9.0. Machines must be manually added to the organization tree unless the agent version is 9.0.5 or higher, which supports self-registration.
When GPO deployment is not optimal, if remote RPC or WMI connectivity is available, deploying the agent remotely via the ControlUp console or Monitor is simpler. For cloud-managed endpoints, Microsoft Intune is the officially documented deployment method.
A practical example was shared demonstrating a PowerShell script to deploy the ControlUp Agent MSI for VDI within a Nerdio scripted action context. The script copies the MSI from a UNC file share to a local temporary path, validates that the MSI file is correctly copied (including a check on the MSI magic bytes), and then executes the msiexec command with silent installation flags, the authentication keys, and logging enabled. It captures and reports installation exit codes and prompts when a reboot is required. The script also includes a post-installation check to list ControlUp-related services to confirm the agent installed and started as expected.
This approach encapsulates the best practice for deploying ControlUp agents in VDI environments using GPO, balancing MSI property requirements, version-specific authentication mechanisms, and practical scripting for automation. For detailed agent deployment contexts and command-line references, the ControlUp official documentation remains the authoritative source: https://support.controlup.com/docs/connect-to-your-machines-locally and https://support.controlup.com/docs/agent-outbound-communication.
Read the entire article here...
Read the entire article here...