Recently, some users have reported an issue where the ControlUp Agent Manager does not automatically install the SIP agent on clients when deployment is done via SCCM or Intune. Although the Agent Manager installs and communicates as expected, the clients do not proceed to download and install the SIP agent themselves. This problem was noted because affected clients were not appearing in the ControlUp console until the SIP agent was installed manually on each machine.
The troubleshooting process included verifying that the deployment codes configured in SCCM and Intune were correct, with confirmed successful manual installations of the SIP agent. Despite the automatic deployment process working previously, the behavior changed starting last Wednesday, and no known recent changes to the ControlUp agent registration process have been identified that could explain this new issue.
A key insight from the community was the importance of confirming whether the feature allowing automatic agent installation via the Agent Manager is properly configured. If it is not active or set up correctly, this would directly cause the failure of automatic SIP agent installations. In this case, however, the configuration was verified as correct, so the root cause remains unclear at this point.
Given that this issue was new and had not been encountered before, the recommended next step was to log a support case with ControlUp. This would allow their support team to review detailed logs and provide a deeper analysis. As of the last update, resolution had not been confirmed, and ControlUp support engagement is needed to identify any underlying changes or bugs affecting the automatic SIP agent deployment process in the current environment.
For more information on managing agent installation and push deployment methods, consult the ControlUp documentation on agent installation at https://docs.controlup.com/wiki/agent-installation and related deployment best practices.
Read the entire article here...
Logs Related Training & Support Archives
Logs 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...
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 FSLogix Profile Compression Event Log Collection in ControlUp Agents
A community member aimed to monitor FSLogix profile compression activity on shared desktops by creating a custom event log rule in ControlUp, cloned from an existing rule. Despite confirming the session hosts had relevant event log entries locally and that the ControlUp agent on those machines was active and sending other data, the new rule failed to pull in the FSLogix compression events.
Initial troubleshooting confirmed that all relevant ControlUp monitors and agents were updated to version 9.2.5.686. Since the setup appeared correct, the next step suggested was to open a support ticket for deeper investigation. However, another community member pointed out a similar known issue documented in a prior Slack thread, referencing an upcoming ControlUp software version (9.2.5.776) release scheduled for September 10, 2026, that reportedly addressed such event log collection problems.
Further clarification noted that while version 9.2.5.776 was available, the specific fix for this FSLogix event collection issue might not have been included in that release yet but expected in the next version update. To verify functionality, one member created a nearly identical event log collection rule targeting informational events with ID 57 (typical of FSLogix profile compression logs), derived from ControlUp's built-in FSLogix rules. This rule successfully captured multiple events from the VDI event logs, indicating the method itself was functional and suggesting that upgrading to version 9.2.5.776 might resolve the issue.
The consensus recommendation was to attempt the upgrade to version 9.2.5.776 first, as this could potentially fix the event log collection problem. Users encountering similar difficulties with FSLogix event gathering should ensure their ControlUp agents and monitors are updated to this or a later version and may benefit from revisiting built-in FSLogix templates for rule creation. For unresolved cases, opening a support ticket with ControlUp is advised to facilitate a resolution.
For further reference on creating and managing event log rules, see the ControlUp documentation at https://docs.controlup.com or ControlUp Academy at https://cuacademy.controlup.com.
Read the entire article here...
Read the entire article here...
Troubleshooting 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...
Troubleshooting Missing Description Field in ServiceNow Tickets Created by ControlUp Templates Due to ACL Permissions
When using ControlUp's built-in templates for creating ServiceNow tickets, such as the Battery/Hardware Replacement Request, users may encounter an issue where the ticket is generated correctly with the appropriate short description, priority, and assignment group, but the detailed description field (result) is not populated. While the description input is visible during the creation process, the corresponding field in ServiceNow remains empty despite the ticket's successful creation.
This symptom typically indicates a permissions-related issue rather than a problem with the template or ControlUp’s integration logic. Specifically, the root cause is often related to Access Control List (ACL) settings in ServiceNow. The integration user account configured in the ControlUp-ServiceNow connection might have the necessary permission to create records but lacks write access for certain fields, such as the Description field on the Incident table. When ServiceNow receives the ticket creation request, it accepts the record creation but silently skips the fields that the user cannot update, leading to the description field being omitted without any error message.
To resolve this, verify that the user configured for the ServiceNow integration has full write permissions to all the required fields on the Incident table, including the Description field. This may involve adjusting ACL rules and permissions in ServiceNow’s user roles and security settings. Testing with an account verified to have full write access confirmed that the Description field populated correctly, indicating the problem indeed lies in ServiceNow’s ACL settings rather than ControlUp itself.
For further troubleshooting, gathering detailed logs from the ServiceNow side and submitting a support ticket along with this diagnostic information can help ControlUp support investigate more complex cases. More information on configuring and troubleshooting ServiceNow integration permissions can typically be found on official ControlUp resources and ServiceNow documentation.
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...
Resolving Permission and Custom Field Issues When Creating ServiceNow Records via ControlUp Flows
When attempting to create an event in ServiceNow via a flow, a common issue encountered is the error message stating, "You don't have permission for this action(edit_ai_agent)." Despite this message, extra fields can be added in the flow, but these custom fields do not appear in the REST message received by ServiceNow. This issue is often accompanied by the problem where fields such as short description, description, or custom fields (e.g., "company") show up empty or without values on the created record, especially when the target is a custom table extended from the task table.
The root cause of the permission error "edit_ai_agent" was identified as a bug on the integration side, which was scheduled to be fixed in an upcoming release. Importantly, this error itself does not affect the actual payload sent to ServiceNow. Rather, the missing field values within ServiceNow are typically due to two main configuration issues on the ServiceNow instance side. First, custom fields must be referenced using their internal column names, which start with the prefix "u_" (for example, "u_company") rather than their field labels. ServiceNow ignores unknown or incorrectly named fields silently without showing an error. Second, the integration user account used by the flow requires proper Access Control List (ACL) permissions: specifically, it needs create ACL rights on the custom table and write ACLs on the individual fields. Without these permissions, ServiceNow will create the record but omit values for fields lacking write permissions, resulting in empty fields.
To validate what data is actually received by ServiceNow, administrators can use the inbound REST transaction logs (found under System Logs > Transactions) to inspect incoming requests. If there are errors like "ACL Exception Insert Failed" in the flow's run history, it confirms that ACL permissions need adjustment for the integration user. Ensuring these conditions—correct internal field names with the "u_" prefix and appropriate ACL permissions—will allow custom fields to populate correctly in ServiceNow records created via the flow.
Relevant documentation for working with ServiceNow's field naming conventions and ACL settings can be found in ServiceNow's official resources, and for troubleshooting integration issues, ControlUp's knowledge base and support channels offer further guidance. The fix for the "edit_ai_agent" permission bug was targeted for the next product release following this report.
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...
Troubleshooting Missing Unified Access Gateway Metrics in ControlUp Due to Horizon API Version Limitations
When configuring the connection to VMware Unified Access Gateway (UAG) in ControlUp version 9.2.5.634, a common issue arises where the UAG appears connected but does not show any metrics or visibility under the EUC Environment or the DEX Connection Servers section. Although the initial connection test succeeds, UAG metrics are missing from the interfaces, leading to confusion about what might be incorrectly configured.
One critical root cause identified is related to the Horizon REST API version supported by the UAG and Connection Servers. ControlUp relies on Horizon’s Monitor Gateways API version 5 to retrieve UAG data, but many Horizon environments running version 2412 or earlier only support versions 3 or 4 of this API. This incompatibility prevents ControlUp from properly monitoring the UAG, resulting in the absence of UAG metrics despite a seemingly successful connection configuration. This limitation is not explicitly detailed in ControlUp’s documentation, making it an easy pitfall for users in older Horizon environments.
Users who upgraded their Horizon Connection Servers to version 2603 reported that after refreshing the UAG settings in ControlUp, UAG metrics became visible and functional, confirming that full UAG monitoring support requires Horizon environments with API version 5 or newer. For those in unsupported environments, the UAG section will fail to sync correctly, although some other synchronization data like "NIC" sync may still appear. This partial failure causes issues with automatic EUC syncs, which will fail on an hourly schedule unless UAG syncs are disabled. Manual syncs from the ControlUp Console, however, still function as a workaround until an official fix or workaround is provided by support.
In light of these findings, users experiencing missing UAG metrics should verify the Horizon API version compatibility and consider upgrading their Horizon environment if UAG monitoring is required. It is also advisable to coordinate with ControlUp support to analyze logs and explore potential short-term solutions. Additional monitoring configuration details can be found in ControlUp’s official documentation on monitoring OmniSaaS and UAG here: https://support.controlup.com/docs/monitor-omnissa-unified-access-gateway. This document clarifies the expected behaviors and limitations with UAG monitoring in various Horizon versions.
Read the entire article here...
Read the entire article here...
