When IP Restrictions are enabled in a ControlUp organization, they apply not only to user sign-in at app.controlup.com but also to REST API calls that use API keys or tokens for authentication. Initially, there was confusion about this behavior, with one party assuming that IP Restrictions only affected user sign-ins via the web application and would not restrict API calls. However, further investigation clarified that IP Restrictions do indeed apply to API requests.
The key issue encountered was that reporting workflows that fetch machine statistics via the REST API started returning "Unauthorized" errors after IP Restrictions were enabled. Although the API tokens used for authentication were verified as valid and not expired, the requests failed due to the IP restriction settings.
The resolution involves adding the public egress IP addresses of the systems making the API calls (such as those running the reporting workflows) to the organization's IP Allow List in ControlUp. This setting is accessible under Settings → Security → IP Allow List in the ControlUp management console. Once the calling system’s IP addresses are added to the allow list, API calls from those IPs will be authorized, provided a valid API token is also used.
For more detailed guidance, official ControlUp documentation and references include the API endpoint for managing IP allow lists (https://api.controlup.io/reference/orgipallowlistpubliccontroller_create) and the knowledge base article on IP Allow Lists (https://support.controlup.com/docs/ip-allow-list). These resources offer comprehensive instructions for configuring the IP Allow List to control API access securely.
Read the entire article here...
Security Related Training & Support Archives
Security training and support-related archives from inside the ControlUp Community on Slack.
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...
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...
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...
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...
How to Implement Native macOS and Windows Self-Service Disk Cleanup via ControlUp Edge DX Without External Tools
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...
Read the entire article here...
Managing Access to Microsoft Teams Meeting Recordings: Insights and Permissions
ControlUp does not currently offer direct insights into Microsoft Teams meeting recordings or their access logs. Meeting recordings in Teams are stored in the organizer's OneDrive or SharePoint, depending on the meeting type. For private meetings, recordings are saved to the organizer's OneDrive, while channel meetings store recordings in the SharePoint site associated with the channel. ([learn.microsoft.com](https://learn.microsoft.com/en-us/MicrosoftTeams/tmr-meeting-recording-change?utm_source=openai))
To monitor access to these recordings, organizations can utilize Microsoft Purview, which provides auditing capabilities for Teams content. Purview allows administrators to track activities related to meeting recordings, such as who accessed or shared the recordings. This functionality is particularly useful for compliance and security purposes. ([learn.microsoft.com](https://learn.microsoft.com/en-us/purview/edisc-search-teams?utm_source=openai))
Additionally, meeting organizers can manage access permissions for their recordings directly within Teams. By default, access is set to "Everyone," but organizers can customize this setting to restrict access to specific individuals or groups. This control ensures that only authorized users can view or download the recordings. ([support.microsoft.com](https://support.microsoft.com/en-us/teams/meetings/customize-who-can-access-a-recording-or-transcript-in-microsoft-teams?utm_source=openai))
In summary, while ControlUp does not provide direct insights into Teams meeting recordings, organizations can leverage Microsoft Purview for auditing access and utilize Teams' built-in features to manage recording permissions effectively.
Read the entire article here...
Read the entire article here...
How to Alert on Added Storage Devices by Drive Letter in ControlUp Using os_disk_configuration Filters
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...
Read the entire article here...
How to Diagnose Microsoft Teams SlimCore Optimization in Citrix and Other VDI Environments Using PowerShell Scripts
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...
Read the entire article here...