ControlUp Community

Connect, Learn, and Grow

ControlUp Insights Related Training & Support Archives

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

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 Use ControlUp Live View to Identify Processes Causing CPU Spikes in VDI Environments

Posted on

When attempting to diagnose CPU spikes and identify the specific processes responsible using ControlUp, the most effective approach is to utilize the Live view, also known as the VDI page in the ControlUp Web UI. This view provides real-time, granular insights into process-level CPU consumption across virtual desktop infrastructure (VDI) environments. Unlike historical reports, which show aggregated past data such as CPU Utilization Max but lack immediacy, the Live view updates metrics approximately every three seconds, enabling administrators to track CPU spikes as they happen and correlate them with individual processes. Accessing this Live view requires either appropriate licensing or configuration that may prompt for a user principal name (UPN) login depending on how ControlUp is set up in the organization. When correctly logged in, administrators can drill down into specific machines experiencing CPU spikes and see a detailed, sortable list of CPU-intensive processes. This functionality helps pinpoint the exact processes causing resource bottlenecks, which is critical since the total CPU utilization of a machine does not always equal the sum of all visible processes. This discrepancy arises because kernel interrupts and other system-level operations that consume CPU are not attributed to individual user processes. Users noted that if access to the Live view is initially unavailable or the relevant VDI tab not visible, it may be due to missing licenses or particular configuration settings controlled by the ControlUp administrator in the environment. In such cases, reaching out to the administrator and providing the UPN for authentication often resolves access issues. Without this, troubleshooting CPU spikes becomes difficult, and users may resort to external scripting solutions like PowerShell, which can be less reliable and less integrated. Once logged into the Live view, operators can monitor real-time CPU usage per user and process, identify the top five consumers, and respond quickly to performance incidents causing a slowdown in the VDI environment. While the Live view is potent for immediate troubleshooting, storing long-term granular process data in a live manner is impractical due to data volume and cost, so ControlUp uses historical reports for trend analysis. Overall, the Live view is regarded as an essential and powerful feature in ControlUp’s suite for understanding and resolving CPU utilization spikes in virtualized desktop environments. For further information on configuring and accessing the Live view in ControlUp, administrators can consult the official ControlUp documentation at https://docs.controlup.com and the ControlUp Academy at https://cuacademy.controlup.com. These resources cover licensing requirements, configuration steps, and best practices for effectively using real-time monitoring to maintain optimal VDI performance.

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

How to Pinpoint CPU-Heavy Processes Across Your VDI Fleet with ControlUp

Posted on

This thread walks through a real customer question: how do you find which processes are eating the most CPU across a large VDI estate (200 servers) over a long period, so you know what to optimize? It starts in ControlUp Dashboards. Using the VDI process data, you can build a widget showing top processes by CPU, then narrow it to the machines you care about using global filters (filter by folder, or switch to query filters with IS / IS NOT). A table beats a bar chart for a top-50 view, and any filters and time frames you set are saved in the URL, so you can bookmark or share the exact view. The built-in Gallery dashboards (notably "Big Screen Dashboard VDI") already include a processes-by-CPU widget out of the box. The harder part is the one the customer really cared about: getting a meaningful picture across all machines rather than a single noisy spike on one box. The data is stored per process per 5-minute timeslot, not pre-aggregated per machine, so the practical approach that emerged was: Filter to the folder containing all target machines. Use CPU usage P95 to strip out short, expected spikes (with a fallback to average CPU, since P95 returned N/A in some environments — a possible bug worth a support ticket). Add metrics under Advanced: computer_name (unique count) to see how many machines run the process, and process_name (count) to see how often it appeared (each record ≈ a 5-minute aggregate). The processes worth optimizing are the ones combining high CPU + high machine count + high record count. Worked example: a process showing ~1,080 records across 197 machines roughly translates to ~90 hours of activity over 7 days, or a few minutes per machine per day. The same method surfaced candidates like CompatTelRunner.exe, WerFault.exe, and WEM-related activity for further investigation. To go deeper, the App Trends and App Statistics reports let you drill into a specific app, and product_name data helps identify what's actually behind generic process names like setup.exe. A few important caveats came up: averages hide spikes (10% average could be one minute at 100%), process counts are per machine, and hypervisor-level CPU (e.g., XenServer) can disagree with in-VM agent data when hosts are over-provisioned — which is also why a Sizing Recommendations report may suggest removing vCPUs even on a machine that looks maxed out. Bottom line: use the dashboard to identify the heavy processes (folder filter + P95/avg CPU + machine count + record count), then use the App Trends report to dig into the details per app.

Read the entire article here...

Troubleshooting CPU Utilization Data in ControlUp App Trends Report

Posted on

A user asked about issues with CPU utilization data not showing in the App Trends report, to which Yoni responded that it is common for many processes to sit at 0% CPU and suggested checking the distribution for more insights. Another user inquired about checking successful vs failed sessions, to which another user requested clarification about what is meant by "failed sessions." The discussion included a screenshot and example of checking process distribution.

Read the entire article here...