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...
Microsoft Related Training & Support Archives
Microsoft training and support-related archives from inside the ControlUp Community on Slack.
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...
How to Fix 400 Errors Caused by Using _id Sorting in ControlUp Edge API Queries
A PowerShell script that queries device data from the ControlUp Edge API using paginated search_after calls experienced failures starting Sunday, returning a 400 Bad Request error. The error message indicated that sorting or aggregations on the _id metadata field were no longer supported, specifically stating that "Using the _id metadata field in aggregations, sorts, scripts, or top-level field loads... is not supported because it loads fielddata into the heap." This change caused calls sorting by the internal OpenSearch/Elasticsearch document _id to fail.
The root cause was an upstream change implemented over the weekend by ControlUp. The API now blocks the use of the _id metadata field in queries to prevent severe OpenSearch JVM issues such as Out of Memory (OOM) conditions, which were observed when sorting or aggregating on large indexes by _id. This protective measure was applied after discovering more widespread usage of _id sorting than previously expected. In response to the problem and customer impact, ControlUp temporarily disabled this restriction for affected tenants, including the user’s tenant, to restore functionality while addressing the underlying stability concerns.
The resolution for the user’s scripts was to update their pagination logic to sort and search_after using a real mapped field, such as device name, instead of the internal _id metadata field. This change immediately restored proper API operation without requiring further modifications. The user’s initial script had been generated with assistance from a language model but required this adjustment due to the updated API behavior.
The discussion also raised the topic of API change notifications. ControlUp has yet to provide advance announcements or subscription-based alerts for breaking API changes, which users expressed interest in receiving. ControlUp may consider this feedback to improve communication about future updates.
For users facing similar errors, it is essential to avoid using the internal _id metadata field for sorting or pagination in ControlUp API queries. Instead, rely on indexed, mapped fields to ensure compatibility with recent security and stability improvements to the ControlUp Edge API backend built on OpenSearch.
Relevant ControlUp resources include the official documentation on the Edge API and pagination techniques, available at https://docs.controlup.com, and the ControlUp Academy at https://cuacademy.controlup.com for learning best practices with API integration.
Read the entire article here...
Read the entire article here...
Troubleshooting the “Something went wrong” error on the ControlUp Unified Communications Dashboard Device Count Widget
A user reported an issue on the ControlUp Unified Communications Dashboard, specifically with the "Amount of devices" metric displaying an error message stating "Something went wrong." The problem was identified within the dashboard gallery, not a customized or private dashboard.
Investigation revealed that the user's environment involved Teams integration only, without Zoom integration. Other users confirmed the feature worked correctly in their setups, suggesting the issue might be isolated or related to specific configuration parameters.
One recommended troubleshooting step was to review and reselect the data index used by the widget, as this action had previously resolved a similar issue with another widget. The suggestion included taking screenshots of the current configurable settings to restore them if necessary since reselecting an index can reset other dashboard settings. This resolution approach highlights the importance of verifying the correct data source or index selection when dashboard widgets fail to display expected information.
Although the issue was not fully resolved within the discussion, the key takeaway is ensuring the widget’s data index aligns properly with the intended source. Administrators encountering similar errors on the Unified Communications Dashboard are advised to confirm their integration settings and, if problems persist, reconfigure the widget's data index while preserving current configuration parameters.
For further guidance, see ControlUp’s official documentation on dashboard configuration and index management at https://docs.controlup.com.
Read the entire article here...
Read the entire article here...
How to Update Records Without Duplication and Manage Retention in Custom ControlUp Edge Data Indexes
When writing records to a custom ControlUp Edge data index via the REST API (POST to edge/api/data/), users may encounter an issue where repeated writes of the same record result in duplicate entries rather than updates to existing records. Additionally, there is a desire to prevent these records from expiring after the default 28 days of inactivity. This discussion sheds light on both the mechanics of record updating and the association of records with the endpoint running the write operation.
The key to controlling whether a record is created anew or updated lies in the uniqueness of the "key" field or primary identifier used in the data index schema. When writing data via a PowerShell script—whether executed inside ControlUp or externally—the operation will create a new record if the key value is not recognized. To update an existing record, the key must remain consistent and the write must explicitly target that key. The official ControlUp scripting guide provides useful guidance for writing data to an index, outlining how to structure the payload and use keys: https://support.controlup.com/docs/scripting-guide#writing-to-a-data-index. Running the script inside ControlUp offers the advantage of on-demand execution with local file availability, but it is not strictly necessary; scripts can also run externally.
A practical complication arises from the fact that data written to the index often becomes associated with the endpoint where the script executes, as seen when the computer name appears linked to each record. This behavior stems from ControlUp’s design, where data sources are tied to machine endpoints to facilitate monitoring and troubleshooting. In scenarios where building information needs to be stored independently of endpoint context, some organizations have implemented custom solutions such as storing building data locally on endpoints (e.g., in registry or Active Directory properties), then running scripts on each endpoint to gather and send this data to ControlUp. While this approach inherently associates data with those endpoints, it maintains up-to-date building information across the environment.
Controlling record expiration beyond the default 28 days typically requires adjusting settings on the data index or implementing regular writes to keep the record active. Without ongoing updates, ControlUp’s retention policy will remove inactive records. Users are also encouraged to explore ControlUp Workflows for automating data collection and writing processes, which can streamline operations despite a learning curve. The ControlUp support team and community forums remain valuable resources for addressing specific scripting and data index challenges.
For additional details and sample scripts, the ControlUp scripting guide is recommended: https://support.controlup.com/docs/scripting-guide#writing-to-a-data-index.
Read the entire article here...
Read the entire article here...
How to Identify and Manage Duplicate Devices in ControlUp Desktops Due to Reimaging and Agent Re-registration
A common challenge with ControlUp's Desktops product arises when IT teams test new device models by repeatedly reimaging machines, causing multiple instances of the same device to register with unique device IDs but identical hostnames. This scenario leads to an inflated license count, as each registration consumes a license until the devices are flagged inactive and subsequently removed from the system.
To identify these "duplicate" devices, one effective method involves querying the ControlUp `device_status` data index. While leveraging ControlUp Dashboards can help visualize this data, caution is advised when running queries based solely on device IDs without applying appropriate filters to avoid misleading results. Advanced options in the dashboard allow adding additional metrics that can pinpoint such duplicates by hostname or device name, which is particularly helpful since the root issue is not duplicate device IDs but duplicate device names retained after reimaging.
In practice, customizing dashboard widgets with additional filters and metrics can enable teams to monitor and isolate devices that have been repeatedly reimaged and registered, streamlining license management. For devices already deployed, it is possible to run a script that forces re-registration of devices with a new unique ID to prevent license count inflation. This step may be beneficial where device IDs need to be refreshed or reset in the ControlUp environment.
Another important factor involves deployment parameters. For example, the `REGISTERWITHNAME=1` flag, if set during agent deployment, can cause devices to register under the same name, exacerbating duplicate name issues. However, in many cases, the default setting with the `ALLUSERS=1` flag, used in ControlUp's standard installer from the Downloads pane, is sufficient and does not trigger duplicate registrations unless devices are repeatedly reimaged and reset by users.
Overall, the underlying cause of the inflated license usage is the repeated device reimaging and agent re-registration under the same hostname but with unique IDs. Proper use of the `device_status` index for querying, cautious dashboard configurations, potential scripting to reset device IDs, and awareness of deployment flags can effectively manage and mitigate "duplicate" device issues within the ControlUp Desktops product.
Read the entire article here...
Read the entire article here...
Enabling FSLogix Metrics on ControlUp Dashboards Using Real-Time Data and Upcoming API Enhancements
ControlUp users have inquired about displaying FSLogix metrics on the ControlUp Dashboard, but encountered the limitation that no predefined FSLogix metrics are currently available in the existing data scopes. This is because FSLogix real-time data is not currently included in ControlUp’s historical data sets, which underpin the dashboard's metric options and the public API. As a result, FSLogix metrics are not accessible through these channels at present.
ControlUp’s product management and development teams have confirmed that this situation is expected to change soon. There is an upcoming Real-time public API planned for release that will include FSLogix real-time data. This update will enable users to access FSLogix metrics on dashboards in real time, expanding the ability to monitor FSLogix environments directly within the ControlUp interface.
In parallel, ControlUp is also working on extending real-time data access for its AI Assistant functionality. Once implemented, this will allow users to generate dynamic visuals and analyses on FSLogix data using the AI Assistant, further enhancing real-time monitoring and troubleshooting capabilities related to FSLogix.
For now, users cannot directly add FSLogix metrics to dashboards due to the absence of these metrics in the historical data and public API. However, the forthcoming updates will bridge this gap, allowing seamless integration of FSLogix metrics into ControlUp’s real-time dashboards and AI-driven analytics. For further information on ControlUp dashboards and the evolving capabilities, users can refer to the 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...
ControlUp Community Meetup 16: From DEX to Autonomous IT: A Fireside Chat with ControlUp CEO Jed Ayres
In this ControlUp Community Meetup, host Douglas Brown sits down with Jed Ayres, CEO of ControlUp, to discuss the growing complexity of IT, the evolution of Digital Employee Experience, and how AI is changing the way technology teams identify and resolve problems.
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 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...

