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...
Logs Related Training & Support Archives
Logs training and support-related archives from inside the ControlUp Community on Slack.
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...
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...
Widget Wednesday #25: Building Dashboard Widgets with Audit Log Data
This week’s Widget Wednesday introduces a new data source for ControlUp Dashboards: the Audit Log.
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...
How to Enable File Browsing in ControlUp’s File Browser by Configuring Role Permissions
A common issue encountered with ControlUp's File Browser feature is the inability to see any files within a user's system during a remote session, despite being able to navigate folders. This typically occurs when the appropriate permissions are not enabled for the user role in ControlUp. For example, a user attempting to retrieve log files without interrupting a session might notice that the file list remains empty, even though directories are visible.
The root cause is often related to role permissions. By default, the built-in Admin role in ControlUp does not have the File Browser permission enabled for viewing files. To resolve this, administrators need to create a custom role that explicitly grants this permission. Specifically, under Device Permissions, navigating to Remote Management > Management > File Browser, the administrator must set the scope to allow users assigned this role to view files.
Once the custom role is created with the correct File Browser permissions, it is possible to assign the user both the built-in Admin role and this new custom role simultaneously. ControlUp's role-based access control supports multiple role assignments per user, enabling flexible and granular permission management without removing any existing higher-level roles such as Admin.
In summary, to access files via ControlUp’s File Browser, ensure that the user has a custom role with the "View Files" permission under File Browser enabled. This role can be combined with the default Admin role, allowing complete management capabilities while enabling file browsing. For detailed role creation and permission configuration instructions, refer to ControlUp's official documentation on role management at https://docs.controlup.com.
Read the entire article here...
Read the entire article here...
Investigating Historical Network Usage Spikes and Setting Alerts with ControlUp for Desktops
A user reported a network performance issue at one of their offices where a single computer had downloaded and uploaded several gigabytes of data within approximately the last four hours. They sought a way to determine exactly what data was downloaded and where it was uploaded to after the fact.
ControlUp experts clarified that while ControlUp for Desktops can provide detailed network usage volume information retrospectively, it does not store historical data about the specific destination addresses or detailed process-level network activity. The device’s Performance tab includes historical charts such as Network Usage (MB/s) and Hourly Network Usage (MB), which show the volume of data sent and received over time. This helps confirm the timing and magnitude of a network spike but only at the overall device level, not by specific process or destination.
For live, real-time network connection details—including which process is communicating with which remote IP address—the Network tab and TCP Connections Map can be used. This tab shows detailed, process-to-destination connections but does not retain historical data, so it only helps monitor ongoing network activity. Consequently, if the large data transfer activity occurred several hours ago and is no longer ongoing, ControlUp itself cannot provide retrospective insights into the process or endpoints involved.
To investigate historical transfers of this nature, network security and monitoring should be supplemented with firewall logs, proxy logs, or netflow data, which retain detailed connection records over time. This approach is recommended for network administrators with access to those tools.
For prevention and proactive detection, users can configure static threshold alerts in ControlUp to notify them immediately if network usage exceeds a predefined value in the future. This allows administrators to catch high-volume transfers as they happen and investigate using real-time detail from ControlUp. The documentation for setting static threshold alerts can be found here: https://support.controlup.com/docs/devices-static-threshold-alerts.
Additional guidance on real-time network analysis is available at https://support.controlup.com/docs/live-network-analysis.
Read the entire article here...
Read the entire article here...