ControlUp users focusing on digital employee experience (DEX) and user experience monitoring have found several features and best practices especially valuable for measuring adoption, engagement, and satisfaction across their environments. Key recommendations center around combining telemetry data with direct user feedback such as surveys to obtain richer insights. Surveys are most effective when paired with quantitative telemetry metrics, as this correlation reveals gaps and areas for improvement that neither approach alone can fully expose.
A primary metric endorsed by the community is the DEX Score, which aggregates user experience data into a single score per user, and can be rolled up by department, location, or persona. Trending DEX Scores over time provides a clear adoption and satisfaction narrative. In addition, monitoring logon duration per group is critical because delays here are a common source of user frustration and complaints.
For user experience visibility, the Employee View dashboard enables IT teams to quickly identify issues impacting end users. Other frequently cited dashboards include those focusing on Windows application crashes, app stability and performance, AI-driven apps and sites usage, and Teams/Unified Communications call quality—particularly important for organizations heavily reliant on Microsoft Teams. Anomaly detection using AI (Pulse AI) is recommended over static threshold alerts, as it can find unusual patterns proactively and even suggest or enact fixes via workflows.
Custom dashboards should be tailored to different stakeholders—executive views showing aggregated DEX by business units, operational views tracking logon times and resource usage, and user experience views combining app performance and user sentiment. In addition, creative use of automation workflows can significantly enhance support responsiveness. For example, a self-healing workflow can collect diagnostic data on machine issues, generate AI-driven recommendations, automatically open service tickets (e.g., in ServiceNow), and notify users with remedial steps before they contact helpdesk.
Integrations such as with ServiceNow enable automated ticket creation and remediation workflows that improve IT support efficiency and end-user communication. ControlUp roles can be customized to give access across teams (security, network, telephony) beyond just helpdesk functions, helping different groups leverage relevant telemetry.
New users of ControlUp are advised to start with free courses available at ControlUp Academy, followed by hands-on evaluation of dashboards in the Dashboard Gallery to understand available data and refine dashboards per organizational needs. Building out use cases and dashboards incrementally—starting with a few key metrics and expanding gradually—helps organizations avoid measurement overload and focus on actionable insights.
Finally, community insights emphasize ongoing management of user personas underpinning DEX Score segmentation, with approaches varying from manual updates to bulk imports depending on organizational scale.
Overall, a combined strategy using ControlUp’s telemetry, custom dashboards, integrations, AI-powered anomaly detection, and employee survey data provides a powerful framework for measuring and improving employee experience in IT environments.
Relevant resources include:
ControlUp Academy: https://cuacademy.controlup.com
ControlUp official documentation: https://docs.controlup.com
ControlUp Community: https://community.controlup.com
Dashboard Gallery (within ControlUp platform)
Read the entire article here...
VDI Related Training & Support Archives
VDI training and support-related archives from inside the ControlUp Community on Slack.
Why ControlUp Uses LDAP (Port 389) Instead of LDAPS for Active Directory Queries and Firewall Configuration Guidance
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...
Read the entire article here...
Automating Quarterly VDI “Unique Users” Reports with ControlUp Workflows and Custom SQL Queries
A common request in VDI environments is automating the generation and distribution of quarterly reports that include metrics such as "Unique Users" along with detailed user session data. One such use case involves producing an Excel (CSV/XLSX) report that captures the list of users who logged into the VDI environment during the previous quarter and sending it automatically to management via email.
ControlUp does not offer a direct, out-of-the-box report that automates this exact task with both unique user counts and full session data in one export, nor does it natively support emailing such reports on a quarterly schedule through the product UI alone. However, this requirement can be addressed using ControlUp’s extensibility and automation features, particularly by leveraging ControlUp Workflows and custom SQL queries within the ControlUp Insights platform.
One practical implementation involves creating a custom SQL query that extracts user session activity data—such as usernames and counts of sessions per user over the desired interval. This query can be run on a schedule aligned to quarters. The results are then exported into Excel format using the Microsoft Excel integration available within ControlUp Workflows. An automated workflow can then use the Microsoft Outlook integration to send the generated report via email to predefined recipients at the beginning of each quarter, with the data covering the previous quarter.
A useful example comes from a community user who adapted the "Device Inventory Report to Email" workflow template for their use case. They included a custom SQL query to capture user session activity over the last set number of days, generating a report of users and their session counts. This workflow creates a document (Excel file) and attaches it in an email sent automatically to recipients whose addresses are stored in a global variable, enabling easy customization of distribution lists. This approach requires the integrations of ControlUp for VDI, Microsoft Excel, and Microsoft Outlook to function smoothly.
While this method does not currently exist as a pre-built ControlUp dashboard or report that directly sends emails on a quarterly schedule, using the powerful combination of custom SQL queries, Workflows automation, and Office integration provides a viable and robust solution. For organizations that cannot utilize AI assistance due to policy restrictions, this approach offers a fully scriptable, controlled, and customizable method to achieve the quarterly "Unique Users" report and distribution goal without manual intervention.
ControlUp customers interested in implementing such solutions can explore the ControlUp Workflows feature, the SQL Query Editor in ControlUp Insights, and the email and Excel integrations detailed in the ControlUp documentation and the ControlUp Academy tutorials at https://academy.controlup.com. Additionally, the official workflow templates available in the ControlUp Console or downloadable from the ControlUp community can form a good starting point for customization.
Read the entire article here...
Read the entire article here...
How to Apply and Save Filters on ControlUp Dashboards and Widget Pages
ControlUp users seeking to filter dashboard results by specific criteria such as operating system or Delivery Group encounter a limitation in the product’s current functionality: while filters can be applied within a dashboard, these filter settings are not saved as part of the dashboard’s configuration. Instead, filters and time frame selections are temporarily stored within the URL. This means that users can preserve a filtered view by bookmarking or sharing the URL, but these preferences are not inherently saved or persist when navigating through the web user interface (UI) dynamically from one dashboard to another.
ControlUp has acknowledged this limitation and confirmed that a more user-friendly graphical interface (GUI) for saving dashboard views—including filters and time selections—is under development, with an anticipated release in the fourth quarter. Until this feature is available, the only practical method to save a filtered view involves using the URL, which has drawbacks in user navigation experience, especially for environments where multiple users need to explore dashboards dynamically and consistently see predefined filtered content.
A similar issue arises with VDI widget pages, which are distinct from dashboards but also involve filtering by Delivery Group. Filtering individual widgets to focus on specific Delivery Groups currently does not allow saving these filter states or drills down into more detailed views for specific groups. The “Focus on” feature can selectively highlight certain items via the UI’s left-hand column, yet these views cannot be saved or preconfigured to tailor environments for end users.
The ability to create and save predefined, filtered screens tailored to different audiences remains a highly requested feature for creating controlled, user-friendly environments. Users and administrators want to build customized views that persist across sessions and are easy to navigate, but currently must rely on URL-based workarounds. Until the upcoming GUI enhancements are released, best practice includes creating bookmarks with specific filter parameters encoded in URLs and educating users on navigating with these bookmarks for a more consistent experience.
For official updates on saving dashboard views and filters in ControlUp, monitoring release notes and the Knowledge Base at https://docs.controlup.com is recommended. Further learning resources are available through ControlUp Academy at https://cuacademy.controlup.com.
Read the entire article here...
Read the entire article here...
Managing FSLogix Profile Size: Best Practices with ControlUp Monitoring and Profile Cleanup Automation
A community member transitioning from eG Enterprise to ControlUp in a virtual desktop infrastructure (VDI) or remote desktop services (RDS) environment inquired about managing FSLogix profile size through logon or logoff scripts executed by ControlUp. The goal was to reduce profile bloat by deleting specific files within user profiles during session start or end. It was clarified that ControlUp does not support traditional logon or logoff scripts in the classical sense, although it can trigger scripts on events such as "User logged On." This functionality, however, is not ideally suited for the described profile cleanup use case.
Regarding FSLogix profile management, the conversation highlighted that VHD disk compaction is enabled by default in recent FSLogix releases, which automatically helps reduce profile size. However, disk compaction alone may not be sufficient. A practical approach mentioned involved setting up ControlUp alerts to monitor profile conditions—such as low disk space—triggering notifications through ServiceNow tickets for manual intervention by the VDI team. Although automation was still a work in progress, this method added a layer of proactive management.
Another critical recommendation was the use of the FSLogix redirections.xml configuration file. This file allows administrators to exclude certain paths or folders within the user profile—such as temporary files or application cache—from being saved. By strategically excluding these locations, profile bloat can be effectively reduced before it accumulates. The official Microsoft documentation on VHD Disk Compaction (https://learn.microsoft.com/en-us/fslogix/concepts-vhd-disk-compaction) and the redirections.xml configuration (https://learn.microsoft.com/en-us/fslogix/concepts-redirections-xml) provide authoritative guidance on these techniques.
For scripted profile cleanup during user logoff, the community recommended leveraging traditional Group Policy Object (GPO) or Citrix Workspace Environment Management (WEM) tools. One valuable resource shared was Aaron Parker’s Profile Cleanup script (https://stealthpuppy.com/fslogix/profilecleanup/), which is widely used for automating the removal of unwanted files in FSLogix profiles.
In summary, while ControlUp offers monitoring and alerting capabilities that can assist in managing FSLogix profile size, tasks like cleaning profile contents on logon or logoff are better handled by existing scripting mechanisms triggered outside of ControlUp, such as GPO or WEM. Employing FSLogix’s built-in disk compaction and profile exclusion features forms the foundation of efficient profile size management complemented by monitoring workflows for remediation alerts.
Read the entire article here...
Read the entire article here...
Troubleshooting FSLogix Profile Compression Event Log Collection in ControlUp Agents
A community member aimed to monitor FSLogix profile compression activity on shared desktops by creating a custom event log rule in ControlUp, cloned from an existing rule. Despite confirming the session hosts had relevant event log entries locally and that the ControlUp agent on those machines was active and sending other data, the new rule failed to pull in the FSLogix compression events.
Initial troubleshooting confirmed that all relevant ControlUp monitors and agents were updated to version 9.2.5.686. Since the setup appeared correct, the next step suggested was to open a support ticket for deeper investigation. However, another community member pointed out a similar known issue documented in a prior Slack thread, referencing an upcoming ControlUp software version (9.2.5.776) release scheduled for September 10, 2026, that reportedly addressed such event log collection problems.
Further clarification noted that while version 9.2.5.776 was available, the specific fix for this FSLogix event collection issue might not have been included in that release yet but expected in the next version update. To verify functionality, one member created a nearly identical event log collection rule targeting informational events with ID 57 (typical of FSLogix profile compression logs), derived from ControlUp's built-in FSLogix rules. This rule successfully captured multiple events from the VDI event logs, indicating the method itself was functional and suggesting that upgrading to version 9.2.5.776 might resolve the issue.
The consensus recommendation was to attempt the upgrade to version 9.2.5.776 first, as this could potentially fix the event log collection problem. Users encountering similar difficulties with FSLogix event gathering should ensure their ControlUp agents and monitors are updated to this or a later version and may benefit from revisiting built-in FSLogix templates for rule creation. For unresolved cases, opening a support ticket with ControlUp is advised to facilitate a resolution.
For further reference on creating and managing event log rules, see the ControlUp documentation at https://docs.controlup.com or ControlUp Academy at https://cuacademy.controlup.com.
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...
How to Identify Java Process Executable Paths on VDIs Using ControlUp Real-Time Data and Recurring Exports
A common challenge among IT teams managing virtual desktop infrastructure (VDI) environments is identifying the exact executable paths of Java processes running on their VDI machines. In a recent inquiry, a ControlUp user sought to locate Java processes and determine the full execution path of these processes on their VDIs using ControlUp dashboards. Although they were able to create a dashboard widget that revealed the folder structure, they found no direct way to report the full executable path for historical data within ControlUp.
The root cause identified is that ControlUp does not retain the full executable path information as part of its historical data records. Instead, this level of process detail—specifically the executable path—is only available in live, real-time data monitoring. For those needing to track Java process paths over time, this limitation means historical analysis of full executable paths is not natively supported by ControlUp’s historical data collection.
Several users acknowledged that having the executable path data visible and reportable in a historical context would be highly valuable, especially for use cases such as identifying outdated Java runtime versions and understanding diverse Java process usage patterns across an organization’s VDI environment. While real-time data is sufficient for immediate troubleshooting, historical visibility would enhance trend analysis and proactive software management.
As a practical workaround, it was suggested to leverage ControlUp’s live monitoring capabilities combined with recurring data exports using the ControlUp PowerShell module command `Export-CuQuery`. By regularly exporting live process data—including executable paths—over time, teams can build their own longitudinal datasets outside of ControlUp. This approach allows filtering and analysis of Java process paths beyond what the platform currently stores in its historical database.
Regarding the broader context of Java monitoring integration into ControlUp for Azure Virtual Desktop (CU4A), current support remains focused on real-time visibility, with no confirmed release date for extending these capabilities to historical data or enhanced Java-specific monitoring features. Users are encouraged to stay updated through official ControlUp resources.
For further details on ControlUp capabilities, data export options, and dashboard customization, users may consult the ControlUp Knowledge Base at https://docs.controlup.com and the ControlUp Academy at https://cuacademy.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...
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...