Migration steps

If you use AD synchronization and you have issued an AD token for the All static group or any groups outside of Companies that will not be migrated, you must revoke tokens for such groups to prevent devices from synchronizing into these groups. After the migration completes, you must reissue AD tokens for groups located under the Companies static group to use AD synchronization.

Ensure that any administrators of a given static group/site are not locked out during the migration and can still manage all devices, whether migrated or not.

There are two ways to do this:

•Edit the existing permission sets used for administrators and add the static group representing the new static group/site to them (Site 1 in this example).

•Create new permission sets.

Create new permission sets

1.Navigate to the Permission sets page and click the New button.

2.In the Static Groups tab, select the respective static group under the Companies tree.

3.In Functionality, select all the permissions you want to give to the administrators of the static group.

4.After you create a permission set, assign it to administrators. This way, they can see everything they could see before and, additionally, all objects under their respective static group, where devices will be migrated.

After migrating static groups, you may clean any obsolete permission sets that company administrators had before the migration.

Recommended approach

•Grant already created preset permission sets Read access permission set, Write access permission set or Administrator permission set, which are scoped to the All static group to global administrators.

•Static group/site-specific administrators should have permission sets scoped to the static group/site (Site 1 in this example).

The devices should retain the same policy configuration before and after the migration. Look for any policy configuration that may be lost due to devices no longer inheriting it from some of the parent static or dynamic groups. Similarly, devices may inherit additional policy configurations from new parent groups after the migration.

In the picture below, the group in the red box represents the group from which migrated devices are inheriting policy configuration and may be lost due to the migration. Similarly, in the green boxes are those groups from which the migrated devices will inherit additional policy configuration after the migration. Exceptions to this rule are the All static group and all dynamic groups placed directly under the All group. The devices will inherit policy configurations from these groups before and after the migration.

Check the policy assignments of any of the groups in red or green boxes and check whether any policies are assigned to these groups.

When you see any policy configuration for any of the problematic groups after you click Manage policies—ensure, before migrating devices, that the policy configuration assigned to the group in the red box is also set for groups in green boxes to retain the same configuration after the migration.

Recommended approach

•Any policy configuration that should be enforced on every device managed by this instance should be assigned to the All static group.

•Any policy configuration that should be enforced only to devices of one site should be assigned to the static group representing this site (Site 1 or Site 2 in this example) below the Companies static group.

Rules similar to policies apply to client tasks and their respective triggers, which may also target some static or dynamic groups. To check whether there are tasks assigned to one of the problematic groups:

1.Navigate to Computers, click the gear icon next to the group you want to inspect and click Show Details.

2.Click the Tasks tab to see all client tasks with at least one of their triggers assigned to this group. In this example, we have an Example task with a trigger assigned to the Sites SG group.

3.After clicking Show Details for any specific task, you will be redirected to a new page to inspect all the task triggers.

Recommended approach

•Identical to the one mentioned in policies—organize your client tasks and triggers based on their scope and devices they should run on.

To check whether notifications are going to continue functioning as before, you must check which static groups they are monitoring:

1.Navigate to Notifications and click every used notification.

2.From the context menu, select Edit, and go to Configuration.

3.If a notification monitors a problematic group, the behavior of the notification can change after the migration. You may lose some existing notifications because of the migration or trigger new notifications because the migrated devices appear in different static groups after the migration.

To resolve these issues, similar rules apply as before. Any notification that should be triggered for all of the company devices should be monitoring the All static group, and any notifications meant for a single site or static group should be monitoring this static group (Site 1 or Site 2 in this example).

Ensure all the installers are configured to put devices into groups under the Companies static group. You can do this in two ways:

•Create a new installer for every site if present under the Companies static group.

•Move the entire static group to which the installer is configured to add devices into one of the static groups as a subgroup.

Create a new installer

1.Navigate to the Installers screen, click Create Installer and then click Select.

2.Select the respective static group (Site 1 in this example).

3.All devices installed with this newly created installer will appear in the correct part of the static group tree.

Now you can migrate the devices.

Migration method I.

The most usual setup is having the devices in a single static group outside of the Companies tree (with optional subgroups).

•Move the static group where the company’s devices are managed into the static group representing the company (Site 1 in this example).

•Advantage–all objects that target the static group will be functional even after moving it.

•After migrating the static group Site 1 SG, your static groups hierarchy should look like in the example below.

Migration method II.

Alternatively, you can manage all the devices in the All static group and have different dynamic groups for every site.

•We recommend to click a dynamic group representing the migrated site, select all devices and move the devices into the static group representing the company’s site (Site 1 in this example).

•After all the devices actively connected to ESET PROTECT reconnect, you can move the dynamic group.

Devices in the static group Lost & found must be migrated manually, depending on where they belong. For example, a device belonging to Site 1 in our example should be moved to this group or to any of its subgroups. Devices belonging to the top-level company should be moved to SMB company or any of its non-site subgroups.