ControlUp Community

Connect, Learn, and Grow

Microsoft Windows Related Training & Support Archives

Microsoft Windows training and support-related archives from inside the ControlUp Community on Slack.

How to Deploy ControlUp Agent via GPO in VDI Environments with MSI Silent Install and PowerShell Automation

Posted on

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...

Troubleshooting Access Denied Errors When Upgrading ControlUp Monitor Servers Using PowerShell

Posted on

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...

ControlUp Community Meetup 15: How to: Connecting MCP AI to your Real-Time Data

Posted on

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...

Troubleshooting PowerShell Script Execution Failures in User Context with Ivanti Application Control and ControlUp

Posted on

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...

How to Implement Native macOS and Windows Self-Service Disk Cleanup via ControlUp Edge DX Without External Tools

Posted on

A ControlUp community member developed a native self-service disk cleanup solution for macOS and Windows users, designed to be triggered via ControlUp Edge DX without requiring IT intervention or external tools. The goal was to allow users to safely free disk space through a simple, native dialog that displays current disk usage and offers a checklist of safe-to-clean areas such as Trash, application caches, container caches, logs, Xcode build cache, and old temporary files. Each item is described in plain language and sorted by the space it occupies, allowing users to select and confirm the cleanup themselves. On macOS, the dialog is implemented using only built-in osascript capabilities—no additional tools like swiftDialog or extra installations are necessary. For both macOS and Windows, the solution emphasizes safety by running a dry-run by default, excluding critical system folders and personal directories such as Documents, Downloads, Keychains, and SSH keys from cleanup. The cleanup operates within the context of the logged-in user, not root, ensuring user-specific data protection. After cleanup, the system verifies the amount of space reclaimed against the actual free volume. Triggering this cleanup from an Edge DX alert, either automatically due to disk usage thresholds or on-demand, enables a small dashboard that reports on reclaimable and freed disk space, all without requiring elevated permissions, Intune writes, or admin consent. One of the more challenging technical aspects was delivering the cleanup dialog from a root-level agent into the user’s session, given the restrictions of macOS and Windows environments. The community member shared that while the script could likely be optimized or shortened by more experienced developers, this version works reliably and safely. Detailed setup documentation is available by request. Additionally, to complement the cleanup tool, the developer created an analytics dashboard to track the cumulative space saved by the script. This solution offers a practical way for organizations using ControlUp Edge DX to empower their end users with safe, controlled disk cleanup capabilities, minimizing helpdesk workload without compromising disk security or user privacy. For more on creating and managing custom alerts and actions within ControlUp Edge DX, consult the official documentation at https://docs.controlup.com/edge and explore ControlUp Academy at https://cuacademy.controlup.com for training on extending ControlUp functionality.

Read the entire article here...

Analyzing Windows Client Boot Time Delays: Using External Scripts to Generate Boot Performance Reports in ControlUp Environments

Posted on

A community discussion sought an effective method to analyze Windows client boot times with detailed insights into the causes of any delays. The original inquiry focused on whether there was an existing script or dashboard capable of breaking down boot delays, as the environment faced issues with slow client startups. Such diagnostics would provide valuable information to address client performance problems. In response, a community member shared a beta script designed as a boot analyzer, which generates an HTML report summarizing boot performance. This script creates an output that visually breaks down boot times, helping identify the components or processes causing delays. However, the script does not currently save boot information within the ControlUp platform because the ControlUp agent is not active during the Windows boot phase, preventing direct integration of boot data into ControlUp's indexes. While the script is substantial and complex, it offers a practical starting point for environments needing detailed boot-time diagnostics. The contributor noted the lack of time to fully test writing the boot data to the ControlUp index but confirmed the HTML report format is functional and aesthetically clear. The shared approach highlights the current workaround for boot analysis within ControlUp environments: external data collection and report generation rather than native ControlUp indexing, due to agent limitations during system startup. For users seeking to monitor boot performance in Windows clients using ControlUp, this solution involves running external scripts to analyze boot metrics and then reviewing detailed offline reports. Until ControlUp supports native boot-time data collection via its agent during the startup phase, such scripts provide the most direct method to diagnose and troubleshoot boot delays.

Read the entire article here...

How to Alert on Added Storage Devices by Drive Letter in ControlUp Using os_disk_configuration Filters

Posted on

A community member sought assistance with creating a ControlUp trigger or alert to detect when storage devices are added to a physical endpoint and assigned a drive letter or mounted. The data relevant to this event is visible in the ControlUp 4D (CU4D) Performance tab under the Operating System location and stored in the *_devices* index. Specifically, the data is found in the os_disk_configuration field, which contains a JSON array showing details about mounted drives, including drive letters. The user’s challenge was to configure an alert that could detect any newly mounted drive except the system drive C:\ without having to set multiple alerts for every potential drive letter (e.g., D:\, E:\, etc.). They noted the lack of regex support in the filter queries limited their options. The issue arises because the os_disk_configuration field holds a JSON array with multiple drive entries, and filtering out drive_letter "C:\" naively removes all entries due to the structure of the array. Attempts to use a “does not contain” filter eliminated all Windows devices, only showing macOS devices, complicating detection on Windows endpoints. The user also tried to narrow the focus to removable media but learned that their security team's use case requires alerting on any disk, mounted by drive letter, which remains the best indicator available. Advice provided during the discussion included adding filters for platform or OS to ensure the alert targets only Windows devices (e.g., platform set to 1 or OS equals Windows). This helped reduce irrelevant results but did not completely solve the filtering problem. Suggestions included playing with additional filters such as combining conditions to exclude drive_letter "C:\" while explicitly including removable devices, though this required trial and error. A recommendation was to test filter configurations in the CU4D index view, including setting the platform to 1 to target Windows devices specifically. Ultimately, the thread highlights the challenge in using ControlUp’s current filtering capabilities on complex JSON arrays like os_disk_configuration for dynamic drive letters without regex support. The workaround involves narrowing the scope by platform/OS filters and experimenting with composite negation filters, although a straightforward out-of-the-box solution for this specific alert scenario is limited. Users needing comprehensive coverage for any drive letter other than C:\ must create a series of alerts or await enhanced filter features. For now, leveraging the detailed disk configuration data in the *_devices* index with strategic filter layering is the best approach. For further reading on creating and troubleshooting alerts and filters in ControlUp, users can consult official documentation at https://docs.controlup.com and explore ControlUp Academy resources at https://cuacademy.controlup.com.

