Working with management groups

About management groups

Management groups provide a powerful mechanism for cleanly partitioning and classifying devices within an estate. Management groups are associated with one or more rules (not to be confused with the 1E Platform's Endpoint Automation rules) that define the criteria for group membership. For example, you could define a management group whose membership rule was that all devices whose FQDN contained a particular string would be members of the group.

Version 8 of the 1E Platform has introduced changes to the way management groups work. Although in most cases the broad concepts are similar, there are some important differences. Refer to Management group changes in version 8 of the 1E Platform.

Management group types

There are two types of management groups:

  • Rule-based groups have their device membership defined through rules. A rule consists of an expression which can refer to one or more attributes.
  • Direct-based groups have their device membership defined as an explicit list of devices.

Refer to Rule-based and direct-based management groups.

Management Group Safeguarding

Management Group Safeguarding is a feature that was introduced in version 24.5 of the 1E Platform. Management Group Safeguarding allows groups to be created and membership evaluated but without these groups becoming active on the platform. Once you are confident that the rules or the direct-based membership list is correct, you can create normal management groups using these rules or membership lists.

The 1E PowerShell Toolkit provides functionality to support Management Group Safeguarding. Refer to Draft management groups.

Management groups and the SLA subsystem

The 1E Platform relies on the SLA subsystem for management group functionality. While versions prior to release 8 of the platform could be configured to be independent of SLA, this functionality is now deprecated. However, the platform keeps information on management groups internally and requires synchronization with the SLA subsystem in order to reconcile the SLA management groups with its internal set of groups.

Internally, the platform associates a simple set of device FQDNs with a management group. The SLA subsystem is responsible for dynamically evaluating the rules associated with its management groups and then updating this device list on the platform side. Devices that are matched by the rules are included in the list, and devices that fail to match are excluded.

Version 8 of the 1E Platform introduced direct-based management groups. These allow management groups to be defined by one or more FQDNs which make up the group membership, rather than a set of dynamic matching rules. This facilitates the synchronization of large device collections from external sources such as Microsoft Endpoint Configuration Manager. Refer to Direct-based management groups.

The 1E PowerShell Toolkit has a set of cmdlets to create and update SLA management groups and to manage the synchronization of SLA management groups with the platform. Refer to Instruction management cmdlets.

Getting started with management groups

After installation, the platform does not contain any pre-defined management groups. To create and verify groups using the 1E PowerShell Toolkit cmdlets in version 8 and later, refer to Understanding SLA management groups: A simple test scenario.

If you have issues running the connector sync during the above process, and these indicate licensing issues with the 1E-Inventory-* instructions, ensure that your platform license has a valid entry under the TachyonExplorer section which associates the 1E-Inventory prefix with a valid signer hash. If you are unsure of the correct value for this, you can use the export-instruction cmdlet to retrieve one of the inventory instructions, open it in Tachyon Instruction Management Studio (TIMS), and inspect its code signing certificate. The thumbprint value of that certificate is the hash required in the license entry. In the example below, the 1E-Inventory prefix is included in the TachyonExplorer feature along with the inventory consumer and specifies a certificate thumbprint beginning E9AD...., which corresponds to the certificate used to sign the 1E-Inventory instructions distributed with this version of the platform.

Note that these thumbprint values may change across releases if new certificates are used, so you should check their validity in the event of problems by loading the instruction into TIMS and cross-referencing with the actual signing certificate thumbprint, as discussed above.

Copy 
<Feature name="TachyonExplorer">
       <Consumer name="Platform" enable="on"> </Consumer>
       <Consumer name="Explorer" enable="on"> </Consumer>
       <Consumer name="Syslog" enable="on"> </Consumer>
       <Consumer name="Experience" enable="on"> </Consumer>
       <Consumer name="PatchSuccess" enable="on"> </Consumer>
       <Consumer name="GuaranteedState" enable="on"> </Consumer>
       <Consumer name="Inventory" enable="on"> </Consumer>
       <Instructions signersha="F08386A5318A8187D79B0A58253C65CB4E442570" pattern="1E-Explorer-*"> </Instructions>
       <Instructions signersha="323048C57C2A82DF852E1BC9AAA2DC2793E3D2B1" pattern="1E-Exchange-*"> </Instructions>
       <Instructions signersha="E9AD8EA04811AF7D0CF827AC015183481D78358D" pattern="1E-Explorer-*"> </Instructions>
       <Instructions signersha="A2837DBA33FBF3C29B7E72156729D1339A636344" pattern="1E-Exchange-*"> </Instructions>
       <Instructions signersha="E9AD8EA04811AF7D0CF827AC015183481D78358D" pattern="1E-Inventory-*"> </Instructions>
</Feature>

Creating a management group from the Settings UI

You can create a management group in the platform in Settings > Permissions > Management groups. For example, you can create a group which is associated with all processors having 2 cores.

Click the Evaluate option when saving the group so that it becomes visible via the platform API and thus useable by the 1E PowerShell Toolkit.

Verifying a management group

You can use the get-1Erespondingdevice cmdlet to determine which devices would be associated with a management group at any point in time. To do this, first use the get-1Emanagementgroup cmdlet to list management groups and determine the usableid property of the group you wish to interrogate. For example:

If we wanted to determine which devices are associated with a management group, we can then interrogate group membership like this. Note that the UsableId property of the group above is 6, so we specify that in the target scope expression:

Copy 
Get-1ERespondingDevice -TargetScope ManagementGroup=6

Management groups and SLA

The 1E Platform can synchronize its internal management groups with SLA management groups. SLA management groups define device membership by a set of rules that specify device attributes, for example, full or partial OU path.

When the platform synchronizes with SLA, it retains a list of the devices that matched the SLA management group rules, which were also in the associated SLA repository at the time of synchronization. From this point, the platform uses that device list as the group membership until the group is re-synchronized from SLA.

SLA management groups are created and managed using the platform settings. You can also create SLA management groups using the 1E PowerShell Toolkit.

You can view SLA management groups using the get-1Emanagementgroup cmdlet and specifying the optional -Source argument as SLA. When you do this, management group information is retrieved via the SLA API rather than directly from the platform itself.

You can also view SLA management groups using the get-1Eslamanagementgroup cmdlet, which returns only SLA management groups. This cmdlet has the additional option of returning the rules associated with an SLA management group.

Note that SLA management group properties are in some cases different from platform management group properties, as you can see from the example below.

Copy 
Get-1EManagementGroup -Source SLA

Starting with version 8 of the 1E Platform, there are additional cmdlets to manage SLA management groups. Refer to Instruction management cmdlets.

Rule-based and direct-based management groups

SLA and the platform itself support two types of management groups:

  • Rule-based management groups: Allow you to define a rule expression that determines which devices are members of the group. The scenario below shows you how to use rule expressions to determine membership of a test management group. For more information about rule expressions, refer to SLA management groups and rule expressions.
  • Direct-based management groups: Allow you to specify a list of device FQDNs which will be members of the specified group. For more information, refer to Direct-based management groups.

An overview of SLA management group capabilities is discussed below, with a simple test scenario.

The platform relies on SLA to determine the devices that fall within a management group. When management groups are synchronized from SLA to the platform, SLA uses the management group rules (for rule-based groups) to create a set of devices which fall within the group and it passes this device list to the platform.

For direct-based membership groups, SLA will determine the actual active devices in the appropriate repository (normally the Default Inventory repository) and it will then return this list. That could be a subset of the devices that were defined as group members if some of the devices are not online.

Understanding SLA management groups: A simple test scenario

In the scenario below, the test lab has been configured with version 8 of the platform but with no optional applications such as AppClarity installed. Two devices have been configured as devices in the lab domain (URTH.local). The devices are the following:

  • URTH-DEV.urth.local
  • URTH-SQL.urth.local

All operations are conducted using an account (CISO) that has the Global Administrator role in the platform.

Collecting inventory via SLA

In order to test management group functionality, we need to perform an inventory collection sync as described below.

Creating a Tachyon connector

  1. On the connectors screen, create a new connector called Tachyon. Associate it with the Inventory repository and point it at the appropriate consumer URL on your platform server. In this example, the platform server is tachyonv8.urth.local.

  2. Ensure that the account that the connector runs under is an account granted the Global Administrator role (in this test lab, this corresponds to the CISO account) and enter the account password.

  3. Save the connector.

  4. Select the connector and click Execute.

  5. Enter the details into the following screen as shown below.

  6. Click Execute. You can view the progress of the sync from Monitoring > Process Log in the UI.

Once the sync is complete, we can experiment with management groups.

Verifying devices have been captured

If you use a target scope of urth, which is a shortcut for fqdn like %urth% as a platform scope expression, you should find both devices returned.

Copy 
Get-1ERespondingDevice -TargetScope urth

Creating a test management group

Now let's create an SLA management group that filters this device set. We will use a rule that matches device FQDNs that are like %dev%. This will only return one of the two devices.

Copy 
New-1ESLAManagementGroup -Name JustDev -Rules "[ReportDevice.Fqdn] like %dev%"

The square brackets around the entity names are not required unless any part of the name has embedded spaces. You could for example, just say "ReportDevice.Fqdn like %dev".

Starting from the 24.5 release of the platform, changes were made to the platform that refactor functionality previously devolved to the separate SLA subsystem. This means that the names of available attributes you can use in management group expressions have changed. For example, ReportDevice.Fqdn is now Device.Fqdn.

Refer to SLA management groups and rule expressions for a discussion of SLA management group rule expressions and the entities that you can use with them. Note that SLA entity names will be different from platform entity names. The attribute part of the names (in this example, Fqdn) are also case-sensitive.

Synchronizing the group with the 1E Platform

In order for the platform to use the group we just created, we need to synchronize the platform with SLA.

Although we are only dealing with a single management group here, when you synchronize a particular group, you will also cause any other newly-created groups to be synchronized with the platform, and any deleted groups will be removed.

However, only the specified group is updated, so any other groups in SLA that have been changed don't get re-synchronized unless you specify them individually in calls to Sync-1ESLAManagementGroup.

Also, newly-created groups in the platform must be specifically synchronized (by specifying their Id in the Sync-1ESLAManagementGroup cmdlet) in order for the actual device membership associated with the group to be updated. Until this is done, the group in the platform will appear to contain no devices.

Copy 
Sync-1ESLAManagementGroup -Id 9 -RepositoryId 1

To obtain the repository Id value, we can query for all SLA repositories and locate the Default Inventory repository. It is the Id of this repository that we then provide to the sync-1ESLAManagementGroup cmdlet.

Copy 
Get-1ESLARepository

Now, verify that the platform has the new management group.

Copy 
Get-1EManagementGroup

The management group in the 1E Platform may end up with a different Id. Its UsableId value is what we will use when querying the platform.

If you delete a management group in SLA, it remains visible in the platform until you perform a sync operation for another existing SLA management group. At this point, the group is also deleted from the platform.

Determine the devices which fall into the scope of the management group.

Copy 
Get-1ERespondingDevice -TargetScope "managementgroup=9"

If you don't get any devices, try executing a sync again from the platform UI but select generate report - basic inventory consolidation instead of Sync Data - Tachyon. Then try running the sync-1Eslamangementgroup cmdlet again and re-check.

You can now experiment by modifying the existing group or creating a new one. For example, we can change the existing group in SLA:

Copy 
Update-1ESlaManagementGroup -id 9 -Rules "[ReportDevice.Fqdn] like %sql%"

Starting from the 24.5 release of the platform, changes were made to the platform that refactor functionality previously devolved to the separate SLA subsystem. This means that the names of available attributes you can use in management group expressions have changed. For example, ReportDevice.Fqdn is now Device.Fqdn.

We can now re-synchronize:

Copy 
Sync-1ESLAManagementGroup -id 9 -RepositoryId 1

Wait about a minute for the sync to complete. Now when we re-evaluate the rule, we see that the filtered devices have changed accordingly.

Copy 
Get-1ERespondingDevice -TargetScope "managementgroup=9"