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...
Microsoft Windows Related Training & Support Archives
Microsoft Windows training and support-related archives from inside the ControlUp Community on Slack.
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...
Automating Detection and Remediation of Stuck BitLocker Encryption on Windows 11 Endpoints with ControlUp Real-Time Automation Engine
When deploying hundreds of Windows 11 endpoints managed by Intune, a common issue with BitLocker encryption is that the process sometimes becomes stuck at a certain percentage completion. While manually pausing and restarting the encryption process resolves the issue within minutes, automating this detection and remediation can save considerable time and ensure consistent endpoint security.
Using ControlUp Real-Time Automation Engine (CU4D), such automation is achievable by leveraging scripted detection and remediation. One approach is to create a single script that both detects the encryption status and initiates a restart of the encryption process if it remains stuck at the same percentage. This script can be deployed across all affected devices and scheduled to run periodically, for example, once per day, to identify any stuck BitLocker jobs and resolve them promptly.
A more modular approach involves creating two separate scripts: a detection script and a remediation script. The detection script would check the current encryption percentage, and if it identifies a stuck state, it writes the status to a custom index attribute within ControlUp. An alert can then be configured based on the value of this custom attribute. When the alert triggers due to a stuck encryption status, the remediation script executes automatically to restart the BitLocker encryption, ensuring a timely resolution without manual intervention.
This method harnesses ControlUp's ability to store custom scripted outputs in custom indices and link those to alert triggers, thus providing a robust, automated way to handle encryption stalls on Intune-managed Windows 11 devices. For further details on configuring custom scripts, custom indices, and alerts in ControlUp, administrators can refer to ControlUp's documentation at https://docs.controlup.com and explore automation capabilities in the ControlUp Academy at https://cuacademy.controlup.com.
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...
Troubleshooting Access Denied Errors When Upgrading ControlUp Monitor Servers Using PowerShell
When upgrading a ControlUp monitor server from version 9.0.0.1680 to 9.2.0.733 using the PowerShell commandlet Invoke-CUMonitorUpdate, the process may fail with an "Access is denied" error. This failure occurs after the installation steps "Install Verify Service already installed" and "Install Copy Files" complete successfully, specifically at the step involving stopping the `cuMonitor` service. The error indicates that Windows denied access during the attempt to stop or control this service, despite running PowerShell as an administrator and having folder-level access to the monitor installation directory.
The root cause is typically related to security settings or interference by antivirus (AV) or endpoint detection and response (EDR) software, which can block the service from stopping. Alternatively, a restrictive service Access Control List (ACL) can prevent the upgrade from proceeding. When attempting to upgrade through the ControlUp Console, a similar failure occurs silently because the console relies on remote commands (via admin share or WMI) that suffer the same permissions restrictions.
To resolve this issue, manually stopping the `cuMonitor` service with elevated privileges is required. Running `sc.exe stop cuMonitor` on the monitor host as an administrator can successfully stop the service. If this command fails, it is necessary to configure AV/EDR exclusions for the ControlUp monitor executable and folder (`C:\Program Files\Smart-X\ControlUpMonitor\` and `cuMonitor.exe`) or adjust the service's ACL using `sc.exe sdshow cuMonitor` to inspect and modify permissions. Once the service is stopped, re-running the Invoke-CUMonitorUpdate commandlet completes the upgrade successfully.
When upgrading through the ControlUp Console, ensure the account used has local administrator rights on the monitor host; otherwise, upgrade via the PowerShell commandlet locally on the machine is recommended for reliability. This approach has been verified to resolve the access denied error and enable the upgrade to proceed without interruption.
For more details on managing ControlUp monitor services and upgrade procedures, refer to the official ControlUp documentation at https://docs.controlup.com or consult ControlUp support resources.
Read the entire article here...
Read the entire article here...
ControlUp Community Meetup 15: How to: Connecting MCP AI to your Real-Time Data
Learn how to connect AI to live enterprise data using the ControlUp MCP Server. In this session, Chris Twiest explains the fundamentals of Model Context Protocol (MCP), including LLMs, prompts, system prompts, tool calling, and retrieval, before demonstrating how to connect Claude Desktop to ControlUp. Watch a live walkthrough of configuring the MCP Server, querying real-time endpoint data, visualizing application crashes, comparing results against historical baselines, and using system prompts to dramatically improve AI accuracy. The session also explores practical use cases, including upgrade planning, combining multiple MCP servers, building custom AI interfaces, and the future of autonomous endpoint management.
Read the entire article here...
Read the entire article here...
Troubleshooting PowerShell Script Execution Failures in User Context with Ivanti Application Control and ControlUp
A user encountered an issue when attempting to run PowerShell scripts on endpoint machines using ControlUp (CU) in the user context. While executing scripts in the system context was successful, running them as the user failed with an error code -1. The environment included Ivanti Application Control, a security solution similar to Windows Defender Application Control (WDAC) or AppLocker, which enforces application execution policies. The user had configured a process rule allowing SipAgent.exe to launch PowerShell.exe, which was confirmed to function correctly via Process Monitor and Process Explorer, as PowerShell.exe briefly appeared. However, the actual PowerShell script never executed, even a simple command like ‘Start-Sleep 1000’ failed to run.
Disabling the Ivanti Application Control service restored the ability to run scripts, indicating a conflict with the security controls. Interestingly, no block events were logged by Ivanti, suggesting the issue was not a straightforward deny event at the application control layer. The user inquired about which processes and system files ControlUp uses during script execution to better understand the interaction.
The root cause was identified as an Ivanti configuration rule that elevated PowerShell processes for the test user account. This elevation interfered with the ControlUp execution mechanism, preventing the script from running properly in user context. The resolution involved creating an exception within the Ivanti elevation rule: PowerShell processes launched with the ‘-file’ parameter were excluded from elevation. This adjustment allowed the scripts to run successfully while maintaining the intended elevation policy for other PowerShell instances.
This case highlights the importance of carefully managing application control and elevation policies in security products like Ivanti when deploying user-context scripts via ControlUp. Explicitly excluding ControlUp-launched PowerShell processes that run script files from elevation can prevent execution failures without compromising security. Users facing similar issues should review their application control and elevation configurations, particularly any rules that modify or elevate PowerShell, and test exclusions for script execution parameters. For more details on ControlUp’s script execution methods and related settings, users can consult the official ControlUp documentation at https://docs.controlup.com.
Read the entire article here...
Read the entire article here...