ControlUp users focusing on digital employee experience (DEX) and user experience monitoring have found several features and best practices especially valuable for measuring adoption, engagement, and satisfaction across their environments. Key recommendations center around combining telemetry data with direct user feedback such as surveys to obtain richer insights. Surveys are most effective when paired with quantitative telemetry metrics, as this correlation reveals gaps and areas for improvement that neither approach alone can fully expose.
A primary metric endorsed by the community is the DEX Score, which aggregates user experience data into a single score per user, and can be rolled up by department, location, or persona. Trending DEX Scores over time provides a clear adoption and satisfaction narrative. In addition, monitoring logon duration per group is critical because delays here are a common source of user frustration and complaints.
For user experience visibility, the Employee View dashboard enables IT teams to quickly identify issues impacting end users. Other frequently cited dashboards include those focusing on Windows application crashes, app stability and performance, AI-driven apps and sites usage, and Teams/Unified Communications call quality—particularly important for organizations heavily reliant on Microsoft Teams. Anomaly detection using AI (Pulse AI) is recommended over static threshold alerts, as it can find unusual patterns proactively and even suggest or enact fixes via workflows.
Custom dashboards should be tailored to different stakeholders—executive views showing aggregated DEX by business units, operational views tracking logon times and resource usage, and user experience views combining app performance and user sentiment. In addition, creative use of automation workflows can significantly enhance support responsiveness. For example, a self-healing workflow can collect diagnostic data on machine issues, generate AI-driven recommendations, automatically open service tickets (e.g., in ServiceNow), and notify users with remedial steps before they contact helpdesk.
Integrations such as with ServiceNow enable automated ticket creation and remediation workflows that improve IT support efficiency and end-user communication. ControlUp roles can be customized to give access across teams (security, network, telephony) beyond just helpdesk functions, helping different groups leverage relevant telemetry.
New users of ControlUp are advised to start with free courses available at ControlUp Academy, followed by hands-on evaluation of dashboards in the Dashboard Gallery to understand available data and refine dashboards per organizational needs. Building out use cases and dashboards incrementally—starting with a few key metrics and expanding gradually—helps organizations avoid measurement overload and focus on actionable insights.
Finally, community insights emphasize ongoing management of user personas underpinning DEX Score segmentation, with approaches varying from manual updates to bulk imports depending on organizational scale.
Overall, a combined strategy using ControlUp’s telemetry, custom dashboards, integrations, AI-powered anomaly detection, and employee survey data provides a powerful framework for measuring and improving employee experience in IT environments.
Relevant resources include:
ControlUp Academy: https://cuacademy.controlup.com
ControlUp official documentation: https://docs.controlup.com
ControlUp Community: https://community.controlup.com
Dashboard Gallery (within ControlUp platform)
Read the entire article here...
Microsoft Windows Related Training & Support Archives
Microsoft Windows training and support-related archives from inside the ControlUp Community on Slack.
Troubleshooting ControlUp Endpoint Installation Issues: Logs, Version Control, and Deployment Guidance
When troubleshooting issues with ControlUp endpoint installations where the Agent Manager installs correctly but additional components like SIP, EdgeDX, or Remote DX do not, the primary locations for diagnostic information include the Windows Event Viewer (Application logs) and the folder at C:\ProgramData\ControlUp\Logs. However, users have reported that this logs folder might sometimes exist but be empty, making Event Viewer logs the primary source for troubleshooting.
One potential root cause identified is related to the Version Control settings in the ControlUp portal. These settings can delay or prevent the deployment of additional components beyond the Agent Manager. Verifying and adjusting the Version Control configuration is recommended to ensure it is not interfering with installation timing.
Besides configuration settings, antivirus or endpoint security solutions frequently interfere with ControlUp installations. It is important to check that all ControlUp-related folders and files are excluded from real-time scanning and quarantine, as security software blocking these files can halt installation progress without clear error messages.
Another consideration is the deployment method used for Remote DX, which differs from the Agent Manager and may require separate deployment steps or tools. This factor should be verified, especially in complex or staged deployments.
While there is an MSI installer log that could provide more detailed insights and may reside under the ControlUp program data path, its location and availability may vary based on setup. Users are advised to consult the ControlUp documentation on Version Control and agent deployment for the latest guidance. If further help is needed, providing Event Viewer logs, any available installation logs, and screenshots of Version Control settings to ControlUp support will facilitate resolution.
For more details on controlling agent versions and deployment, see the official ControlUp documentation at https://support.controlup.com/docs/agent-version-control.
Read the entire article here...
Read the entire article here...
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...
Troubleshooting Missing Usernames and Metric Data in ControlUp Process Monitoring Dashboards and Stat Widget Limitations
A common issue encountered with ControlUp dashboards involves inaccurate reporting of process start times and user counts, specifically with high numbers of users and processes that initiate immediately after login. In a troubleshooting case, a community member observed that the Netskope client was not routing traffic to on-premises file shares for 5 to 10 minutes post-login. They wished to confirm through a dashboard or report that the service in question (stAgent process) started almost immediately after user login. However, the dashboard filtered to this process was showing many "N/A" values for relevant metrics, and the total user count was about 900 fewer than expected.
The core technical challenge was identified as a data collection nuance related to where process data originates and the timing of process starts relative to the SIP (Session Initiation Protocol) agent. It was clarified that the metrics came from "process stops" indices. Users noted that usernames were sometimes missing from these entries because the process starts before the SIP agent logged the user identity, leading to incomplete user data capture. Additionally, the "app_launch_time_ms" metric was missing for some process start events, likely due to this timing discrepancy. Differences were highlighted between two different data sources, "process_stops" (Windows-focused) and "builtin_process_stop" (Mac-focused), explaining variations in available metric details.
Another topic discussed was the limitation encountered when interacting with Stat widgets in ControlUp dashboards. When clicking on a stat card representing many devices (e.g., 2000 unique device IDs), the drill-down view only displayed up to 500 devices, causing confusion and incomplete visibility. This limitation was acknowledged as potentially unintentional and slated for further investigation. The community debated the practical need for disabling this drill-down feature in some dashboards, with consensus that although direct action on large device sets might be unusual, users still expect full visibility matching the dashboard summary counts.
From a solution perspective, filtering widgets by exact username with a negation filter was suggested to show only entries with recorded usernames, assisting in troubleshooting user data completeness. The issue with incomplete metric values related to early-starting processes remains a technical limitation tied to data collection timing, without an immediate fix but with suggested workarounds for filtering and interpreting available data.
In summary, to troubleshoot processes that start immediately after login but show incomplete metrics or user data in ControlUp dashboards:
- Understand the difference between the Windows "process_stops" and Mac "builtin_process_stop" indices and their data characteristics.
- Recognize that processes starting before the SIP agent registers the user can result in missing usernames and launch time metrics.
- Use filtering techniques to isolate entries with valid usernames.
- Be aware of drill-down limits on Stat widgets (currently capped at displaying 500 devices), which affects visibility on large datasets.
- Monitor ControlUp updates for potential removal or adjustment of drill-down limits.
For more details on dashboards, filtering, and process monitoring in ControlUp, refer to the official documentation at https://docs.controlup.com, and for dashboard customization best practices, visit https://cuacademy.controlup.com.
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...
Troubleshooting Missing macOS Script Details in ControlUp Event Logs and Resolution via 2.18 RC Agent
Users managing macOS devices within ControlUp reported an issue where script execution events only displayed "script started" and "script completed" messages without showing which script was run or its output. This behavior was a departure from prior functionality, where script details and outputs were visible. Windows devices did not exhibit this problem, and macOS scripts continued to generate output as expected. The concern arose when verifying the actual execution of scripts on macOS devices became necessary, but the ControlUp console failed to surface detailed script information.
Further investigation revealed that ControlUp versions 2.17 and 2.18 for macOS, as well as the Windows version, should include script details in raw event data accessible either through developer browser tools or the ControlUp API endpoint at https://api.controlup.io/reference/get-system-events. However, in the normal device view within ControlUp, the description field showing script details was missing or blank, even though the event index properly contained the script output information. This suggested a user interface issue rather than a complete loss of the event data.
The root cause appeared to be tied to the macOS 2.18 release state. The 2.18 build available was a special release candidate (RC) version, not yet generally available (GA), and it contained fixes targeting this exact problem. Users running this 2.18 RC version (including builds like 2.18.301.5B9E7EB35 and RC9) reported that the issue was resolved in those builds, with script details properly displayed alongside event logs. ControlUp staff offered to enable this release candidate on affected tenants to restore full visibility of macOS script execution events.
In summary, the lack of script detail visibility on macOS devices in ControlUp event views was a recognized bug in releases prior to 2.18. The problem was fixed in the 2.18 RC macOS agent builds, which restored proper logging and display of script names and outputs. Users encountering this should verify their macOS agent version and upgrade to the 2.18 RC or later when it becomes generally available. Meanwhile, script event data can still be queried directly via the ControlUp API or found in event indices, offering a workaround until the UI fully reflects the script details. For more information on monitoring system events and interacting with the ControlUp API, consult the official documentation at https://docs.controlup.com/ and https://api.controlup.io/reference/get-system-events.
Read the entire article here...
Read the entire article here...
How to Update Device Registration Codes for Existing ControlUp Agents After Code Expiration
ControlUp has deprecated the old Device Registration Codes across all tenants, requiring a transition to new codes for agent deployment. While new agent installations using the latest Device Registration Code proceed without issues, existing devices that were registered prior to the code expiration retain the old registration code in the Windows registry. This persistence causes a problem when these devices become inactive and are removed from ControlUp. Upon attempting to re-register, the ControlUp Agent reads the outdated, expired Device Registration Code from the registry, which leads to a registration failure.
The recommended approach to resolve this for existing devices differs from the process for new installations. The latest Agent Manager deployment automatically uses the new Device Registration Code for fresh agent installs; however, it does not automatically update the registration code already stored in the registry of existing agents. Therefore, device re-registration fails if the persisted old code is expired. There is no official migration tool provided by ControlUp to update this registry value across existing installations en masse. The key registry path involved is `HKLM\SOFTWARE\Avacee\SIP` and the relevant value is `DeviceRegistrationCode`.
For an immediate workaround, ControlUp acknowledges that updating the registry manually or via script on affected devices is effective. This involves stopping the SIP Agent service, updating the `DeviceRegistrationCode` registry value to the current valid code, and restarting the service. Given that agent version auto-updates are managed separately (either by ControlUp version control or via user-managed software deployment like SCCM or Intune), it is the administrator’s responsibility to ensure deployment tools push such remediation scripts or silent Agent Manager reinstalls outfitted with the new Device Registration Code to devices at scale.
In practice, many organizations use deployment platforms such as Intune or SCCM to run remediation scripts that overwrite the expired registration code in the registry of existing agent installations, thereby preventing registration failure without full reinstallation. This approach balances efficiency and scale, allowing smooth transition without requiring large-scale agent removal and fresh installation. Administrators should plan to deploy these registry updates proactively to avoid disruptions caused by automatic agent attempts to re-register post device inactivity cleanup.
For further details on Agent Manager deployment and registry settings, consult the ControlUp documentation at https://docs.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 Use ControlUp Workflows to Add Devices to Groups and Tagging Devices Efficiently
A new user of ControlUp sought guidance on building workflows to manage device organization, specifically adding devices to groups and tagging them. The user was attempting to create a workflow starting with a "List Devices" step, filtering devices by an ID pattern containing "HR," followed by a "Set Group" step intended to assign those devices to an "HR" group. However, uncertainty arose over what value to enter in the "Device ID" field within the "Set Group" step.
A key insight provided by community members clarified that the "List Devices" action returns multiple device records, each representing a unique device. Consequently, the "Set Group" step cannot directly accept multiple device IDs at once in a simple field. Instead, it requires isolating each device's ID through iteration. This can be accomplished by using an array to collect the IDs and then looping through the array to apply the group assignment individually to each device. This approach ensures that each device is addressed correctly when setting group membership.
Further advice noted that an alternative and potentially more streamlined approach is to assign the group at the time of agent deployment. According to ControlUp's official documentation on agent installation and distribution (https://support.controlup.com/docs/edge-dx-agent-distribution-and-installation-for-windows#installation-methods), groups can be set during the agent installation process itself, which might simplify workflows where initial grouping is critical.
For complex or specific setup requirements, it is recommended to consult your ControlUp Customer Success Manager (CSM), who can provide tailored support based on your environment and goals. This guidance should help new users effectively automate device grouping and tagging using ControlUp workflows while leveraging best practices outlined in the official resources.
Read the entire article here...
Read the entire article here...
Understanding macOS Crash Reporting in ControlUp 2.18 through the Windows Event Log Data Source
Starting with version 2.18, the ControlUp agent introduced a new feature that captures macOS crash reports in a manner similar to how Windows crash events are reported. Specifically, macOS crash events are logged into the `win_event_log` data source. Despite the name suggesting Windows-specific logs, the `win_event_log` was retained for these macOS crash reports to maintain compatibility with existing dashboards, reports, and other analytics tools that use this data source.
In the `win_event_log`, macOS events can be identified by the `platform` column, which uses the value 2 to represent macOS. This mechanism allows users to distinguish between Windows and macOS crash events within the same log. It's important to note that prior to version 2.18, the `platform` column was either absent or not used for such differentiation because macOS crash reporting was not implemented in this way. If the `platform` column is missing in your index, it likely means no macOS crash reports from version 2.18 or later have been collected yet.
When creating dashboards or queries to analyze these logs, you cannot filter on `os_name` with the expectation that macOS events will appear under Windows Event Log sources. Instead, you should query the `win_event_log` but use the `platform` column to separate macOS crash events from Windows ones. This approach leverages the backward compatibility of the log source naming while correctly distinguishing between operating systems in your monitoring views.
For more detailed guidance on working with macOS crash reports and the implications of their integration in the `win_event_log`, refer to ControlUp’s official documentation and the release notes for version 2.18. These resources offer comprehensive information about this feature and best practices for its usage.
Read the entire article here...
Read the entire article here...