ControlUp recently updated its workflow functionality with a notice that input variables are now restricted to API-triggered flows and can be marked as "Required." Additionally, workflows will warn when a flow with input variables is changed to a different trigger type. This update unintentionally disrupted a key capability: running subflows with input variables passed from a main flow. Previously, input variables in subflows functioned similarly to parameters in PowerShell functions, enabling seamless parameter passing and modification within nested workflows.
Users reported that while subflows still received parameters correctly during execution, the workflow editor UI no longer allowed modification or addition of input variables for flows that were not API-triggered. This caused confusion and limited flexibility in workflow design, as input variables appeared hidden or locked outside of API-triggered contexts. There was also concern that input variables should remain editable and available for manual triggers and subflow usage, rather than being limited solely to API workflows.
ControlUp’s development team investigated and identified that the core runtime functionality for passing parameters to subflows had not changed; the problem lay in the editor interface. The editor was erroneously hiding and disabling input variable editing for non-API triggered flows. A fix was prioritized and promptly released. The update restored the visibility and editability of input variables for all trigger types in the workflow editor, allowing subflows to continue receiving and modifying parameters as before. The warning banners and options to remove input variables were removed to avoid user confusion. The "Required" setting remains functional exclusively for API-triggered flows, displayed as a small toggle next to each variable rather than a checkbox.
Users are advised not to use the "Remove input variables" button, as this clears the flow’s variables and may disrupt parameter passing. If variables were removed and parameter passing stopped, users can restore them in the Start node. No other action is necessary to maintain functionality. Support remains available to investigate any persisting issues.
This resolution illustrates the importance of distinguishing between UI/editor features and core workflow execution in ControlUp’s flow management. It confirms that input variable functionality across different trigger types remains intact, preserving the flexibility needed for complex orchestrations involving subflows.
ControlUp documentation on workflows and input variables can be referenced at https://support.controlup.com/v1/docs/create-workflows.
Read the entire article here...
PowerShell Related Training & Support Archives
PowerShell 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...
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...
Efficiently Combining and Processing Large Index Datasets in ControlUp Workflows Without Native Loop Constructs
A community member faced challenges building a workflow in ControlUp to combine two indexes dynamically for a nightly dashboard summarizing the previous day’s environment status. The primary difficulties arose from limitations in the workflow engine compared to PowerShell scripting, particularly related to looping constructs, array size management, and efficient data handling. Attempting to accumulate all data into a single large array caused performance degradation, and efforts to split data handling into groups of 100 records ran into issues because workflows lacked a traditional for-loop or the ability to reinitialize variables inside loops.
ControlUp experts clarified that appending to arrays in loops is generally inexpensive, but performance issues often stem from JSON modification or calculation nodes that operate on the entire array each iteration. Instead of keeping large arrays in memory, a recommended pattern is to flip the subflow logic: allow the subflow to write records directly to the target custom index and return no data to the main flow. The main flow can paginate data requests using Get Custom Data (which supports paging via from/size parameters), looping over pages where each subflow processes one page end-to-end, avoiding large in-memory arrays and reinitialization challenges.
To emulate traditional loop behavior, a “fake while loop” workaround was suggested by creating a dummy array representing the number of iterations desired (e.g., 20), then looping over that array. Combined with OpenSearch’s partitioning (`include > partitions` and `include > num_partitions`), this approach divides large datasets into manageable buckets processed in separate iterations. The configuration can be sized to match the environment—for example, capturing 4,000 records per iteration across 20 iterations to cover up to 80,000 results, adjustable as needed.
A practical example from the discussion involved combining device data from two ControlUp indexes: one filtering Windows devices by specific event logs, and the other fetching device information filtered by the extracted device IDs. Merging these on the device ID with the "Preserve structure from: both" option enabled results in a unified dataset ready for further processing or custom indexing. This workflow ran efficiently in about four seconds on test data. To control data volume, filtering steps were added to isolate devices exhibiting significant event counts (e.g., more than 5 events in 24 hours), which reduced processing load while focusing on impactful network issues.
The conversation highlighted the current lack of a native "for" loop feature in ControlUp workflows, but noted this capability is planned for future releases. Meanwhile, users can leverage paging, subflows writing directly to indexes, and OpenSearch partitions to manage large datasets effectively. Per-iteration writes to custom indexes are feasible if API rate limits and retry logic are properly handled. For large data reads, Get Custom Data is preferred over Get Data Index because of its paging capabilities. These insights provide a reliable framework for users needing to aggregate and analyze dynamic multi-index data in ControlUp workflows while balancing performance and complexity.
For additional guidance on ControlUp workflow nodes and custom data handling, refer to ControlUp’s official knowledge-base and documentation at https://docs.controlup.com and https://cuacademy.controlup.com.
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...
Automating Device Group Assignment in ControlUp Workflows Using Registry Key Data
A community member inquired about automating device group assignment in ControlUp based on a specific registry key value. The initial approach discussed involved writing a PowerShell script to read the registry key and create a custom index in ControlUp, which could then feed into a workflow for moving devices to the appropriate device group. This method also opened possibilities for using the data in dashboards, creating alerts for registry changes, and triggering remediation workflows.
A practical PowerShell script example was shared to demonstrate how to write, read, and output a registry key value under the current user (HKCU). This script was integrated with ControlUp’s Device Events by printing the output between defined event markers. Subsequently, a more detailed script was contributed, which collects registry information along with system and timestamp metadata, outputs it as a compressed JSON object, and supports error handling if the registry key access fails. This script is intended to run periodically to populate ControlUp’s data index, providing the basis for alerting and workflow triggers.
The recommended implementation steps include adding the script to the environment to gather registry data regularly, setting up alerts to trigger on specific registry values, and using ControlUp workflows with webhooks to move devices to the correct device groups based on the registry data. While alerts were initially used for this purpose, the community acknowledged the drawback of proliferation—needing many alerts for multiple groups—and expressed a preference to rely more on workflows for automation, preserving alerts for genuine issues.
To advance beyond alerts, the suggestion was made to leverage ControlUp’s API to retrieve custom data directly, enabling workflows to act on this real-time data without spawning numerous alerts. This approach supports scalable device management workflows, automating group assignments effectively. A recommendation was offered to engage ControlUp Customer Success Management (CSM) or Professional Services for further assistance with complex workflow setups integrating API data extraction. The discussion underscores the evolving use of ControlUp’s scripting, alerting, and workflow capabilities to streamline device group management based on registry key states.
For further reference, ControlUp’s official documentation on custom data scripting, workflows, and alerts can be found at https://docs.controlup.com, and detailed learning modules are available via ControlUp Academy at https://cuacademy.controlup.com.
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...
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...
Support for Boolean Fields in ControlUp Indexes via PowerShell Scripts
A community member inquired about the official support for Boolean columns in ControlUp when written to via a PowerShell script. They noted that their script was functioning as expected, showing a dropdown with options for "true" and "false" instead of a plain text box for the Boolean field. This behavior indicates that Boolean fields are recognized and handled appropriately within the ControlUp system's indexing and UI.
The confirmation came from multiple users, including a ControlUp expert, that Boolean fields are indeed supported. ControlUp's platform supports defining columns with Boolean data types, enabling users to interact with these fields through dropdown selectors for true/false values, which enhances data consistency and ease of use.
This means that scripts or automation workflows that write Boolean values into ControlUp indexes can rely on native support for true/false states. This feature is useful for scenarios where binary states need to be tracked and toggled directly from the ControlUp interface without requiring manual text input.
For more detailed information on supported data types and scripting integration with ControlUp indexes, users can refer to the official ControlUp documentation at https://docs.controlup.com, and consider the ControlUp Academy (https://cuacademy.controlup.com) for deeper learning resources on scripting and data management in ControlUp.
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...