--- title: "June 2025 monthly release" description: "What changed in Guardian Classic in the June 2025 monthly release." product: "Guardian" edition: "Classic" type: "reference" url: "https://docs.cloudhouse.com/guardian/classic/what-s-new/2-previous-release/2025/monthly/june-2025/" --- # June 2025 monthly release For help upgrading to the latest version, contact your Cloudhouse Representative. The following table describes each component available to upgrade within this release of Guardian. For more information on the known issues currently present within Guardian, see [Known Issues](https://docs.cloudhouse.com/guardian/classic/known-issues/known-issues/index.md). Applies to: `Guardian Classic` !!! tip To access a more simplified view of the changes included within this release, see [June 2025 Changelog.pdf](https://docs.cloudhouse.com/guardian/classic/assets/files/guardian/what-s-new/2-previous-release/2025/changelog/june-2025-changelog.pdf). | Release Date | Guardian Platform | Guardian Web | Windows Agent | | --- | --- | --- | --- | | 25th June 2025 | V4 | V3.56.0 | V5.20.0 | ## Guardian web application v3.56.0 Here's what's included in V3.56.0 of the Guardian web application as part of the June 2025 monthly release. ### New features The following new features are included within this release of the Guardian web application. #### Reactivate a deleted node As part of our continuous efforts to improve Guardian's usability, we have introduced the ability to reactivate a previously deleted node. In the **Events** tab (**Control** > **Events**), we have added a new `node_id` field in the event details panel. This field is only displayed for node-related events (it won't display for an 'Environment Scan' event, for example) and links to the node related to the event. ![Node deleted event](https://docs.cloudhouse.com/guardian/classic/assets/images/guardian/whats-new/2025/june/node-deleted-event.png) When a node is deleted, a 'Node Deleted' event is logged and you can now use the `node_id` to access the deleted node. Click the `node_id` field to display the results of the deleted node's most recent scan. ![Reactivate](https://docs.cloudhouse.com/guardian/classic/assets/images/guardian/whats-new/2025/june/reactivate.png) Click the **Reactivate** button to re-add the node to your Guardian instance. There is no limit on how long you can wait to reactivate a node. Any previously applied policies, scheduled jobs, etc. are automatically reinstated, alongside any scan data. For more information, see [Reactivate Deleted Node](https://docs.cloudhouse.com/guardian/classic/inventory/add-nodes/reactivate-deleted-node/index.md). !!! tip The `node_id` field was added to every 'Node Deleted' event as part of this release, however, you can reactivate a node that was deleted prior to V3.56.0 by sourcing the `node_id` from a 'Node Updated' event in lieu. #### New appliance health stats PDF (Admin only) If you have a user account with the 'Admin' role you can now access information about your Guardian appliance's health stats. Simply navigate to the **Settings** page (**Account > Settings**) and click the new **Health Stats** button to display the **Appliance Health Stats** PDF. Here, you can access data regarding your appliance's general health, disk usage, and so on. ![Health stats](https://docs.cloudhouse.com/guardian/classic/assets/images/guardian/whats-new/2025/june/health-stats.png) ### Other enhancements The following additional enhancements are included within this release of the Guardian web application. #### Greater visibility when editing multiple nodes We have made updates to the **Edit Nodes** page that is displayed when editing two or more individual nodes, or the nodes contained within a group, for example. The aim of this development is to provide greater visibility on what fields are being changed during an edit, how many nodes are impacted by the change, and to remove any redundant functionality. **To edit nodes within a group, complete the following steps**: 1. In the **Monitored** tab (**Inventory** > **Monitored**), select the node group that you want to edit from the **Node Groups** drop-down menu. ![Monitored tab](https://docs.cloudhouse.com/guardian/classic/assets/images/guardian/inventory/monitored/node-groups/edit-node-group/monitored-tab.png) 2. Click the **Diff This Group** drop-down and select **Edit Nodes In Group**. The **Edit Nodes in Node Group [name]** page is displayed. !!! tip Additionally, you can use the multi-select check box functionality to select any individual nodes within that group to edit, rather than all the nodes within that group. ![Edit nodes in group drop down](https://docs.cloudhouse.com/guardian/classic/assets/images/guardian/whats-new/2025/june/edit-nodes-in-group-drop-down.png) 3. The fields displayed here depend on the types of nodes contained within the group. Edit the values as required and click to **Save** any changes. For more information, see below. Now, when editing the values on the **Edit Nodes** page, an **Unsaved Changes** icon (![Pencil](https://docs.cloudhouse.com/guardian/classic/assets/images/guardian/buttons/pencil.png)) is displayed, until you click to **Save** your changes. ![Edit nodes in group 2](https://docs.cloudhouse.com/guardian/classic/assets/images/guardian/whats-new/2025/june/edit-nodes-in-group-2.png) Additionally, if you have different settings applied on different nodes, the following text is displayed within the corresponding field: 'Multiple values detected'. If you edit the value within the field and save it, those changes are applied to all nodes within the group. ![Edit nodes in group 1](https://docs.cloudhouse.com/guardian/classic/assets/images/guardian/whats-new/2025/june/edit-nodes-in-group-1.png) Additionally, to reduce the potential for causing configurational breakages, we have removed the following options from the **Edit Nodes** page: - **Hostname/IP Address** field – This field value is specific to each individual node, and not relevant during a bulk edit. - **Operating System Family** drop-down list – This option is no longer displayed if the selected nodes do not have the same OS family. Instead, you can edit the **Environment** field only. #### Improvements to job history tab and CSV file In the **Job History** tab (**Control** > **Job History**), you can use the drop-down options to filter the results displayed in the **Job History** table and view a customised list of jobs that have been run in Guardian. We have introduced new functionality to the Guardian web application that allows you to filter by multiple columns at a time, rather than only one at a time. Additionally, you can now refresh the page and have your filters remain, without needing to re-apply them. !!! note For more information on the **Job History** tab, see [Job History](https://docs.cloudhouse.com/guardian/classic/control/job-history/job-history/index.md). ![Job histort tab](https://docs.cloudhouse.com/guardian/classic/assets/images/guardian/whats-new/2025/june/job-histort-tab.png) Prior to this update, the **Updated At** column was only available to use and filter by within the Guardian web application. Now, if you click to **Download as CSV File**, the **Updated At** column is also displayed within the CSV file to provide greater insight into which jobs are taking longer to run within a flat file format. We have also increased the number of records able to be exported within a CSV file from 20 to 1000 to better align the CSV file output with the Guardian web application. ![Updated at](https://docs.cloudhouse.com/guardian/classic/assets/images/guardian/whats-new/2025/june/updated-at.png) Additionally, we have fixed an issue occurring when trying to export a filtered view of job runs within a CSV file. When filtering the **Job History** table according to job type or status, for example, exporting that data as a CSV file now displays the correctly filtered results. #### Unix Connection Manager OVA: Deprecated This release contains the **final version** of the Unix Connection Manager OVA, **V5.43.0**. As of this release, the OVA Connection Manager will no longer automatically update, as it has been deprecated and removed from the [Guardian Application Downloads](https://download.cloudhouse.com/) page. !!! tip If you wish to continue receiving updates, we advise you to install the alternative Linux Connection Manager that is available. For more information, see [Linux Connection Manager – Installable](https://docs.cloudhouse.com/guardian/classic/inventory/connection-managers/connection-managers/linux/linux-installable-connection-manager/index.md). #### Guardian upgrade efficiency improvements We have improved the efficiency of the Guardian upgrade process by implementing a more orderly system startup, effectively reducing the need for manual intervention. #### Extra transaction logging We have added extra debug logging around transactions to aid diagnosing possible system performance issues. #### Database Server improvements We have completed various database server improvements as part of our efficiency initiative, by freeing up disk space and improving the time required to insert rows into various tables. ### Fixed issues The following issues have been fixed within this release of the Guardian web application. **Affects Versions**: V3.50.0 : **Fix Version**: V3.56.0 **Problem** : If the credentials feature was enabled and you had configured a node to use a set of stored credentials, when editing that node, the **Enable Secondary Password** field was being incorrectly displayed. !!! tip When creating a credential, a secondary password is added. The Enable Secondary Password field should only be visible when editing the associated credential, not for a node using those credentials. For more information on credentials, see [Credentials](https://docs.cloudhouse.com/guardian/classic/inventory/credentials/credentials/index.md). **Solution** : We have removed the **Enable Secondary Password** field from the **Edit Node** page. Now, when editing a node with stored credentials, the **Secondary Password** field is not displayed. You can only edit that value from within the associated credential, as expected. **Affects Versions**: V3.55.0 : **Fix Version**: V3.56.0 **Problem** : When editing a node's settings, regardless of the credentials that were previously set on the node, the credentials stored on the node were being displayed as the 'SSH Key'. If you were to **Save** the changes, the actual credentials that were stored on the node would be overwritten. !!! note This issue was occurring regardless of whether the credentials feature was enabled. **Solution** : When a node's settings are edited, if the connection type is changed, the new value is stored correctly within the back end database. Now, you can change the credential type for any node and have the value save between edits, as expected. ![Cred types](https://docs.cloudhouse.com/guardian/classic/assets/images/guardian/whats-new/2025/june/bugs/cred-types.png) **Affects Versions**: V3.55.0 : **Fix Version**: V3.56.0 **Problem** : If a Guardian action was configured to delete a node when triggered by a specific event, the node was being deleted but a 'Node Deleted' event was not being generated within the **Events** tab. For example, if you had an action configured to delete any nodes that failed to scan five times, Guardian would automatically delete any nodes that met that criteria. However, nodes were being deleted and not recorded within the **Events** tab, resulting in a lack of visibility of node churn. !!! note This bug was only occurring with the 'Perform a Guardian action' type, not your standard integration-based actions. For more information on event actions, see [Actions](https://docs.cloudhouse.com/guardian/classic/control/events/actions/actions/index.md). **Solution** : We have updated the code in the Guardian database to account for this scenario. Now, when a Guardian action is configured to delete a node when triggered by a specific event, any nodes that meet the stipulated criteria are deleted and a 'Node Deleted' event is generated for each node and displayed within the **Events** tab. ![Node deleted event](https://docs.cloudhouse.com/guardian/classic/assets/images/guardian/whats-new/2025/june/bugs/node-deleted-event.png) ## Windows Agent v5.20.0 Here's what's included in V5.20.0 of the Windows Agent as part of the June 2025 monthly release. ### New features The following new feature is included within this release of the Windows Agent. #### Log level configuration When installing the Windows Agent, you can now configure the default log level to provide more or less information for troubleshooting purposes. On the **Connection Manager Registration** screen, the new **Default Log Level** drop-down list is displayed. For more information on this installation method, see [Windows Connection Manager – Installer](https://docs.cloudhouse.com/guardian/classic/inventory/connection-managers/connection-managers/windows/windows-connection-manager-installer/index.md). !!! tip Alternatively, the default log level can also be set during a command line installation using the `--log_level` parameter. For more information, see [Windows Connection Manager – Command Line Installation](https://docs.cloudhouse.com/guardian/classic/inventory/connection-managers/connection-managers/windows/windows-connection-manager-command-line/index.md). ![Log level](https://docs.cloudhouse.com/guardian/classic/assets/images/guardian/whats-new/2025/june/log-level.png) Here, you can set the log level to one of the following settings: - 'Info' (Default) – This is the recommended setting. Provides basic logging information. - 'Debug' – Provides more detailed logging information. - 'Warning' – Displays logs warnings only. !!! note To set the log level to 'Warning' for the [Windows Connection Manager – Command Line Installation](https://docs.cloudhouse.com/guardian/classic/inventory/connection-managers/connection-managers/windows/windows-connection-manager-command-line/index.md) use `warn`. Upon installation, the default log level is saved to the config file and the logs are now stored in the Guardian D log. By setting the log level during installation, the configuration remains consistent. The log level setting will persist even after reinstalling the software. ### Other enhancements The following additional enhancement is included within this release of the Windows Agent. #### Guardian endpoint efficiency We have centralised the Guardian endpoint function to improve efficiency, by ensuring a consistent 10-second wait between calls. This prevents the system from making calls at unpredictable intervals, enhancing overall performance.