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...
ControlUp Monitor Related Training & Support Archives
ControlUp Monitor training and support-related archives from inside the ControlUp Community on Slack.
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...
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...
Troubleshooting a Stuck ControlUp Monitor after Beta Upgrade
A user has a ControlUp monitor at a site that lost membership in the cluster during a beta upgrade. The monitor is now stuck and cannot be deleted or started. It may be stuck in a config somewhere and the user may need to contact support. Additionally, having Monitor logs from the upgrade failure can be helpful for a support case and can be sent to the Beta team.
Read the entire article here...
Read the entire article here...
Troubleshooting ControlUp Upgrade Process
An employee is troubleshooting the upgrade process for ControlUp. They are updating from version 9.0.5.423 to 9.1.5.445 and have encountered an rpc error when trying to add a monitor to a specific region. The issue is due to the console using the Windows identity of the person running the console, so the user may need to run the console as a user with permission or deploy the monitor through PowerShell. The recommended upgrade order is console, monitor, data collector agents, and all other agents. The ControlUp website has a guide for upgrading and the employee has a further question about downloading the Real-Time DX Console.
Read the entire article here...
Read the entire article here...
Understanding ControlUp Monitor Alerts and Their Frequency
A user inquired about the frequency of alerts for when the monitor stops uploading. Another user provided information on Monitor Alerts and confirmed that 3 alerts are sent for no upload activity and then stop. The org name was requested in order to check the alerts on the back-end. To learn more about Monitor Alerts, visit https://support.controlup.com/docs/monitor-alerts
Read the entire article here...
Read the entire article here...
Setting up Triggers in the ControlUp DEX Alerts Tab
A user asked for clarification on how to set up triggers in the ControlUp DEX Alerts tab. They had previously set up triggers that resulted in emails and incidents in the Incidents tab, but nothing appeared in the DEX events. Another user suggested verifying that the incidents show up in the old UI before contacting support for further assistance. The required version for the ControlUp Monitor responsible for collecting this data is 9.1.5.313 or above.
Read the entire article here...
Read the entire article here...
Understanding ControlUp Monitor Database and Query Options
There were questions about where the ControlUp monitor database is stored and what tables are available. It was suggested that the database is stored in RAM and data is only exported to the cloud backend for long enough. There were suggestions to use the powershell invoke-cuquery or api to query the database. It was also mentioned that the export-cuquery may have less impact on the monitor and export more data at a time.
Read the entire article here...
Read the entire article here...
Troubleshooting Permissions for Running Scripts on ControlUp Monitors
Some users suggested using ssh as a workaround for issues with permissions for running scripts on monitors or for more centralized management. Although it may require a "double hop" process, it can be effective. Python was also mentioned as a possible tool for opening an ssh session that opens Powershell. The advantage of ssh is that it allows for redirecting error and std_out streams. In theory, a similar approach using psexec could work but has not been successful for some users.
Read the entire article here...
Read the entire article here...
Best Practices for Redundancy in ControlUp Components for VDI Onboarding
A discussion arose about best practices for redundancy of components for new clients onboarded for VDI. It was suggested to deploy at least 2 ControlUp Monitors and dedicated Data Collectors for failover mode, with configuration instructions provided in the relevant EUC / Hypervisors API connection. ControlUp has a sizing guideline for v8.x, found at https://support.controlup.com/docs/sizing-guidelines-for-controlup-v8-x, though it is advised to monitor with ControlUp and scale as needed.
Read the entire article here...
Read the entire article here...