When writing records to a custom ControlUp Edge data index via the REST API (POST to edge/api/data/), users may encounter an issue where repeated writes of the same record result in duplicate entries rather than updates to existing records. Additionally, there is a desire to prevent these records from expiring after the default 28 days of inactivity. This discussion sheds light on both the mechanics of record updating and the association of records with the endpoint running the write operation.
The key to controlling whether a record is created anew or updated lies in the uniqueness of the "key" field or primary identifier used in the data index schema. When writing data via a PowerShell script—whether executed inside ControlUp or externally—the operation will create a new record if the key value is not recognized. To update an existing record, the key must remain consistent and the write must explicitly target that key. The official ControlUp scripting guide provides useful guidance for writing data to an index, outlining how to structure the payload and use keys: https://support.controlup.com/docs/scripting-guide#writing-to-a-data-index. Running the script inside ControlUp offers the advantage of on-demand execution with local file availability, but it is not strictly necessary; scripts can also run externally.
A practical complication arises from the fact that data written to the index often becomes associated with the endpoint where the script executes, as seen when the computer name appears linked to each record. This behavior stems from ControlUp’s design, where data sources are tied to machine endpoints to facilitate monitoring and troubleshooting. In scenarios where building information needs to be stored independently of endpoint context, some organizations have implemented custom solutions such as storing building data locally on endpoints (e.g., in registry or Active Directory properties), then running scripts on each endpoint to gather and send this data to ControlUp. While this approach inherently associates data with those endpoints, it maintains up-to-date building information across the environment.
Controlling record expiration beyond the default 28 days typically requires adjusting settings on the data index or implementing regular writes to keep the record active. Without ongoing updates, ControlUp’s retention policy will remove inactive records. Users are also encouraged to explore ControlUp Workflows for automating data collection and writing processes, which can streamline operations despite a learning curve. The ControlUp support team and community forums remain valuable resources for addressing specific scripting and data index challenges.
For additional details and sample scripts, the ControlUp scripting guide is recommended: https://support.controlup.com/docs/scripting-guide#writing-to-a-data-index.
Read the entire article here...
ControlUp Community Training & Support Archives
All training and support-related archives from inside the ControlUp Community on Slack.
Understanding Real-Time Access and Limitations of the TCP Connections Table in ControlUp
The TCP Connections table found under the Network Tab in ControlUp is accessible exclusively as a real-time data source. There is no indexed or historical storage of this table's data within ControlUp's platform. This means that the TCP Connections information is gathered and displayed dynamically at the moment of the query, providing a current snapshot of network connections, but it is not archived for later analysis or retrieval.
Users seeking to analyze TCP connection trends or historical network session data over a period would need to use alternative monitoring or logging tools designed for data retention and historical reporting. ControlUp focuses on real-time performance monitoring and diagnostics, and the design decision for the TCP Connections table reflects this emphasis.
For detailed information on what network-related metrics ControlUp captures and how to leverage them in troubleshooting or performance analysis, the ControlUp documentation and knowledge base offer comprehensive guidance at https://docs.controlup.com. Additionally, exploring ControlUp Academy at https://cuacademy.controlup.com can provide training on optimizing network monitoring within the ControlUp environment.
Read the entire article here...
Read the entire article here...
Support for Boolean Fields in ControlUp Indexes via PowerShell Scripts
A community member inquired about the official support for Boolean columns in ControlUp when written to via a PowerShell script. They noted that their script was functioning as expected, showing a dropdown with options for "true" and "false" instead of a plain text box for the Boolean field. This behavior indicates that Boolean fields are recognized and handled appropriately within the ControlUp system's indexing and UI.
The confirmation came from multiple users, including a ControlUp expert, that Boolean fields are indeed supported. ControlUp's platform supports defining columns with Boolean data types, enabling users to interact with these fields through dropdown selectors for true/false values, which enhances data consistency and ease of use.
This means that scripts or automation workflows that write Boolean values into ControlUp indexes can rely on native support for true/false states. This feature is useful for scenarios where binary states need to be tracked and toggled directly from the ControlUp interface without requiring manual text input.
For more detailed information on supported data types and scripting integration with ControlUp indexes, users can refer to the official ControlUp documentation at https://docs.controlup.com, and consider the ControlUp Academy (https://cuacademy.controlup.com) for deeper learning resources on scripting and data management in ControlUp.
Read the entire article here...
Read the entire article here...
How to Identify and Manage Duplicate Devices in ControlUp Desktops Due to Reimaging and Agent Re-registration
A common challenge with ControlUp's Desktops product arises when IT teams test new device models by repeatedly reimaging machines, causing multiple instances of the same device to register with unique device IDs but identical hostnames. This scenario leads to an inflated license count, as each registration consumes a license until the devices are flagged inactive and subsequently removed from the system.
To identify these "duplicate" devices, one effective method involves querying the ControlUp `device_status` data index. While leveraging ControlUp Dashboards can help visualize this data, caution is advised when running queries based solely on device IDs without applying appropriate filters to avoid misleading results. Advanced options in the dashboard allow adding additional metrics that can pinpoint such duplicates by hostname or device name, which is particularly helpful since the root issue is not duplicate device IDs but duplicate device names retained after reimaging.
In practice, customizing dashboard widgets with additional filters and metrics can enable teams to monitor and isolate devices that have been repeatedly reimaged and registered, streamlining license management. For devices already deployed, it is possible to run a script that forces re-registration of devices with a new unique ID to prevent license count inflation. This step may be beneficial where device IDs need to be refreshed or reset in the ControlUp environment.
Another important factor involves deployment parameters. For example, the `REGISTERWITHNAME=1` flag, if set during agent deployment, can cause devices to register under the same name, exacerbating duplicate name issues. However, in many cases, the default setting with the `ALLUSERS=1` flag, used in ControlUp's standard installer from the Downloads pane, is sufficient and does not trigger duplicate registrations unless devices are repeatedly reimaged and reset by users.
Overall, the underlying cause of the inflated license usage is the repeated device reimaging and agent re-registration under the same hostname but with unique IDs. Proper use of the `device_status` index for querying, cautious dashboard configurations, potential scripting to reset device IDs, and awareness of deployment flags can effectively manage and mitigate "duplicate" device issues within the ControlUp Desktops product.
Read the entire article here...
Read the entire article here...
How to Configure AND vs OR Logic with Device Tags in ControlUp Alerts
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...
Read the entire article here...
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...