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...
Microsoft Related Training & Support Archives
Microsoft training and support-related archives from inside the ControlUp Community on Slack.
How to Query Wi-Fi Adapter Driver Versions Using Custom PowerShell Scripts and Data Indexes in ControlUp
A first-time ControlUp user sought help generating a report or dashboard to query Wi-Fi adapter drivers across devices. They had PowerShell scripts producing the desired output but struggled to implement these within ControlUp. The root challenge involved correctly transforming and sending the script output to ControlUp’s custom data index for dashboard visualization.
The recommended approach required modifying the PowerShell script to wrap the output in specific markers—`### SIP DATA BEGINS ###` and `### SIP DATA ENDS ###`—and present the data as a JSON array. This enables the ControlUp agent to parse and ingest the data into a custom data index, which can then be queried in dashboards. A sample script was provided illustrating how to query Wi-Fi drivers using `Get-CimInstance` filtered by device name and manufacturer, then constructing a JSON array with device name, manufacturer, driver version, and driver date properties. This script output was wrapped in the SIP markers for ControlUp Data (CU4D) to capture the information.
Configuration instructions detailed how to add this script inside ControlUp for Desktops by navigating to Configuration > Scripts and creating a new script entry. Important options included setting the platform to Windows, language to PowerShell, enabling data sending to a specifically named custom data index (e.g., `wifi_adapter_drivers`), and choosing a trigger such as "Once Per Day" to optimize resource use since Wi-Fi driver info changes infrequently. They also noted enabling "Overwrite Existing Data" to maintain the current driver state without historical data buildup. After running the script on targeted devices, users could verify data ingestion under Configuration > Data and use or import JSON to visualize in dashboards.
During deployment, an error involving a positional parameter indicated character encoding issues with the script on some devices, despite the command working via remote shell. This highlighted the importance of script formatting and encoding handled within ControlUp’s execution environment. Further enhancements included correcting the PowerShell property name for the device name field (switching from `device_name` to `devicename`) due to how the data was read, ensuring accurate output reflecting the adapter’s actual name rather than the computer name.
A community member also shared a ready-made script and dashboard JSON import, tested on their ControlUp fleet, to streamline adoption. This example underscored ControlUp’s flexibility in integrating custom scripted data sources for tailored visibility into hardware driver versions via dashboards.
This case demonstrates how ControlUp’s scripting and custom data indexing framework can extend monitoring and reporting capabilities beyond built-in metrics, supporting complex, field-specific queries through simple PowerShell integration and well-structured JSON output. Users should ensure proper script structure with SIP markers, configure triggers and data indexes thoughtfully, and validate script encoding to avoid runtime errors. Detailed guidance is available in ControlUp’s scripting guide at https://support.controlup.com/docs/scripting-guide and broader dashboard how-to resources in their knowledge base.
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...
Resolving Device Registration Failures Using Intune Script and ControlUp’s Tracking Dashboard
A recent user shared an effective method to troubleshoot and resolve device registration failures detected via the Device Registration Failure Tracking Dashboard in ControlUp. The issue typically manifests when endpoints fail to register correctly, possibly due to mismatched or outdated registration codes that prevent successful detection and installation of necessary software components.
The solution revolves around a PowerShell script (PS1) used within an Intune Script and Remediation framework paired with a Win32 application deployment set as a required install. This script checks if the device's registration code matches the expected value—defined by modifying a single variable ($ExpectedRegCode) in the script. If the detected registration code does not match, the script initiates an uninstall command to remove existing components causing conflicts. It subsequently restarts the Intune Management Extension service to trigger a forced synchronization and installation of the latest published application version. This approach ensures that devices automatically correct registration code discrepancies by clearing stale state and obtaining the correct app package and registration anew.
This method leverages ControlUp’s Device Registration Failure Tracking Dashboard to pinpoint affected endpoints quickly, making remediation targeted and efficient. It is particularly useful in environments managed by Microsoft Intune, where automated script remediation helps maintain compliance and consistency of Win32 app deployments tied to device registration status.
Administrators planning to apply this solution should customize the $ExpectedRegCode variable within the script to reflect their environment’s correct registration string. The process assumes familiarity with Intune’s Script and Remediation capabilities and Win32 app deployment mechanics. ControlUp documentation and Microsoft’s official Intune script remediation guides provide valuable context for further customization and expansion of this workflow.
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...
How to Release Remote Control Session Guard in ControlUp During Network Issues
A common issue encountered by Support Teams when using ControlUp for remote session management is the challenge of releasing the session control guard when a user's device experiences network issues. In such scenarios, the support agent is often disconnected and attempts to reconnect to the remote session can fail or be significantly delayed, especially during active phone support sessions. This delay can hinder timely assistance and prolong user downtime.
The root cause stems from the remote control session remaining locked or guarded by the ControlUp client process, preventing immediate reconnection or takeover of the session. To resolve this, a practical workaround involves terminating the ControlUp Remote Control process associated with the session on the support agent's device. Specifically, killing the process named CU_RC.exe frees the control of the remote session, allowing the agent to reconnect without the usual delays caused by the locked session state.
This method has been verified by multiple users within the community as an effective way to release the session control guard promptly. It is recommended as a quick and straightforward action in cases where network instability disrupts remote control continuity. Teams are advised to share this approach as a standard troubleshooting step to minimize downtime during remote support sessions.
It should be noted that forcibly terminating the CU_RC process might interrupt an ongoing session and should be performed with clear communication to the end-user. Additionally, this technique is applicable in environments using current versions of the ControlUp Remote Control feature and may need adaptation if underlying product updates change process names or behaviors.
For more detailed information on managing remote control sessions in ControlUp and handling connectivity issues, users can refer to ControlUp’s official documentation and knowledge base at https://docs.controlup.com or explore training resources at https://cuacademy.controlup.com.
Read the entire article here...
Read the entire article here...
Resolving macOS Network Extension Approval Prompts During ControlUp Agent Deployment
When deploying the ControlUp macOS agent via ControlUp for Digital Experience (CU4D), users may encounter a system prompt asking for approval related to a Network Content Filter extension. This prompt is legitimate and a standard security feature of macOS. Apple requires explicit user or Mobile Device Management (MDM) approval for network extensions because they run in the background and have the capability to inspect network traffic.
The specific prompt appears due to the agent’s use of a network extension to facilitate Unified Communications and Collaboration (UC&C) live monitoring. While the agent itself continues functioning without this approval, enabling the extension is necessary to capture and provide real-time UC&C data, which is vital for comprehensive digital employee experience monitoring focused on communication tools and services.
Deployment of the ControlUp macOS agent often involves using remote control utilities like ScreenConnect, and configuration of these network extension approvals can be managed through MDM solutions such as Jamf or Microsoft Intune. By applying configuration profiles through MDM, administrators can reduce or prevent these approval prompts from appearing to end users, streamlining the deployment process and improving user experience.
For further details and step-by-step instructions on deploying the macOS agent and handling configuration profiles in MDM environments, refer to ControlUp’s official documentation at https://support.controlup.com/docs/configuration-profiles-for-mdm-deployment. This article has been validated with recent versions of Jamf and Intune, ensuring compatibility and applicability in modern macOS management setups.
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...
How to Pass Command Output Between Workflow Steps in ControlUp Using Data Index as a Workaround
In a recent discussion among ControlUp community members, the capability of passing output from the "Run System Command" node directly into the next step of a workflow was explored. The specific use case involved reading a device’s Organizational Unit (OU) from Active Directory (AD) and using that information to dynamically assign tags through the "Update Tags" node in a workflow. The question centered on whether the result of a command or script executed by the "Run System Command" node could be piped directly to the subsequent node for immediate processing.
The response clarified that currently, ControlUp's "Run System Command" or script execution nodes do not support the direct output transfer or piping of command results into subsequent workflow steps. This limitation means that you cannot directly feed command or script output into another node like "Update Tags" within the same workflow step sequence.
A recommended workaround involves using a data index alongside a script. The script, executed by the "Run System Command" node, can write the needed output (such as device OU information) to a ControlUp data index. The "Update Tags" node or any subsequent workflow step can then query and apply data from this index, thereby indirectly passing the information through the workflow with a slight delay compared to direct piping. Another mentioned option involves invoking a new flow via a REST API call from the script once execution completes, which offers a programmatic way to chain operations but also introduces additional complexity.
While there is no current timeline for enabling direct output passing from the "Run System Command" node, the ControlUp team acknowledged the usefulness of this feature and indicated plans to add it in the future to streamline workflows by eliminating the need for external data storage steps or additional scripts.
For further guidance on automating tags based on device attributes, workflows, and data indexing in ControlUp, users may refer to the official ControlUp documentation at https://docs.controlup.com and the ControlUp Academy at https://cuacademy.controlup.com, where detailed instructions and best practices for workflow automation and integrating Active Directory data can be found.
Read the entire article here...
Read the entire article here...