Best practice: designing groups in Enterprise Console

  • Article ID: 63155
  • Rating:
  • 3 customers rated this article 2.7 out of 6
  • Updated: 09 Oct 2013

A group in Enterprise Console is a collection of computers that will use the same policies. In ADSync, these groups are similar to your Organizational Units (OUs).

Groups and sub-groups are logical divisions that share common policy requirements. A new group is needed whenever you have a computer that requires a different Updating, Anti-Virus and HIPS, Firewall, Data Control, Device Control or Application Control policy to the other computers on your network.

A common example of the need for multiple groups is for servers that have a special updating schedule in place so that the network is updated during quieter times of the day. Those servers will need their own group in Enterprise Console with a special updating policy applied, but they may share all other policies with the endpoint computers on your network.

We have compiled the following advice for designing your computers groups in Enterprise Console

  1. Try to base your groups on your existing IT administration system. Replicating the existing structures will save you time later when you are designing policies and performing remedial actions on computers.

    If you use Active Directory, we recommend importing your OUs (containers) first, and then, when you've created the appropriate groups and subgroups (and sub-estates, if you are using this feature) in Enterprise Console, synchronize some or all of the groups with Active Directory to automatically populate the Enterprise Console groups with the computers in the OUs.
  2. If you don't have an existing structure, or you would rather create a new one, we find that a lot of our customers use location or department as a basis for their groups. So they may use a schema like:

    City

    Department

    Laptop

    At the minimum, you should create separate groups for your endpoints and servers, as you will likely want different scan settings and update schedules for your servers to ensure that scans and updates don't create server access delays.

  3. Especially for the initial deployment, but also for regular maintenance, it's wise to restrict your groups to no more than 1000 computers.
  4. If you're going to be creating and using sub-estates, ensure that you define the sub-estates and the groups that belong in each one before you import your computers into Enterprise Console. This is because it can get a bit tricky when moving computers between groups later when they are in different sub-estates.
  5. Finally, be aware of the implications of certain policy settings. For example, you may want your sales department to have access to an instant messaging program, but not your manufacuring department. These different departments will therefore need to be in different groups in order to apply different Application Control policies to them.
  6. If you need more flexibility, you can also create subgroups, which can have different policies than their parents. If you use Active Directory, this will allow you to use OUs to create and synchronize your computers, but still apply a separate policy (or two or three) to some of the computers in that group.

    An example of this scenario would be in a finance department that routinely sends intradepartmental emails containing banking or financial information. You may want to set up a Data Control policy that forces most of these users to accept a warning when they are about to transfer the data, but allow the transfers between the senior officials in the unit with no intervention. Hence the most permissive policy would be applied to a subgroup that shares all the other policies (Anti-Virus, Firewall and others).

    Another example of using subgroups is for laptops. You may want them to use the same policies as the desktop computers in the group, but to have a firewall policy that includes a secondary location or more stringent settings than those that are applied to the computers on your site. Simply create a subgroup for the laptops and apply all the same policies as the parent group, but a different firewall policy (that can be shared with all laptops in the company).
  7. We recommend that you read the Policy Setup Guide and the Anti-Virus and Firewall setttings guides on the Best Practice site for help deciding how many policies you will need, which in turn will affect how many groups you create. Policy settings that can affect how many groups you need include:

    • on-access scan settings
    • scheduled scan settings
    • scheduled scan schedules
    • potentially unwanted application exceptions
    • suspicious file exceptions
    • suspicious behaviour exceptions
    • updating schedules and locations
    • firewall exclusions and application rules
    • device control exceptions
    • application control exceptions
    • differences in data control policies and how users interact with them

Related articles

  • To read more about designing sub-estates and role-based administration, see the Best Practice guide: designing sub-estates and role-based administration.
  • To read more about the Anti-Virus and Firewall policy settings that you may want to consider setting, see the Anti-Virus and HIPS and the Firewall Settings Guides on the Best Practice site.
  • For guidance on rolling out your policies once you've set up your groups, see the Policy Setup Guide.

 
If you need more information or guidance, then please contact technical support.

Rate this article

Very poor Excellent

Comments