ControlUp’s Realtime DX Console and Monitor components currently use LDAP (Lightweight Directory Access Protocol) on port 389 to communicate with Active Directory for essential functions such as reading the domain’s organizational structure, discovering computers, and retrieving user and group information. This communication method is explicitly documented in ControlUp’s support materials. While security teams often prefer LDAPS (LDAP over SSL/TLS) on port 636 to secure directory queries, ControlUp’s product does not automatically fall back from LDAP to LDAPS if port 389 is closed or blocked.
The reliance on LDAP instead of LDAPS is outlined in ControlUp’s official documentation, including the Communication Ports for VDI environments, particularly for the EU region. These documents confirm the use of LDAP on port 389 as a mandatory communication channel for the Console and Monitor to function correctly. Attempting to restrict access by only allowing LDAPS traffic on port 636 without open access on port 389 will disrupt domain querying operations and break functionality.
There is currently no straightforward option within ControlUp to switch these queries from LDAP to LDAPS. The documentation and community experts note that closing port 389 and permitting only port 636 is not supported and will result in operational issues. This limitation is important for network and firewall teams to understand when reviewing and tightening rules related to ControlUp’s network communication.
For detailed information on required ports and communication flows, ControlUp provides a dedicated documentation page at https://support.controlup.com/docs/communication-ports-used-by-controlup-hybrid-cloud-eu-customers, which includes tables and descriptions of mandatory ports for the Console and Monitor roles. Users seeking secure directory communication should be aware of this existing protocol limitation and plan network configurations accordingly to avoid disruptions.
Read the entire article here...
Virtual Desktops Related Training & Support Archives
Virtual Desktops training and support-related archives from inside the ControlUp Community on Slack.
Troubleshooting ControlUp Endpoint Installation Issues: Logs, Version Control, and Deployment Guidance
When troubleshooting issues with ControlUp endpoint installations where the Agent Manager installs correctly but additional components like SIP, EdgeDX, or Remote DX do not, the primary locations for diagnostic information include the Windows Event Viewer (Application logs) and the folder at C:\ProgramData\ControlUp\Logs. However, users have reported that this logs folder might sometimes exist but be empty, making Event Viewer logs the primary source for troubleshooting.
One potential root cause identified is related to the Version Control settings in the ControlUp portal. These settings can delay or prevent the deployment of additional components beyond the Agent Manager. Verifying and adjusting the Version Control configuration is recommended to ensure it is not interfering with installation timing.
Besides configuration settings, antivirus or endpoint security solutions frequently interfere with ControlUp installations. It is important to check that all ControlUp-related folders and files are excluded from real-time scanning and quarantine, as security software blocking these files can halt installation progress without clear error messages.
Another consideration is the deployment method used for Remote DX, which differs from the Agent Manager and may require separate deployment steps or tools. This factor should be verified, especially in complex or staged deployments.
While there is an MSI installer log that could provide more detailed insights and may reside under the ControlUp program data path, its location and availability may vary based on setup. Users are advised to consult the ControlUp documentation on Version Control and agent deployment for the latest guidance. If further help is needed, providing Event Viewer logs, any available installation logs, and screenshots of Version Control settings to ControlUp support will facilitate resolution.
For more details on controlling agent versions and deployment, see the official ControlUp documentation at https://support.controlup.com/docs/agent-version-control.
Read the entire article here...
Read the entire article here...
Understanding and Configuring the Location Field for Citrix Cloud Sessions in ControlUp
In ControlUp's Sessions view, the Location field may appear blank even when session information like Client IP is correctly populated. This is because the Location column is specifically linked to Citrix Cloud environments and represents the "resource location" of Citrix Cloud Sessions, not the client's geographic location or data coming from Remote DX. The field corresponds to the `CitrixCloudColumns.Location` attribute in the ControlUp schema, which pulls its data from Citrix Monitor OData through the ControlUp Citrix Cloud EUC connection.
For Citrix Cloud users, ensuring the Location field populates requires that resource locations be properly configured and assigned within the Citrix Cloud administrative portal. Administrators should verify that their resource locations are defined in the Citrix Cloud admin portal under Resource Locations and that these are correctly associated with their sessions and resources. Without proper resource location assignment, ControlUp cannot display this information in the Location column.
This functionality is specific to Citrix Cloud and does not apply to on-premises Citrix deployments or other remote services. It also does not derive from ControlUp Remote DX or other integrations; rather, it depends strictly on the integration between ControlUp and Citrix Cloud session data via the Citrix Monitor OData feed.
To summarize, if the Location field is blank in ControlUp for Citrix sessions, the key step is to confirm that resource locations are configured and assigned within the Citrix Cloud portal. Proper configuration ensures that ControlUp can retrieve and display the location data as intended.
Read the entire article here...
Read the entire article here...
ControlUp v9.2.5.776 REST API Bug Affects Horizon 2406 and 2412 Integration; Workaround and Fix Pending
In ControlUp version 9.2.5.776, a significant issue was identified impacting Omnissa Horizon environments running versions 2412 and 2406. This release introduced a bug affecting the REST API integration used by these Horizon versions, causing disruptions in built-in SYNC functionality and monitoring, including problems with the new Unified Access Gateway (UAG) agentless monitor. The root cause lies in the incompatibility or improper support of REST API versions 3 and 4 by this ControlUp release. Horizon environments 2503 and above, which utilize REST API version 5, were not affected and continued to function correctly.
As a temporary workaround, users in affected Horizon 2412 and 2406 environments can revert their Collectors to use the older SOAP-based method by setting a new registry entry (Use Soap = 1). This older SOAP method, while more resource-intensive and anticipated to be phased out eventually, restores functionality until the bug is fixed. ControlUp has clarified that this is a bug rather than a planned deprecation of REST API support for these Horizon versions, and a fix is actively being developed and will be released promptly.
The issue was initially not reflected in the release notes or documentation, which generally specify Horizon version requirements starting at 2406 or higher for Omnissa Horizon integration. Users should be aware that Omnissa Horizon 8.2412 remains supported until January 28, 2028, underlining the importance of maintaining compatibility. ControlUp's development team is replicating the problem using different 2412 builds to understand the issue fully, noting that the bug seems reproducible with specific builds like 8.14.0 (build 14371628935).
Caution is encouraged for organizations running Horizon 2412 or 2406 environments on this ControlUp version to avoid unanticipated monitoring data loss, as was experienced in some community reports with prolonged missing metrics. ControlUp’s documentation team is preparing to add this issue as a known bug in the current release notes to inform users more effectively until a correction is deployed. For the most accurate and updated guidance, users should consult ControlUp’s official resources at https://docs.controlup.com and seek support if needed.
Read the entire article here...
Read the entire article here...
Understanding ALERT RULES Licensing and Usage in ControlUp One EVENTS Tab
Within the ControlUp One platform, the EVENTS tab includes an ALERT RULES section that is specifically designed for ControlUp for Desktops (CU4D). Users who do not have a CU4D license will encounter a license error when accessing the ALERT RULES tab, even though other areas like OVERVIEW and EVENT DETAILS function normally. This is because the ALERT RULES feature is directly tied to CU4D licensing and capabilities.
The ALERT RULES in ControlUp One covers alerting for CU4D, ControlUp for VDI (CU4VDI), and Synthetic Monitoring; however, the creation and management of alert rules within this tab are exclusive to CU4D. For alerting related to ControlUp for VDI and Synthetic Monitoring, users must configure those alerts within their respective products. Once alerts are configured in each solution, they will be aggregated and displayed together in ControlUp One for centralized monitoring.
In summary, the ALERT RULES function in the ControlUp One EVENTS tab is dedicated to CU4D alert creation, and attempting to access this function without the proper CU4D license will trigger a license error. Alert management for CU4VDI and Synthetic Monitoring requires using those individual products’ alerting tools, after which their alerts become visible collectively within the ControlUp One interface. This division maintains clear licensing boundaries and functional segregation across ControlUp’s different monitoring products.
For more information, see ControlUp’s official documentation on alerting and licensing at https://docs.controlup.com and explore the ControlUp Academy for training on alert configuration and best practices at https://cuacademy.controlup.com.
Read the entire article here...
Read the entire article here...
Troubleshooting Script-Based Action Visibility Delays Between ControlUp Console and Web App
When a Script-Based Action (SBA) is created in the ControlUp Real-Time Console, it typically becomes available in the ControlUp web app almost immediately. The synchronization between the console and the web app occurs through the ControlUp store configuration, which is propagated via the monitor cluster. Generally, no additional manual steps are necessary for the new script action to appear in the web app interface.
However, in scenarios where the script action does not immediately show up in the web app, several troubleshooting steps can help resolve the issue. The first recommended approach is to simply refresh the web console page to ensure the interface updates with the latest configuration changes. If the script action still does not appear, verifying user permissions is crucial, as lack of appropriate access often causes visibility problems. An explicit save of the configuration from the console using the File -> Save Configuration option may also accelerate the propagation process. As a last resort, restarting the monitor cluster can force synchronization across components.
The most common root cause for delays or failures in SBA availability in the web app is permission settings. Ensuring users have the necessary rights to access and execute the script actions is essential. This sequence of steps—refresh, check permissions, save config, restart the cluster—provides a structured approach to troubleshooting SBA visibility issues across ControlUp environments.
For further details on managing Script-Based Actions and permission configurations, refer to the official ControlUp documentation at https://docs.controlup.com and explore ControlUp Academy resources at https://cuacademy.controlup.com.
Read the entire article here...
Read the entire article here...
Troubleshooting issues with RemoteDX plugin manager updates
A user asked about issues with the RemoteDX plugin manager updating, and a suggestion was made to open a support ticket. Log paths for troubleshooting were provided. The RemoteDX logs can be found at C:\ProgramData\ControlUp\Remote DX\Logs.
Read the entire article here...
Read the entire article here...
Troubleshooting Script Actions in ControlUp Realtime and Web Consoles
A user asked how long it takes for a script action to be available in the Web Console after creating it in the Realtime Console, and another user responded that it usually takes a few seconds. If the issue persists, instructions were given for a potential solution and to contact support. The process of updating and running the new version of a script on the Web Console was also discussed. The user found that the new version was not immediately populated, but refreshing the web console and using the Save Configuration feature may help in this process. Support can be contacted at support@controlup.com if necessary.
Read the entire article here...
Read the entire article here...
Troubleshooting Greyed Out AVD User Sessions in the ControlUp DEX Portal
A user asked if the fix for Real-Time DX (build 733) would solve their issue of the value being greyed out in the DEX portal for AVD user sessions. ControlUp recommended upgrading to the latest 9.2.0.733 build and opening a support ticket if the issue persists.
Read the entire article here...
Read the entire article here...
How to Pinpoint CPU-Heavy Processes Across Your VDI Fleet with ControlUp
This thread walks through a real customer question: how do you find which processes are eating the most CPU across a large VDI estate (200 servers) over a long period, so you know what to optimize?
It starts in ControlUp Dashboards. Using the VDI process data, you can build a widget showing top processes by CPU, then narrow it to the machines you care about using global filters (filter by folder, or switch to query filters with IS / IS NOT). A table beats a bar chart for a top-50 view, and any filters and time frames you set are saved in the URL, so you can bookmark or share the exact view. The built-in Gallery dashboards (notably "Big Screen Dashboard VDI") already include a processes-by-CPU widget out of the box.
The harder part is the one the customer really cared about: getting a meaningful picture across all machines rather than a single noisy spike on one box. The data is stored per process per 5-minute timeslot, not pre-aggregated per machine, so the practical approach that emerged was:
Filter to the folder containing all target machines.
Use CPU usage P95 to strip out short, expected spikes (with a fallback to average CPU, since P95 returned N/A in some environments — a possible bug worth a support ticket).
Add metrics under Advanced: computer_name (unique count) to see how many machines run the process, and process_name (count) to see how often it appeared (each record ≈ a 5-minute aggregate).
The processes worth optimizing are the ones combining high CPU + high machine count + high record count.
Worked example: a process showing ~1,080 records across 197 machines roughly translates to ~90 hours of activity over 7 days, or a few minutes per machine per day. The same method surfaced candidates like CompatTelRunner.exe, WerFault.exe, and WEM-related activity for further investigation. To go deeper, the App Trends and App Statistics reports let you drill into a specific app, and product_name data helps identify what's actually behind generic process names like setup.exe.
A few important caveats came up: averages hide spikes (10% average could be one minute at 100%), process counts are per machine, and hypervisor-level CPU (e.g., XenServer) can disagree with in-VM agent data when hosts are over-provisioned — which is also why a Sizing Recommendations report may suggest removing vCPUs even on a machine that looks maxed out.
Bottom line: use the dashboard to identify the heavy processes (folder filter + P95/avg CPU + machine count + record count), then use the App Trends report to dig into the details per app.
Read the entire article here...
Read the entire article here...