Read the entire article here...

How to Diagnose Microsoft Teams SlimCore Optimization in Citrix and Other VDI Environments Using PowerShell Scripts

Posted on

This discussion highlights two PowerShell scripts developed to aid tracking and diagnosing Microsoft Teams SlimCore Optimization specifically within Citrix environments, with potential applicability to Azure Virtual Desktop (AVD), Windows 365 (W365), and VMware Horizon sessions. SlimCore is an optimized media stack used in virtual desktop infrastructure (VDI) scenarios to enhance Teams call performance by offloading audio and video processing to the client side.

Read the entire article here...

How to Calculate and Display Compliance Percentage Using ControlUp JSON Query and Transformations

Posted on

This discussion addresses how to display a compliance percentage in a ControlUp dashboard card based on two widget values: total devices and compliant devices. The goal is to calculate and show a compliance rate as a percentage, for example, showing 5% if 10 out of 200 devices are compliant. The solution involves using the ControlUp JSON builder with a custom query and transformation setup. To achieve this, the key is to use the "CombineMetrics" plugin in the JSON configuration. This plugin allows the calculation of a ratio (a percentage) by specifying the compliant devices count as the numerator and the total devices count as the denominator. Participants shared examples modeled after an AI dashboard where a similar percentage metric—percentage of users accessing AI-related websites—is calculated by summing durations and using filters. One example query includes the use of "cardinality" aggregation on device IDs, filtering by device groups and OS details to separately count total devices and compliant ones. This data is then fed into a transformation block that scales the ratio by 100 and applies precision to display the percentage nicely. The JSON snippet demonstrates how the numeratorNodeIds and denominatorNodeIds correspond to the compliant and total device counts, respectively, providing a ready-to-adapt template. Additionally, the conversation touched on the potential for applying conditional palette colors to the percentage display, similar to gauges, to visually represent thresholds (e.g., red for 0%, orange at 50%, green at 100%). Though not yet implemented, this idea is being considered as part of ongoing UI improvements. For further implementation guidance, ControlUp documentation on custom widgets and the JSON query builder is a useful resource at https://docs.controlup.com. The approach described can support not only two values but can be extended to combine multiple metrics as needed, providing flexible compliance and performance monitoring visualizations in ControlUp dashboards.

Read the entire article here...

Monitoring CPU Thermal, Power, and Frequency Throttling with Custom ControlUp Scripts and Dashboards

Posted on

A common challenge in monitoring CPU performance is that traditional CPU utilization metrics often fail to reveal the underlying causes of slowdowns, especially in cases related to thermal or power throttling that reduce CPU frequency without triggering high CPU%. To address this, a detailed custom PowerShell script and accompanying dashboard have been developed to report CPU temperature, frequency, and distinct throttling signals in a granular and actionable way. This solution creates a dedicated data index named `custom_cpu_throttle` to track multiple independent throttling signals, enabling more precise diagnostics of CPU performance issues. The core innovation of this approach lies in splitting CPU throttling indicators into three separate categories: thermal throttling (hardware/BIOS-related issues such as overheating or dust), power throttling (policy-related causes like power plans, Intune profiles, or BIOS max-state configurations), and frequency throttling (cases where the CPU clock speed drops below 85% of the rated max under load, capturing otherwise silent throttling scenarios common on AMD processors or CPUs with boost frequencies). By differentiating these factors, the method captures scenarios where traditional Event ID 37 logs or CPU utilization metrics miss critical performance degradations. The script captures a range of per-device metrics during each run, including temperature and its source, throttle status types, current and maximum CPU frequency with a ratio percentage, and comprehensive throttling evidence logs that correlate performance drops with frequency and utilization data. This data feeds into a customizable ControlUp dashboard that aggregates key performance indicators, categorizes throttle types, tracks frequency trends, and identifies devices exhibiting the hottest or most throttled behavior. The dashboard also correlates these metrics with user experience signals like application crashes and digital employee experience (DEX) scores, enabling targeted troubleshooting from a single pane of glass. Technical details specify that the solution runs on Microsoft Windows devices using PowerShell scripts triggered every two minutes (120 seconds) with a 60-second timeout and sends data to the `custom_cpu_throttle` index only when devices are online. The solution supports filtering by device, throttle type, and status for focused analysis. While the script covers many AMD-specific throttling scenarios, some complexities remain given AMD's diverse behaviors, though unrealistic values are filtered out to maintain accuracy. This tool is well-suited for IT administrators and helpdesk teams looking to resolve performance tickets where CPU utilization appears normal but throttling impacts response times, such as in Outlook or other user-facing applications. For detailed setup or a walkthrough, the script (`SP-CPU-Throttle-v2.ps1`) and ControlUp dashboard configuration (`SP-CPU-Throttle-Dashboard.json`) are available on request. This solution is an example of extending ControlUp’s monitoring capabilities via custom scripts and dashboards to deliver deeper insights into CPU performance issues that go beyond default instrumentation.

Read the entire article here...