ControlUp Community

Connect, Learn, and Grow

CPU Related Training & Support Archives

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

Managing ControlUp’s CoreAgent on macOS without a Bundle ID

Posted on

ControlUp's C4Desktop for macOS utilizes the CoreAgent process to collect and transmit inventory data to the ControlUp platform. This agent is responsible for maintaining device registration, managing credentials, and facilitating communication between the device and ControlUp services. Additionally, CoreAgent oversees scheduled tasks such as periodic device reporting, license checks, and configuration updates. It also monitors and manages supporting modules that gather specific data, including CPU usage, Wi-Fi status, process information, crash reports, location data, and collaboration application activity. In the event that any of these supporting modules cease functioning, CoreAgent is designed to restart them to ensure continuous data collection. Furthermore, CoreAgent serves as the central hub for data transmission, securely uploading collected information to ControlUp and facilitating features like remote control and file browsing. The CoreAgent binary is located at `/usr/local/com.controlup.edgedx.agent/Bin/CoreAgent` on macOS systems. It's important to note that CoreAgent is a signed binary and not an `.app` bundle, which means it does not have a `CFBundleIdentifier` and, consequently, lacks a bundle ID. This absence can present challenges when integrating with Mobile Device Management (MDM) solutions like Jamf, which typically rely on bundle IDs for application management. ControlUp does not publish a bundle ID for CoreAgent, and there is no documented `CFBundleIdentifier` for it in the Jamf or MDM documentation. Instead, for CU4Desktop on macOS, MDM profiles target other agent components by bundle ID. The main one tied to the core agent stack is: This approach allows MDM solutions to manage and configure the necessary components of the ControlUp agent effectively, even in the absence of a bundle ID for CoreAgent itself. For detailed instructions on deploying ControlUp for Desktops with Jamf, including the creation of configuration profiles and deployment scripts, refer to the official ControlUp documentation. ([support.controlup.com](https://support.controlup.com/docs/deployment-with-jamf?utm_source=openai)) In summary, while CoreAgent is integral to the functionality of ControlUp's C4Desktop for macOS, its lack of a bundle ID requires alternative methods for management and deployment, particularly when using MDM solutions like Jamf. By targeting other agent components with known bundle IDs, organizations can effectively deploy and manage the ControlUp agent on macOS devices.

Read the entire article here...

How to Create CPU Usage Alerts in ControlUp That Exclude Restart and Boot Spikes

Posted on

A common challenge in monitoring CPU usage is avoiding false alerts during system restarts or boot periods, when CPU spikes are normal but typically short-lived. One effective method to address this in ControlUp is to configure an alert rule targeting the device_status data index with specific conditions to filter out these transient spikes. To create a CPU alert that excludes restart or boot-phase spikes, set up a static threshold alert on Devices with a condition such as cpuload > 80 (adjust the threshold based on your environment). The key element is applying a time window and hit count that accommodates short bursts without triggering alerts. For example, use a time window of 600 seconds (10 minutes) and require 5 hits within that period before the alert fires. Additionally, a retrigger delay of 3600 seconds (1 hour) helps reduce repeated alerts for sustained high CPU usage. This configuration works because CPU usage during boot or restart typically spikes briefly and does not persist long enough to meet the hit criteria within the time window, thereby filtering out most false positives without complex logic. For situations where CPU remains elevated for longer periods during boot—due to updates, login scripts, or heavy startup applications—it is recommended to implement an uptime check or guard. This further refines alerting by ensuring the system has been running beyond a certain uptime threshold before alerts activate. These steps provide a practical approach to balancing sensitivity and noise in CPU alerting, improving monitoring accuracy in environments where restarts cause predictable, short-term CPU spikes. For more detailed guidance on creating and tuning alert rules, consult the ControlUp documentation at https://docs.controlup.com/alert-rules and consider exploring uptime monitoring techniques available in ControlUp's device health metrics.

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

How to View Device and Experience Scores in ControlUp Dashboard

Posted on

Some employees were discussing the combination of Device Score and Experience Score in a consolidated view or score. @member asked if there was any built-in reports or dashboards to view this combination, and @member answered that it exists within the DEX Score Trending Dashboard from the Dashboard Gallery. However, there was some confusion as to whether this data is based on the Device Score or the Experience Score. It was clarified that the metric used is the Experience Score, and the breakdown of this score can be found in the Employee module. The team discussed different ways to view and analyze this information, and it was suggested that a call be set up for a deeper dive into the dashboards. The conversation also referenced ControlUp URLs such as https://support.controlup.com/docs/device-score and https://support.controlup.com/docs/experience-scores.

Read the entire article here...