All examples below are for information purposes. All group structures and names used are for demonstration purposes to explain theories to group structure. You may use the examples below, or create your own as needed.
Active Directory Sync
An existing Active Directory structure can be synchronized with the Symantec Endpoint Protection Manager (SEPM) to create group structure, but this may not always be the optimum solution. The use of an active directory 'sync' will largely depend on how well the Active Directory structure is organized.
How to design client groups for SEPM
When creating client groups for the SEPM it is best to first consider the structure of the environment. The following questions may be helpful:
- How many physical sites will there be?
- How many computers per site?
- Will each site have its own SEPM?
- Are you using both 32 and 64 bit computers?
- Will there be any specific policies that will apply directly to an individual or a group of computers? For an example; scanning schedules, liveupdate schedules, firewall policies, centralized exceptions, etc.
The answer to these questions will determine how advanced the group structure will need to be.
Simple group structure
Quite often a simple design will only consist of a few groups for all clients. A simple structure may look as follows:
Advanced group structure
A structure like this will be most common in networks with single locations, that are all running computers with the same bit type. If your environment is using a mix of technology, where you have both 32 and 64-bit computers; your structure may look more like this:
When creating a structure like this, a folder (group) is recommended for the general group type, and then sub-groups within for the individual needs. This type of structure can be used for needs other than bit type.
Client computers with special needs
When creating groups for clients that may have individual needs, such as custom policies only applied to one or a few of the computers; they will need to have inheritance turned off. The purpose of doing this is so the sub groups will not inherit the policies of the parent groups. For an example; let’s say the company has one main office, and two small remote locations. It would be best to create a group for each:
After creating a group for the Main Office, Remote Site #1, and Remote Site #2, inheritance must be disabled for all three. Doing this will allow for separate policies to be applied at each site. This is useful for when you need to create differing communication settings, scheduled scans, liveupdate scheduling, and other custom policies. If the configuration needs to be more granular per site, it is suggested to also turn inheritance off for the sub groups; therefore allowing separate policies to be created, and applied to each individual sub group.
Sometimes a situation will be presented as to where one particular computer will need to have custom policies applied that should not be applied to all other groups. The best way to organize this type of setup would be to give this individual computer, or computers their own group in the root of the structure.
The use of a separate group with inheritance turned off will allow for special need computers to function without their policies affecting the other groups of clients.
When creating group structure, it is best to keep the process as simple as possible to avoid confusion at later times. It is also helpful to remember the fact that policies apply directly to groups, not to clients. Clients will only inherit the policies of the group they are placed in.