When configuring alerts in ControlUp based on device tags, a frequent question arises regarding whether selecting multiple device tags in the alert conditions operates as an OR or AND logic. It was clarified that in the current ControlUp alert configuration interface, when multiple device tags are selected, the alert triggers if the device has any one of the specified tags. This means the condition acts as a logical OR between the tags rather than an AND.
The user interface presents these tag selections as checkboxes, limiting the direct ability to express compound AND logic (such as requiring both tags to be present simultaneously). There is no built-in switch or toggle to explicitly select AND versus OR behavior for device tag conditions. While the idea of combining tags using expressions like "tag1&&tag2" was discussed, this is not supported directly within the tag selection box, and typing such expressions does not function as a filter in the UI.
However, a workaround approach involves leveraging multiple alert conditions, which are inherently ANDed together by ControlUp. For instance, instead of trying to combine two tags in one condition, you can create two separate conditions that must both be true, effectively achieving an AND between device tag criteria. Since tags are treated as string fields in the system, operators such as "contains" or "=" can be used in these conditions. Using "contains" is useful but may lead to partial matches, which requires careful tag naming conventions to avoid unintended matches (e.g., "reboot_device" matching both "reboot_device" and "no_reboot_device").
To address this, users have adapted by modifying their tagging strategies to use more distinctive and unambiguous tag names like "device_reboot_yes" and "device_reboot_no," which helps ensure that the use of "contains" or equality checks does not overlap between conflicting tags. Some users also explored adding exclusion conditions (e.g., conditions that exclude devices with certain tags), but these might not cover all scenarios adequately.
The community suggested it would be valuable for ControlUp to enhance alert configuration with explicit AND/OR toggles or support for string operations like "starts with" to improve flexibility for tag-based alerting. Meanwhile, using multiple conditions combined with clear tag naming conventions is the recommended practical approach for achieving AND logic with device tags in alerts.
For more detailed information on alert condition configuration and tag-based filtering, refer to the official ControlUp documentation at https://docs.controlup.com. This includes guidance on condition operators, tag management, and best practices for alert configurations.
Read the entire article here...
ControlUp Community Training & Support Archives
All training and support-related archives from inside the ControlUp Community on Slack.
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...
Enabling FSLogix Metrics on ControlUp Dashboards Using Real-Time Data and Upcoming API Enhancements
ControlUp users have inquired about displaying FSLogix metrics on the ControlUp Dashboard, but encountered the limitation that no predefined FSLogix metrics are currently available in the existing data scopes. This is because FSLogix real-time data is not currently included in ControlUp’s historical data sets, which underpin the dashboard's metric options and the public API. As a result, FSLogix metrics are not accessible through these channels at present.
ControlUp’s product management and development teams have confirmed that this situation is expected to change soon. There is an upcoming Real-time public API planned for release that will include FSLogix real-time data. This update will enable users to access FSLogix metrics on dashboards in real time, expanding the ability to monitor FSLogix environments directly within the ControlUp interface.
In parallel, ControlUp is also working on extending real-time data access for its AI Assistant functionality. Once implemented, this will allow users to generate dynamic visuals and analyses on FSLogix data using the AI Assistant, further enhancing real-time monitoring and troubleshooting capabilities related to FSLogix.
For now, users cannot directly add FSLogix metrics to dashboards due to the absence of these metrics in the historical data and public API. However, the forthcoming updates will bridge this gap, allowing seamless integration of FSLogix metrics into ControlUp’s real-time dashboards and AI-driven analytics. For further information on ControlUp dashboards and the evolving capabilities, users can refer to the official documentation at https://docs.controlup.com and the ControlUp Academy at https://cuacademy.controlup.com.
Read the entire article here...
Read the entire article here...
How to Monitor Hyper-V Hosts in ControlUp After Migrating from ESX
When transitioning from VMware ESX to a Hyper-V environment for Citrix, monitoring Hyper-V hosts through the ControlUp Management Console requires a different setup than for ESX hosts. Unlike ESX, which can be monitored directly once properly connected, Hyper-V monitoring in ControlUp necessitates deploying the ControlUp agent on each Hyper-V host. This agent installation allows ControlUp to gather detailed performance and health data from the Hyper-V hypervisors.
A common issue encountered during this transition is that ControlUp might mistakenly identify a few virtual machines as Hyper-V hosts instead of the actual hypervisor servers. This usually happens if the agents are not installed on the Hyper-V hosts themselves, or if the connection configuration is not correctly set up for Hyper-V clusters. Therefore, simply having the hypervisor hosts visible in the environment without the agent does not provide full monitoring capabilities.
To properly monitor Hyper-V clusters with ControlUp, administrators should follow the official guidance for connecting to Hyper-V hypervisors. The key step is to deploy the ControlUp agent on every Hyper-V host within the clusters. This enables comprehensive visibility into the hypervisor layer similar to what was available for ESX hosts. Detailed instructions and best practices for this process can be found in the ControlUp documentation at https://support.controlup.com/docs/connect-to-your-hypervisors#connect-a-hyperv-hypervisor.
In summary, migrating from ESX to Hyper-V environments requires deploying the ControlUp agent on Hyper-V hosts to achieve effective hypervisor monitoring. Proper identification of Hyper-V hosts and cluster setup within ControlUp hinges on this agent deployment, ensuring accurate and actionable insights for Citrix environments running on Hyper-V.
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...
Understanding and Managing Device Online Status Timeout in ControlUp
In a recent discussion regarding device status indicators within ControlUp, a user inquired about the possibility of customizing the timeout period that determines when a device’s online status changes from a green dot to gray after losing connection. Currently, the system shows a green dot for devices that have been contacted within the last 60 minutes. The user wanted to reduce this timeout to 10 minutes so that devices appear offline sooner after losing connection.
It was clarified by a ControlUp expert that the 60-minute window for displaying a device as online is a platform-level behavior that is hardcoded and currently not adjustable by tenants or administrators. The ControlUp agent operates on a fixed heartbeat cycle, and the online or offline status indicator is calculated server-side based on this fixed threshold. As such, there is no existing setting within the Extended Settings or any other configuration that allows users to shorten this timeout period.
Since this timeout value is not configurable via the UI or Extended Settings, changing it would require a formal feature request to ControlUp’s development team. For now, the 60-minute heartbeat interval remains the standard for determining online device status, and users must expect the green dot to persist for up to one hour after the last successful contact. This behavior is consistent and reliable to avoid fluctuating device statuses due to shorter network interruptions.
For more detailed information on ControlUp agent heartbeat and device status indicators, users can consult the ControlUp documentation and knowledge base at https://docs.controlup.com or explore related training resources on the ControlUp Academy at https://cuacademy.controlup.com.
Read the entire article here...
Read the entire article here...
Status and Options for Ivanti Neurons ITSM Integration with ControlUp
ControlUp currently offers a native, first-party integration exclusively with ServiceNow for IT service management (ITSM) purposes. This integration provides advanced functionality beyond typical ticket creation: it can update an originally created ticket automatically if the same issue recurs, close the ticket when the issue resolves, and reopen it if the problem reappears, based on configurable recurrence and timing settings. Additionally, this ServiceNow integration is embedded directly into the device overview and specific device details user interface within ControlUp, providing seamless operational visibility.
Other ITSM systems are supported primarily through ControlUp Workflows, which offer integration capabilities with several platforms including Jira Service Desk, Freshservice, Zendesk, TOPdesk, and Halo ITSM, using broad REST-based connectivity. ManageEngine ServiceDesk Plus and its on-premises version also have integration options available behind feature flags. While Jira is integrated for workflows, it does not yet have a native ControlUp integration matching ServiceNow’s level of direct functionality.
Regarding Ivanti Neurons ITSM, there is currently no native or first-party integration with ControlUp. No active development plans or timelines have been announced for such an integration. Ivanti Neurons is also not included in the existing set of ITSM connectors available in ControlUp Workflows. However, users interested in integrating Ivanti Neurons can leverage the Workflows platform’s custom integration feature, which allows interaction with Ivanti’s REST API to build tailored solutions fitting organizational needs. Although this requires some configuration effort, it is the recommended alternative until an official integration is developed.
The ControlUp team has acknowledged requests for additional native ITSM integrations beyond ServiceNow, including Ivanti Neurons and Jira, and has indicated these will be considered for future roadmap development. However, no estimated time of arrival (ETA) is provided at this stage. For now, leveraging the robust Workflows engine with available connectors and custom API integrations offers the best path forward for integrating ITSM systems other than ServiceNow.
For detailed guidance on configuring Workflows, custom integrations, and the native ServiceNow integration, users can refer to ControlUp’s official documentation at https://docs.controlup.com and the ControlUp Academy at https://cuacademy.controlup.com.
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...
Troubleshooting AI Query Errors for Connection Failure Metrics and Using ControlUp Dashboards as an Alternative
A user encountered difficulties querying connection failure data within a specified time range using the ControlUp AI assistant. Despite attempting a straightforward query to count connection failures during a certain period, the AI repeatedly generated errors instead of delivering the requested information. This issue highlighted limitations or temporary glitches in the AI interface for composing complex filter criteria involving time intervals.
Upon reporting the problem to the ControlUp support team, it was acknowledged as potentially related to recent network issues, which may have contributed to the AI malfunction on the previous day. The team requested formal feedback submission to investigate the problem further and verify if it could be reliably reproduced under similar conditions.
In the meantime, a practical alternative was suggested from within the community: a pre-built Citrix connection failures dashboard created by a peer user. This dashboard presents connection failure metrics in an organized and visually accessible format, allowing administrators to monitor relevant data without relying solely on raw AI-driven queries. Such dashboards provide easier insights into connection issues and can be a more reliable solution for identifying failure trends over time.
For users experiencing similar problems with AI query errors related to connection failure data, exploring the ControlUp dashboard options is recommended as an effective workaround. Additionally, reporting such AI issues to ControlUp support ensures ongoing improvement of AI capabilities for querying monitoring data. More information on creating and customizing monitoring dashboards can be found in the ControlUp Knowledge Base at https://docs.controlup.com and tutorials at the ControlUp Academy https://cuacademy.controlup.com.
Read the entire article here...
Read the entire article here...
How to Report Horizon Client Versions Across User Sessions Using ControlUp
A common requirement for managing VMware Horizon environments is the ability to report on the endpoint client versions—referred to as "HZ Client Version"—used by users to connect to the Horizon infrastructure. This need becomes particularly important in hybrid environments where users connect from both managed internal devices and unmanaged BYOD (Bring Your Own Device) endpoints. Tracking client versions helps administrators identify devices running outdated Horizon clients that require upgrades to ensure security, compatibility, and optimal performance.
Within ControlUp, the Horizon client version information can be accessed via several mechanisms. The VDI - Details view in the ControlUp console displays the HZ Client Version associated with each session, providing a straightforward way to see the current client version used. For programmatic or historical data extraction needs, ControlUp also offers a real-time data API (https://api.controlup.io/reference/gettables) which can retrieve live session details including client versions. Additionally, the "initial HZ client version" field recorded in the Session Activity report captures the client version that was used to start the session. This field, although labeled as "initial," effectively serves as a snapshot of the client version at session start.
However, because users in hybrid scenarios may connect multiple times throughout the week from different devices or update their Horizon client between sessions (for example, by disconnecting, updating, and reconnecting), it is important to consider that the client version can vary across sessions. The "initial HZ client version" is tied to each individual session start, so accumulating this information over a period allows administrators to identify all versions in use and target users on outdated clients. Pulling session activity reports over time and correlating the client versions used enables identification of BYOD devices needing updates even if the same user connects from multiple endpoints.
In summary, the "initial HZ client version" contained in ControlUp’s Session Activity reports is the key field for tracking Horizon client versions across user sessions. The ControlUp real-time data API further facilitates custom querying and automation for this reporting. For detailed exploration of session data, the VDI - Details view complements these options with an at-a-glance interface. Using these tools, administrators in hybrid environments are able to efficiently monitor and manage Horizon client versions on both managed and BYOD devices, ensuring compliance and performance consistency.
Read the entire article here...
Read the entire article here...
