---
title: "Connection Manager groups"
product: "Guardian"
edition: "Classic"
url: "https://docs.cloudhouse.com/guardian/classic/inventory/monitored/connection-manager-group/connection-manager-groups/"
---
---
title: "Connection Manager groups"
description: "Organise Connection Managers into groups and assign nodes to them."
type: overview
read_time: 7
anchor_aliases:
  'Default: custom-default-groups
  AssignNodestoaConnectionManagerGroup: assign-nodes-to-a-connection-manager-group
  Changing: assign-nodes-to-a-connection-manager-group
  CustomDefaultGroups: custom-default-groups
  NetworkAccess: network-access
  Permissions: permissions
  UseCasesandBestPractice: use-cases-and-best-practice
---

# Connection Manager groups

Organise Connection Managers into groups and assign nodes to them. For example, you could group your Connection Managers according to network topologies, time zones, or any other organisational property. The **Connection Manager Groups** drop-down menu on the **Monitored** tab (**Inventory** > **Monitored**) displays each of the Connection Manager groups that are actively scanning nodes within your Guardian instance. Here, you can view, edit, and configure each of the nodes within those groups. For more information on Connection Managers, see [Connection Managers](https://docs.cloudhouse.com/guardian/classic/inventory/connection-managers/connection-managers/index.md).

Applies to: `Guardian Classic`

!!! note

    Each Connection Manager group should only contain one type of Connection Manager; either all Windows or all Linux.

![Cm groups1](https://docs.cloudhouse.com/guardian/classic/assets/images/guardian/inventory/monitored/cm-groups/cm-groups1.png)

!!! note

    The search functionality for Connection Manager Groups was introduced in V3.57.0 of the Guardian web application. For more information, see [July 2025 Quarterly Release](https://docs.cloudhouse.com/guardian/classic/what-s-new/2-previous-release/2025/quarterly/q3/july-2025/index.md). To enable this feature, contact your Cloudhouse Representative.

Whilst similar to [Environments](https://docs.cloudhouse.com/guardian/classic/inventory/monitored/environments/environments/index.md) due to their organisational properties, Connection Manager groups are not assets that are being scanned, rather, they are the service that is responsible for scanning your assets. For more information on the services available for scanning nodes, see [Agent-Based or Agentless?](https://docs.cloudhouse.com/guardian/classic/getting-started/agent-based-or-agentless/index.md) Unlike [Node Groups](https://docs.cloudhouse.com/guardian/classic/inventory/monitored/node-groups/node-groups/index.md), you cannot add nodes to a Connection Manager group from within the **Monitored** tab, you must configure the Connection Manager group that is responsible for scanning each node within the individual node's settings. For more information, see [Assign Nodes to a Connection Manager Group](#assign-nodes-to-a-connection-manager-group).

When adding a new node, individually or in bulk, you are required to define which Connection Manager group is responsible for scanning that node. Likewise, when registering a Connection Manager to your Guardian appliance, you are required to provide a [Group API Key](https://docs.cloudhouse.com/guardian/classic/inventory/connection-managers/connection-managers/actions/group-api-key/index.md). As such, you should create your Connection Manager groups in advance of setting up your Connection Managers. This helps to distribute network traffic across your Connection Managers. For more information on use cases and best practice for setting up your Connection Manager groups, see below. For more information on how to add a Connection Manager group, see [Add Connection Manager Group](https://docs.cloudhouse.com/guardian/classic/inventory/monitored/connection-manager-group/add-connection-manager-group/index.md).

## Custom / default groups

A custom Connection Manager group is a group that has been manually created in the **Connection Managers** tab (**Inventory** > **Connection Managers**). Custom groups typically have several Connection Managers assigned via the group's unique API Key during the registration phase. Or, alternatively, you could add a new API key to an existing Connection Manager's config file to change the assigned group at any time. Such groups are unique to the organisation they were created in. If you created a 'US-WEST' Connection Manager group in your QA organisation, you would not be able to view or access it from your DEV organisation, for example. This structure prevents any duplicate node scans occurring between one organisation and another. For more information on organisations, see [Organisation Accounts](https://docs.cloudhouse.com/guardian/classic/account/organizations/organizations/index.md).

!!! tip

    Whereas the **Connection Manager Groups** drop-down menu is the location for accessing all of the nodes that are being scanned by each Connection Manager group, the **Connection Managers** tab is the location for accessing individual Connection Managers and organising them into groups. For more information, see [Connection Managers](https://docs.cloudhouse.com/guardian/classic/inventory/connection-managers/connection-managers/index.md).

In contrast, there is only one 'Default' Connection Manager group, which only contains one Connection Manager. The built-in **Linux** Connection Manager. This service is available for all users, with the capacity to scan up to 100 nodes, which is particularly useful for users with a small amount of non-Windows nodes as you are not required to satellite deploy a Linux Connection Manager. You can, instead, rely on the built-in Linux Connection Manager to scan your non-Windows nodes via SSH. You cannot, however, add new Connection Managers to the group, or edit the existing Connection Manager. The 'Default' Connection Manager group is also not tied to a specific organisation, it scans any SSH nodes that are assigned to it regardless of the organisation.

!!! note

    If your Windows nodes are automatically assigned to the 'Default' Connection Manager group due to a lack of alternatives, it may be sensible to create a Windows Connection Manager group with multiple Connection Managers, and then re-assign your Windows nodes to the correct group. Any non-SSH nodes will not be eligible for scanning via the 'Default' Connection Manager group.

## Use cases and best practice

When Guardian receives a request to scan an Agentless node it checks what Connection Manager group it is assigned to first. This is because Connection Managers within the same group share the load for node scans, integrations syncs, etc. However, that load is not distributed between each group within Guardian and so Connection Manager groups can be especially useful to segregate your network and ensure load management. The following section describes two use cases for organising your Connection Manager groups; according to network access or permissions, as well as some best practice advice.

![](../../../assets/images/guardian/inventory/monitored/cm-groups/scan-nodes2.png "The 'Default' Connection Manager Group is displayed. The checkboxes of two nodes have been selected and the Scan Nodes button is displayed.")

The way that you choose to organise your Connection Managers depends on how you want to configure your estate. The only rule for configuring your Connection Manager groups is that they can only contain **one type** of Connection Manager. Meaning that there should be groups of Windows Connection Managers responsible for scanning WinRM nodes and groups of Linux Connection Managers responsible for scanning SSH nodes, in whatever organisational structure you choose to use. You cannot, however, have a Connection Manager group with both Windows and Linux Connection Managers. Whatever way you choose to organise your Connection Manager groups, there are ways to optimise the efficiency and balance the load.

### Network access

The most common way of organising Connection Manager groups is according to the level of network access permitted to your node set. For example, if you organised your Guardian instance to match your own infrastructure with 'DEV', 'UAT, and 'PROD' [Environments](https://docs.cloudhouse.com/guardian/classic/inventory/monitored/environments/environments/index.md), the nodes within the 'DEV' environment would not be able to access the nodes within the 'PROD' environment, and vice versa. As such, you could create corresponding 'DEV', 'UAT, and 'PROD' Connection Manager groups that are responsible for scanning the Agentless nodes within those environments. Then, to optimise the scan times of nodes within those groups, you could have a low-powered Connection Manager within the 'DEV' group and a high-powered Connection Manager within the 'PROD' group to handle the different levels of network traffic typically attributed to those environments. Or, as many Connection Managers as required to cover the load for each group.

!!! note

    Other areas that may be impacted by network restrictions include; geographic regions, cloud regions within AWS or Azure, or DMZ networks. To handle these restrictions, you can create a corresponding Connection Manager group responsible for scanning those areas.

![](../../../assets/images/guardian/inventory/monitored/cm-groups/cm-groups-dv-qa1.png "The Connection Manager Groups drop-down menu is displayed with a red border. The Connection Manager Groups display as follows: 'Default', 'DEV', 'QA', and 'PROD'.")

### Permissions

In some scenarios, you may need a specific user account to access certain nodes. To handle this scenario, you can create a Connection Manager group with Connection Managers that are all using the required user account credentials. Then, assign the nodes that require the elevated permission set to be scanned.

![](../../../assets/images/guardian/inventory/monitored/cm-groups/connection2.png "The Connection Manager Groups drop-down menu is displayed with a red border. The Connection Manager Groups display as follows: 'Default', 'AWD', 'Azure', 'Linux', and 'Windows'.")

Essentially, there is no 'wrong' way to organise your Connection Managers. As described above, there are several use cases for organising according to necessity; dealing with network and permission restrictions. But you can organise your groups according to any number of defining criteria, such as region, or connection type.

## Assign nodes to a Connection Manager group

Once you have set up your Connection Manager groups and added the required Connection Managers, you can begin assigning nodes to your groups. The easiest way to add nodes to a Connection Manager group is during the creation stage, however you can edit a node's settings manually from within the **Monitored** tab in order to re-assign them to a new Connection Manager group. If you have just set up multiple groups after using the 'Default' Connection Manager group, you may need to re-assign multiple nodes at a time. This can be achieved using the built-in [Multi-Select Functionality](https://docs.cloudhouse.com/guardian/classic/inventory/monitored/monitored/index.md#multi-select-functionality).

!!! note

    For more information on how to assign a Connection Manager to a Connection Manager group, see [Group API Key](https://docs.cloudhouse.com/guardian/classic/inventory/connection-managers/connection-managers/actions/group-api-key/index.md).

To manually assign nodes to a Connection Manager group, complete the following steps:

1. In the **Monitored** tab, select the checkbox for the node(s) that you want to assign to a different Connection Manager group.

    !!! note

        You can select a node from any of the drop-down menus in the **Monitored** tab. For example, **Node Groups** or **Environments**.

    ![](../../../assets/images/guardian/inventory/monitored/cm-groups/monitored-env-select-nodes.png "The 'All Nodes' node group is displayed. The checkboxes of two nodes have been selected.")

2. Click the **Diff X Nodes** drop-down, then select **Edit X Nodes** from the list of options. The **Edit X Nodes** page is displayed.

    ![](../../../assets/images/guardian/inventory/monitored/cm-groups/monitored-env-edit-nodes.png "The Diff 2 Nodes drop-down has been selected, a list of options are displayed. The Edit 2 Nodes option has a red border around it.")

3. Select a new Connection Manager group from the **Connection manager group** drop-down list.

    !!! tip

        If the fields are blank, or the **Connection manager group** option isn't displayed, this indicates that the configuration is very different between the two selected nodes. Make sure to only apply settings to nodes of a similar criteria. For example, don't add Linux nodes to a Windows Connection Manager group, as they won't be eligible for scanning.

    ![](../../../assets/images/guardian/inventory/monitored/cm-groups/edit-two-nodes-cm-group.png "The Edit 2 Nodes page is displayed. The Connection manager group drop-down list has a red border around it.")

4. Then, click the **Update Nodes** button to save your changes.

Once complete, the node is assigned to, and displayed within, the new Connection Manager group. For more information on the additional fields displayed within the **Edit Node** page, see [Edit Node](https://docs.cloudhouse.com/guardian/classic/inventory/add-nodes/edit-node/index.md).
