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...
ControlUp for VDI (Real-Time DX) Training & Support Archives
ControlUp for VDI (Real-Time DX) training and support-related archives from inside the ControlUp Community on Slack.
Best Practices for Low Disk Space Alerting Using ControlUp Advanced Triggers
A common challenge in managing disk space alerts in ControlUp arises when disk space percentages hover near a critical threshold, causing redundant or false-positive alerts. One user described a scenario where they used two separate triggers: one to alert when disk space dropped below or equal to 10% for 30 minutes, and a second trigger to fire an "all clear" alert when disk space rose above 10% for 30 minutes. This setup, however, resulted in frequent false positives, especially with the "all clear" alert, due to disk space fluctuating near the 10% boundary.
The root of the problem lies in the independent nature of these two triggers and their durations. For example, if disk space dips below 10% briefly and then recovers, the separate all-clear trigger fires independently, which is often unnecessary or too noisy. The discussion clarified that ControlUp triggers do not chain, meaning one trigger cannot wait for another to fire before acting. Because of this limitation, managing disk space alerts effectively requires a different approach.
The recommended solution is to use a single Advanced Trigger that monitors logical disks rather than entire computers, applying a filter such as free space less than 10%, capacity above 10 GB (to exclude system or recovery partitions), and optionally focusing on specific volumes like the C: drive for operating system disks. This Advanced Trigger should be set with a duration of around 30 minutes, where the incident opens only after disk space has been below 10% continuously for that period. Importantly, the incident only closes automatically when disk space has been above 10% continuously for 30 minutes. This approach eliminates false positives caused by short dips or recoveries because no alert is generated unless the threshold is crossed for the full time duration, and the all-clear condition is represented by the incident resolution—no separate "all clear" trigger is necessary.
Additionally, setting a minimum time between incidents (such as 1 to 4 hours) can help prevent repetitive alerts for the same disk volume oscillating near the threshold. This strategy ensures alerts are meaningful and actionable, reducing alert noise in environments where disk space fluctuates near critical levels.
For more details on configuring Advanced Triggers and alert management in ControlUp, users can refer to the official ControlUp documentation and the ControlUp Academy: https://docs.controlup.com and https://cuacademy.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...
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 Monitor Hyper-V Hosts in ControlUp After Migrating from ESX
When transitioning from VMware ESX to a Hyper-V environment for Citrix, monitoring Hyper-V hosts through the ControlUp Management Console requires a different setup than for ESX hosts. Unlike ESX, which can be monitored directly once properly connected, Hyper-V monitoring in ControlUp necessitates deploying the ControlUp agent on each Hyper-V host. This agent installation allows ControlUp to gather detailed performance and health data from the Hyper-V hypervisors.
A common issue encountered during this transition is that ControlUp might mistakenly identify a few virtual machines as Hyper-V hosts instead of the actual hypervisor servers. This usually happens if the agents are not installed on the Hyper-V hosts themselves, or if the connection configuration is not correctly set up for Hyper-V clusters. Therefore, simply having the hypervisor hosts visible in the environment without the agent does not provide full monitoring capabilities.
To properly monitor Hyper-V clusters with ControlUp, administrators should follow the official guidance for connecting to Hyper-V hypervisors. The key step is to deploy the ControlUp agent on every Hyper-V host within the clusters. This enables comprehensive visibility into the hypervisor layer similar to what was available for ESX hosts. Detailed instructions and best practices for this process can be found in the ControlUp documentation at https://support.controlup.com/docs/connect-to-your-hypervisors#connect-a-hyperv-hypervisor.
In summary, migrating from ESX to Hyper-V environments requires deploying the ControlUp agent on Hyper-V hosts to achieve effective hypervisor monitoring. Proper identification of Hyper-V hosts and cluster setup within ControlUp hinges on this agent deployment, ensuring accurate and actionable insights for Citrix environments running on Hyper-V.
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...
How IP Restrictions Affect REST API Access and How to Configure the IP Allow List in ControlUp
When IP Restrictions are enabled in a ControlUp organization, they apply not only to user sign-in at app.controlup.com but also to REST API calls that use API keys or tokens for authentication. Initially, there was confusion about this behavior, with one party assuming that IP Restrictions only affected user sign-ins via the web application and would not restrict API calls. However, further investigation clarified that IP Restrictions do indeed apply to API requests.
The key issue encountered was that reporting workflows that fetch machine statistics via the REST API started returning "Unauthorized" errors after IP Restrictions were enabled. Although the API tokens used for authentication were verified as valid and not expired, the requests failed due to the IP restriction settings.
The resolution involves adding the public egress IP addresses of the systems making the API calls (such as those running the reporting workflows) to the organization's IP Allow List in ControlUp. This setting is accessible under Settings → Security → IP Allow List in the ControlUp management console. Once the calling system’s IP addresses are added to the allow list, API calls from those IPs will be authorized, provided a valid API token is also used.
For more detailed guidance, official ControlUp documentation and references include the API endpoint for managing IP allow lists (https://api.controlup.io/reference/orgipallowlistpubliccontroller_create) and the knowledge base article on IP Allow Lists (https://support.controlup.com/docs/ip-allow-list). These resources offer comprehensive instructions for configuring the IP Allow List to control API access securely.
Read the entire article here...
Read the entire article here...
How to Auto Log Off Idle Users in Azure Virtual Desktop Using ControlUp Triggers and Scripts
Several ControlUp community members discussed how to configure a trigger to automatically log off idle users from Azure Virtual Desktop (AVD) hosts using the ControlUp Agent for Virtual Desktop Infrastructure (VDI). One common solution is to leverage existing trigger packs within ControlUp, which include triggers designed to log off a user session after a specified period of inactivity. These triggers can be customized based on time thresholds that fit the organization’s session management policies.
An example script and detailed guidance were shared from ControlUp’s official script library, which provides automation for disconnecting or logging off idle sessions. This script can be adapted and deployed within ControlUp's automation policies to monitor session activity and log off users automatically when idle thresholds are met. The relevant resource is available at https://www.controlup.com/script-library-posts/disconnect-or-log-off-idle-sessions/.
Additional insights were shared from a ControlUp blog post that focuses on session resource optimization through automation. This post outlines best practices and practical examples of using ControlUp automation to manage session states efficiently, including auto-logout for idle sessions. The blog can be found here: https://www.controlup.com/blog/controlup-automation-session-resource-optimization/.
While native solutions like DaaS IQ might offer built-in functionality for auto-logging off idle users, many organizations have adopted ControlUp triggers as a practical workaround until formal approval or integration of native options is completed. The combination of ControlUp’s flexible triggers and scripting capabilities allows administrators to enforce session timeout policies effectively within AVD environments, optimizing resource utilization and enhancing security.
Read the entire article here...
Read the entire article here...
Troubleshooting Access Denied Errors When Upgrading ControlUp Monitor Servers Using PowerShell
When upgrading a ControlUp monitor server from version 9.0.0.1680 to 9.2.0.733 using the PowerShell commandlet Invoke-CUMonitorUpdate, the process may fail with an "Access is denied" error. This failure occurs after the installation steps "Install Verify Service already installed" and "Install Copy Files" complete successfully, specifically at the step involving stopping the `cuMonitor` service. The error indicates that Windows denied access during the attempt to stop or control this service, despite running PowerShell as an administrator and having folder-level access to the monitor installation directory.
The root cause is typically related to security settings or interference by antivirus (AV) or endpoint detection and response (EDR) software, which can block the service from stopping. Alternatively, a restrictive service Access Control List (ACL) can prevent the upgrade from proceeding. When attempting to upgrade through the ControlUp Console, a similar failure occurs silently because the console relies on remote commands (via admin share or WMI) that suffer the same permissions restrictions.
To resolve this issue, manually stopping the `cuMonitor` service with elevated privileges is required. Running `sc.exe stop cuMonitor` on the monitor host as an administrator can successfully stop the service. If this command fails, it is necessary to configure AV/EDR exclusions for the ControlUp monitor executable and folder (`C:\Program Files\Smart-X\ControlUpMonitor\` and `cuMonitor.exe`) or adjust the service's ACL using `sc.exe sdshow cuMonitor` to inspect and modify permissions. Once the service is stopped, re-running the Invoke-CUMonitorUpdate commandlet completes the upgrade successfully.
When upgrading through the ControlUp Console, ensure the account used has local administrator rights on the monitor host; otherwise, upgrade via the PowerShell commandlet locally on the machine is recommended for reliability. This approach has been verified to resolve the access denied error and enable the upgrade to proceed without interruption.
For more details on managing ControlUp monitor services and upgrade procedures, refer to the official ControlUp documentation at https://docs.controlup.com or consult ControlUp support resources.
Read the entire article here...
Read the entire article here...