0.5_Creating_Populating_System_Tree_F.pdf

ePolicy Orchestrator 5.1 Essentials ©2013 McAfee, Inc. All Rights Reserved. 1


This module provides an overview of the ePO System Tree and the available options used to populate it. Students will also be shown how tagging can be used to manage the System Tree.


The ePO System Tree The System Tree contains all of the systems that ePO manages. A system is a managed machine, that can be a server, workstation, laptop or an appliance. Each managed system is represented within the System Tree by using the system’s NetBIOS name. Internally to ePO, the system is represented by Globally Unique Identifier (GUID). The System Tree is the primary interface for managing policies and tasks. It is accessed by clicking the System Tree icon on navigation bar or selecting Menu > Systems >System Tree. The System Tree provides an inherited hierarchy of groups of systems managed by ePO. System configuration is initially inherited from the My Default policy objects which are set at the System Tree root and inherited downward to each node within the directory. This provides the capability to group machines logically, and where necessary, set alternative policy and change inheritance settings.


The top level of this structure is the My Organization object. All managed systems are organized within My Organization in units called groups. Groups are created by administrators or users with the appropriate permissions to that portion of the System Tree. They let you manage policies at once, rather than setting policies for each system individually. They also allow you to schedule client tasks (such as, update of virus definition files) at any level of the System Tree, as well as sort by IP address or tags. Groups can contain systems or other groups, you can moved between groups, as needed. There is no limitation on how deeply groups can be nested; however, access to machines becomes impractical if you have more than five levels of nesting. The System Tree root (My Organization) also includes a default group called Lost&Found, which stores systems whose locations could not be determined. Customers control how their systems are organized within the System Tree; for example, they might group the systems by functional department, geographic location, and so on. Remember, however, the organizational structure put in place affects how security policies are inherited and enforced throughout the environment. As part of the planning process, customers must consider the best way to organize systems into groups prior to building the System Tree.


Lost and Found Group When a system is sorted into Lost&Found, it is placed in a subgroup named for the system’s domain or workgroup. If no such group exists, one is created. All users with view permissions to the System Tree can see systems in Lost&Found. The Lost&Found group has the following characteristics:

• It always appears last in the list and is not alphabetized among its peers. • It can not be deleted or renamed. • Its sorting criteria can not be changed (although you can provide sorting criteria for the

subgroups you create within it.)

Note that if you delete systems from the System Tree, you also need to remove their agents; otherwise, these systems continue to appear in the Lost&Found group because the agent continues to communicate with the server.


Inheritance Inheritance is an important property that simplifies policy and task administration. Because of inheritance, child groups in the System Tree hierarchy inherit policies set at their parent groups. Inheritance is enabled by default for all subgroups and individual systems that you add to the System Tree. This allows you to set policies and schedule client tasks in fewer places. However, inheritance can be broken by applying a new policy at any location of the System Tree (provided a user has appropriate permissions) to allow for customization. You can lock policy assignments to preserve inheritance and prevent accidental changes. For example:

• Policies set at the My Organization level of the System Tree are inherited by subgroups below it. • Group policies are inherited by subgroups or individual systems within that group.


Creating the System Tree There is no single way to organize a System Tree, and because every network is different, the System Tree organization can be as unique as the network layout. Although you won’t use each method offered, you can use more than one. In many cases, the combination of methods chosen is to balance ease of creation, and the need for additional structure to make policy management more efficient. For example, you might create the System Tree in two phases.

• First, the customer can create 90% of the System Tree structure by importing whole NT domains or Active Directory containers into groups. If Active Directory is used in the network, the customer may consider importing the Active Directory containers rather than the NT domains.

• Then, they can manually create subgroups within each of the groups to classify systems together that may have similar antivirus or security policy requirements. If one NT domain is very large or spans several geographic areas, you can create groups and point the systems in each one to a separate distributed repository for efficient updating. Or, you can create smaller functional groupings, such as for different operating system types or business functions, to manage unique policies for these types of groupings.

If the Active Directory or NT domain organization does not make sense for policy management, the customer may prefer to create the System Tree organization in a text file and import it into the System Tree. If they have a smaller network, then they can create the System Tree manually and import each system.


Active Directory Synchronization The Active Directory Synchronization feature of ePO provides the capacity to provide synchronization between the Active Directory and the ePO System Tree. It allows mapping points to be created that link an Active Directory Organizational Unit (OU) container with an ePO group at any level in the System Tree. Each group within the ePO System Tree can be mapped to one Active Directory container, and sub-containers within the Active Directory container may be excluded from this process. As systems are added or removed from Active Directory, this feature allows you to easily populate and manage the portions of your ePO System Tree that contain computers from Active Directory, as well as assist you in enforcing compliance on new computers discovered on the network.

This may be achieved as a one or a two stage process.

• The one stage process allows you to import from a single Active Directory Organizational Unit (OU) container to a single ePO group. This is known as the Active Directory Import Wizard, and is accessed by clicking on the Systems tab and selecting the desired group.

• The two stage process allows you to first specify a number of Active Directory Organizational Unit (OU) containers to import to a number of ePO groups (Active Directory Synchronization Settings). The second stage allows you to schedule an Active Directory Synchronization Task.

Also systems can automatically move within ePO if they are moved between OUs in AD. If a computer is deleted in AD, it can optionally be removed from ePO, and the McAfee Agent automatically un-installed.


Importing NT domains You can create and populate groups automatically with systems from the network by importing entire NT domains. This method is an easy way to add all the systems in the network to the System Tree in one click. If domain is very large, you may want to also create sub-groups to assist with policy management or System Tree organization. To do this, first create a group by importing the domain into the System Tree, then manually create logical subgroups under the group, and drag the appropriate systems into them. When using this method, the customer should consider setting up tags or IP filters (if address information corresponds to the domain structure) and running the Domain Synchronization task regularly to ensure easy maintenance. You can use the NT domain importing feature to create and populate groups or to add systems of an NT domain to an existing group. Importing NT domains to existing groups In addition to creating a group from an NT domain import, you can also import all systems belonging to the selected Windows NT domain to an existing group. This is useful if the customer has several smaller domains on the network that would all use the same policies and tasks. To define them all in one place, they can import these systems into the same group and manage their policies from that group level.


Considerations when planning the System Tree An efficient and well-organized System Tree can simplify maintenance. Many administrative, network, and political realities of each environment can affect how the System Tree is structured. The customer should plan the organization of the System Tree before they build and populate it. Regardless of the methods chosen, it is best to always consider the environment while planning the System Tree. Here are some considerations when creating the directory structure:

• Subgroups are useful when anti-virus management is distributed across the organization and need to partition access to the directory. Alternatively subgroups can be useful if the anti-virus management is distributed across different system types (e.g. workstations, file servers, mail servers etc.).

• May be able to take advantage of the existing IP infrastructure to sort the System Tree if the environment is sub-netted or otherwise organized by IP address

• When needing to create policies for sets of computers, since most settings on most computers (especially workstations) are likely to be the same, it makes sense to group these systems.

• Similarly when needing to apply policy changes to numbers of computers, or where to report on these systems, it makes sense to group them.

Continued on next page


• Consider the access that other Administrators will need to have to the policies of the systems being managed.

• Consider how using sorting and inheritance can structure your System Tree to align with security needs.

• Consider the notifications that are needed to monitor on groups of systems. • Consider the grouping of machines that the Agent Handlers will manage.

Although it’s possible to create a detailed System Tree with many levels of groups. McAfee recommends that customers create only as much structure as is useful. In large networks, it is not uncommon to have hundreds or thousands of systems in the same container. Assigning policies in fewer places is easier than having to maintain an elaborate System Tree.


The Organization The customer has five offices — how should you organize computers within the ePO System Tree? Which groups should you create? There are several factors that should be weighed when deciding how to organize the System Tree; some of these factors include:

• The size of the organization. • How many physical sites (offices) are there? • Network bandwidth limitations. • The networking model of the organization. (Active Directory?) • The desktop clients operating system. • The scope of Remote Access to clients. (Can you see them? Do you have rights to administer

them?) • System configuration and exceptions. • Political boundaries. (Who is restricted from accessing which type of client, department, or

device?) • Who will be responsible for managing which systems? • Who will require access to view information about the systems? • Who should not have access to the systems and the information about them?

Though this may seem complicated, some of these factors may not be relevant to the customer’s organization, and others may be dictated by mechanisms that are already in place.


Methods of organizing the ePO System Tree Before deciding how to organize the System Tree structure consider the current situation:

• How are computers currently managed? Does the existing structure help or hinder anti-virus administration? Is administration centralized or distributed? Consider using the administrative boundaries as groups.

• Look at the geography — are all computers located in the same building or campus, city or country? Consider where updates will originate, the number and speed of network links available from the distribution points to managed computers.

• Look at administration with regard to computer roles — is desktop, laptop, file server, mail server and gateway server administration all undertaken by the same user or group? Consider grouping computers by type.

Subnets and IP address ranges In many cases, organizational units of a network use specific subnets or IP ranges, so you can create a group for a geographic location and set IP filters for it. Also, if your network isn’t spread out geographically, you can use network location, such as IP address, as the primary grouping criterion. You are not limited to manual sorting, IP address range, AD container or Windows domain. These are good places to start, but you can create logical groups, such as location or operating system, to align with administrative responsibility or function. This precision and flexibility makes it easier to accommodate organizational changes and policy variations.


Creating Groups Manually The directory structure can be built manually by adding groups that you define. This is useful where no formal Microsoft environment exists (e.g., using a NetWare-based network) or when the Microsoft Networking environment does not map well to the anti-virus management structure that is required. It may be beneficial to manually create sub-groups for logical collections of certain systems, after importing an entire NT domain or Active Directory container into the Directory. For example, you can create a Servers or an Exchange sub-group to set policies for special server applications. To add groups manually: These groups can be populated with systems by typing NetBIOS names for individual systems or by importing systems directly from the network. From the System Tree, select a parent group to begin. To create a new subgroup select the New Subgroups button. Enter the group name you wish to create and then click OK. The new group appears in the System Tree. Repeat as necessary until you are ready to populate the groups with the desired systems.


The Group Details Tab This page allows you to edit and configure a variety of settings for the selected group, including the group’s sorting criteria and its synchronization type (for example NT Domain or Active Directory). Clicking the Group Details tab when viewing the group in the System Tree will display this page. Note the options available from the Actions button.


Systems Permissions The Systems permission set specifies whether a user can modify the system tree, create, edit, or use tags, or take other actions on systems in the environment.

• System Tree: Specifies whether the user can see the System Tree tab under Systems. • Actions: Specifies actions a user can take. Options include: Wake up agents; view Agent Activity Log: Grants ability to wake up agents on systems in

groups to which the user has been granted access.

Edit System Tree groups and systems: Grants abilities create, edit, and organize groups and systems in the System Tree. Which portions of the System Tree this permission applies depends on the System Tree access permissions granted to the user. oDeploy agents: Grants ability to deploy agents to systems in groups to which the user has

been granted access. This option is only available when Edit System Tree groups and systems is selected.

• Tag Use: Specifies how a user can apply, clear, and exclude tags. Options include: Apply, exclude, and clear tags

• Tag Catalog: Specifies how a user can use the Tag Catalog. Options include: No permissions Create and edit tags Create and edit tags and tag criteria.

o This permission also requires that the user also has the Create and edit personal queries permission.


System Tree access Specifies the System Tree groups to which a user has access. This permission defines which systems a user can view or take actions on, as defined by the other permissions in the permission set. This option displays a list of checkboxes that correspond to the groups in the System Tree. Select the checkboxes next to the groups that you want users with this permission set to have access to in the System Tree.


Just like groups, systems can be added to the System Tree manually or automatically by a text file. If using Active Directory (AD), consider importing the existing Active Directory structure in ePO to manage systems in the network. Using Active Directory synchronization, the System Tree is updated automatically when Active Directory changes.


Deploying the McAfee Agent while creating the System Tree If you have not yet populated the System Tree, you can send the McAfee Agent installation package to computers at the same time that you are adding groups and computers. However, McAfee does not recommend doing this if the customer is creating the System Tree by importing large Active Directory containers, since this can generate a large volume of simultaneous network traffic.

Options: • Push agents and add systems to the current group: Deploys agents to the specified systems and

places them in the selected group of the System Tree. • Push agents and place systems in the System Tree according to sorting criteria: Deploys agents

to the specified systems in the groups System Tree according to sorting criteria. • Add systems to the current group, but do not push agents: Adds specified systems to the

current group but agents are not deployed to them. • Create and download agent installation package: Creates a custom agent installation package in

which you can embed credentials for the installation. • Import systems from a text file into the selected group, but do not push agents: Imports

systems from a properly generated text file, but does not deploy agents to these systems • Create a URL for client-side agent download: Specifies the custom URL used to download the

McAfee Agent installer. Copy the URL and share it with managed system users for manual installation. Available with ePO 5.0 and later.


The first and most expensive use of bandwidth occurs when the agent installation package is deployed to client systems. Customers can deploy the agent installation package from the ePolicy Orchestrator console to sites, groups, or systems in the System Tree. Deployment Recommendations: • Deploy agents:

In stages: Do not push network utilization over 80% at any time for a given segment of resources.

To individual sites or groups: This is especially important if you have more bandwidth-limiting factors such as slower connections between geographic locations.

• Options: System Tree sorting: Disables System Tree sorting on all specified systems when they are

added to the System Tree. Agent version: Specifies the version of the agent to send and install on the selected systems.

Agent versions that are available depends on which agent installation packages are checked in to the master repository.


During initial setup, pushing the agent generates enough network traffic that it is advisable to stagger agent deployments. The installation package for the agent is smaller than other products (such as VirusScan Enterprise), but the agent must be deployed to every client system that needs to be managed. Doing this all at once can generate a large spike in network traffic.


Adding Systems Manually to Existing Groups On the New Systems page, you can select whether to deploy the agent to the new systems, and whether the systems are added to the selected group or to a group according to sorting criteria.

Next to the Systems to add, type the NetBIOS name for each system in the text box, separated by commas, spaces, or line breaks. You can cut and paste a list of systems from a text file into this field as well. Alternatively, click Browse to select the systems. This will allow you to add any computers that are present in the browse list to the ePO directory structure. Although this is a simple process it may not be the best way to build the directory. Often browse lists are not completely current (both showing computers that no longer exist and not showing newer computers). In addition, some computers may be configured to not participate in the browse list so they will never appear. Organizations often use a single NT domain to manage NT computer accounts, but anti-virus administration may be better served by splitting this domain into multiple groups. If you selected Push agents and add systems to the current group, you can enable automatic System Tree sorting. Do this to apply the sorting criteria to these systems. If you selected to deploy agents to the new systems:

• Select the agent version to deploy. • Select whether to suppress the agent installation user interface on the system. Select this if you

do not want the end-user to see the installation interface. • Configure the agent installation path or accept the default. • Type valid credentials to install the agent.


Adding Computers through a Text File Follow these steps to build the directory structure based on a formatted text file or series of text files.

1. Prepare the text file or text files in the appropriate format.

2. From the System Tree, click the group into which you wish to import computers, and select New Systems. The New Systems page appears.

3. Select Import systems from a text file into the selected group but do not deploy agents.

4. Click Browse, then select the text file. Select what to do with systems that are included in the import, but that already exist elsewhere in the System tree.

5. Click OK.

The systems are imported to the selected group in the System Tree. If your text file organized the systems into groups, the server creates the groups and imports the systems.


Regardless of how you generate the text file, you must use the correct syntax before importing it. Verify the names of groups and systems, and the syntax of the text file, then save the text file to a temporary folder on the server. List each system separately on its own line. To organize systems into groups, type the group name followed by a backslash (\), then list the systems belonging to that group beneath it, each on a separate line.

GroupA\system1 GroupA\system2 GroupA\system3 GroupA\system4

The following import file syntax is legal:

• Designer1 — adds a computer called Designer1 below the current node. • Servers\Server1 — adds a computer called Server1 to a group “Servers” below the current node.

Use this syntax to add computers within subgroups. • Production\Servers\Server1 – adds a computer called Server1 under the “Servers” group that

exists under the “Production” group. Technically it is not recommended to use this format. There are 3rd party utilities available that can export a listing of computers into a text file. Windows 2000 and above provides CSVDE.EXE and LDIFDE.EXE which can be used to export Active Directory objects such as computers. When importing systems from a text file, the text file must use UTF-8 file encoding to correctly import system names with double-byte or extended characters in them.


ePO offers powerful integration capabilities to streamline the creation and ongoing maintenance of the System Tree.

• Automation: You can populate all or part of the System Tree with an AD structure and system placement. This saves time and reduces the possibility of human error.

• Flexibility: ePO supports the use of Active Directory and NT domains as the source for the System Tree structure. Its interface also provides flexible configuration options that let you control the level of integration that meets the organization’s needs.

• Simplified Management: ePO simplifies ongoing management change control through regular synchronization; for example, if the Active Directory structure changes (for example, systems or containers are added, moved, or removed), ePO updates the System Tree automatically at the next synchronization. ePO also supports polling and discovery at scheduled imports to ensure the tree remains up-to-date. ePO regularly polls Active Directory containers using an interval you define. If it discovers new systems, it imports them into the System Tree for administrative follow up.

• Optional Mirroring: ePO also provides a System Tree import tool for administrators who wish to identically mirror their Active Directory groupings within the System Tree.


If the network runs Active Directory, you can use Active Directory synchronization to create, populate, and maintain parts of the System Tree. Through Active Directory integration, you can:

• Synchronize with the Active Directory structure, by importing systems, and the Active Directory sub-containers (as System Tree groups), and keeping them up-to-date with Active Directory.

• At each synchronization, both systems and the structure are updated in the System Tree to reflect the systems and structure of Active Directory.

• Import systems as a flat list from the Active Directory container (and its sub-containers) into the synchronized group.

• Control what to do with potential duplicate systems.

• Use the system description, which is imported from Active Directory with the systems.


Types of Active Directory Synchronization There are two types of Active Directory synchronization (‘Systems Only’ and ‘Systems and container structure’). Which one gets selected depends on the level of integration desired with Active Directory. With each type, you can control the synchronization by selecting whether to:

• Deploy agents automatically to systems new to ePolicy Orchestrator. It’s best not to set this on the initial synchronization if the customer is importing a large number of systems and have limited bandwidth. The agent installation package is about 6 MB in size. However, the choice may be to deploy agents automatically to any new systems that are discovered in Active Directory during subsequent synchronizations.

• Delete systems from ePolicy Orchestrator (and remove their agents) when they are deleted from Active Directory.

• Prevent adding systems to the group if they exist elsewhere in the System Tree. This ensures no duplicate systems if you manually move or sort the system to another location.

• Exclude certain Active Directory containers from the synchronization. These containers and their systems are ignored during synchronization.


NT Domain Synchronization NT domains can be used as a source for populating the System Tree. When you synchronize a group to an NT domain, all systems from the domain are put in the group as a flat list. The customer can manage those systems in the single group, or they can create subgroups for more granular organizational needs. They can use a method, like automatic sorting, to populate these subgroups automatically. If moving systems to other groups or subgroups of the System Tree, be sure to select to not add the systems when they already exist elsewhere in the System Tree. Unlike Active Directory synchronization, only the system names are synchronized with NT domain synchronization — the system description is not synchronized.


The figure provides a process overview for Active Directory integration. We take a closer look at each of these steps in the sections that follow.

• First, you must prepare for Active Directory synchronization. You must register an LDAP server(s). If not importing the entire Active Directory structure, also configure the Synchronization type settings on the Group Details tab of each group that you want to map.

• Next, you’ll define synchronization settings; for example, mapping, synchronization type, treatment for duplicate entries, domain and credentials (if appropriate), containers, exclusions, and so on.

• Then you will configure the Agent Push settings, such as Agent version, credentials, the retry interval, number attempts, and so on.

• Finally, you will need to maintain synchronization manually or automatically by using server tasks and scheduling.


To perform the synchronization with Active Directory, you must first register an LDAP server, so that you can connect ePO with an Active Directory server. Register LDAP Servers Registered LDAP servers permit dynamically-assigned permission sets for Windows users. Dynamically-assigned permission sets are permission sets assigned to users based on their Active Directory group memberships. The user account used to register the LDAP server with ePO must be trusted via a bi-directional transitive trust, or must physically exist on the domain where the LDAP server belongs. Map Groups If you are not importing the entire Active Directory structure, configure the Synchronization type settings on the Group Details tab of each group that you wish to map. Use the Container section to map to specific Active Directory containers.


Mapping points created, link an Active Directory Organization Unit (OU) with precisely one ePO group. Sub-containers within the AD container may be excluded from this process. When an import task is run it will copy machines found in the AD location to the group specified in the ePO System Tree. To create a mapping point:

1. Select the System Tree button, then select the desired group in the System Tree. This should be the group to which you want to map an Active Directory container.

2. In the right-hand side of the console, select the Group Details tab. Next to Synchronization type.

3. Click the blue Edit link. The Synchronization Settings page for the selected group appears. 4. Click the Active Directory radial button for the Synchronization type. The Synchronization

Settings page opens.


Configuring Synchronization Settings (Continued) 5. Complete the Synchronization Settings page opens, using these guidelines.

Synchronize: Systems and container structure: Select this option if you want this group to truly reflect the

Active Directory structure. When synchronized, the System Tree structure under this group is modified to reflect that of the Active Directory container it's mapped to. When containers are added or removed in Active Directory, they are added or removed in the System Tree. When systems are added, moved, or removed from Active Directory, they are added, moved, or removed from the System Tree.

NOTE: If the organization of Active Directory meets your security management needs and you want the System Tree (or parts of it) to continue to look exactly like your mapped Active Directory structure, use this synchronization type with subsequent synchronizations.

Systems only (as a flat file): Select this option if you only want the systems from the Active Directory container (and non-excluded sub-containers) to populate this group, and this group only. No subgroups are created like when mirroring Active Directory.

NOTE: If you choose this synchronization type, be sure to select not to add systems again if they exist elsewhere in the System Tree. This prevents duplicate entries for systems in the System Tree.



When to Use This Synchronization Type Use this synchronization type when you use Active Directory as a regular source of systems for ePolicy Orchestrator, but the organizational needs for security management do not coincide with the organization of containers and systems in Active Directory. Use this procedure to import systems from an Active Directory container, including those in non-excluded sub-containers, as a flat list to a mapped system tree group. You can then move these (manually or by sorting) to the desired locations in the system tree by assigning.

NOTE: McAfee does not recommend selecting this option, especially if you are only using the Active Directory synchronization as a starting point for security management and use other System Tree management functionalities (for example, tag sorting) for further organizational granularity below the mapping point.

• Systems that Exist Elsewhere in System Tree:

• Add systems to the synchronized group and leaves them in their current System Tree location - Specifies that at the time of synchronization, if a system in the synchronized NT domain or Active Directory container is already in a different location of the System than the synchronized group, that system would exist in both System Tree locations after the synchronization. Therefore, selecting this option creates duplicate system entries in the System Tree.

• Leave systems in their current System Tree location only - Specifies that at the time of synchronization, if a system in the synchronized NT domain or Active Directory container is already in a different location of the System than the synchronized group, that system is not added to the synchronized group, but continues to stay where it was in the System Tree.

NOTE: McAfee recommends selecting this option if you use the synchronized group as the starting point for your System Tree organization and create other groups for granular security management.

• Move systems from their current System Tree location to the synchronized group - Specifies that at the time of synchronization, if a system in the synchronized NT domain or Active Directory container is already in a different location of the System than the synchronized group, that system is moved from the current location the synchronized group.

NOTE: McAfee recommends selecting this option if you always want the system in the synchronized System Tree group.

• In Active Directory domain, type the fully-qualified domain name of your Active Directory domain. This specifies the Active Directory domain whose containers are synchronized with the group. Or you can use the previously registered server.

• In Active Directory credentials, type the Active Directory user credentials that ePolicy Orchestrator uses to retrieve the Active Directory information.

• Next to Container, click Browse and select a source container in the Select Active Directory Container dialog box, then click OK.

ePolicy Orchestrator 5.1 Essentials ©2013 McAfee, Inc. All Rights Reserved. ‹#›



• Exclusions: To exclude specific sub-containers, click Add Container next to Exclusions and select a sub-container to exclude, then click OK. This specifies the Active Directory sub-containers that you want to exclude from the synchronization with this group. Use the Add and Remove buttons to create and edit this list.

• Delete Options: When using the Active Directory Synchronization task, ePolicy Orchestrator can delete systems from the ePolicy Orchestrator System Tree after the system is deleted from Active Directory. To do this, the specified Active Directory credentials must have access to the Deleted Objects container of Active Directory. If the Active Directory credentials do not have access to this container, such systems are not removed from the ePolicy Orchestrator Directory.

• Tags: You can assign custom tags to new machines added through synchronization. For example adding a tag labeled Synchronized via AD will let you know and quickly identify when new machines have been added through AD.

NOTE: The user account that is used for the synchronization is required to be able to view the ‘’Deleted items container of Active directory. Refer to the Microsoft knowledgebase article at http://support.microsoft.com/kb/892806. • Synchronize Now: Initiates synchronization between this group and its synchronized NT domain or

Active Directory container. NOTE: Clicking Synchronize Now saves changes to the synchronization settings before synchronizing the group. If you have an NT domain synchronization notification rule enabled, an event is generated for each system added or removed. (These events appear in the Notifications Log, and are queryable).


If using containers within the ePO Directory that correspond exactly with the name of domains or workgroups with the browse list, customer can use the Synchronize Domains task to add and delete systems manually or automatically to or from these groups. You can only synchronize the contents of domains or workgroups within the browse list with groups of the same name. If the domains or workgroups selected during task creation do not exist in the ePO System Tree, they are automatically added as groups. If there is an existing group with the same name as a domain or workgroups you select, the computers in the domain are added to that group. Note that in addition to placing the system into the ePO Directory the Synchronize Domains task will install the McAfee Agents.

NOTE: McAfee recommends that customers not deploy the agent during the initial import if their domain is large. Deploying the McAfee Agent package to many systems at once may cause network traffic issues. Instead, import the domain, then deploy the agent to smaller groups of systems at a time, rather than all at once. However, once finished deploying agents, consider revisiting this page and selecting this option after the initial agent deployment, so that the agent is installed automatically on any new systems that are added to the group (or its subgroups) by domain synchronization.


On-going Maintenance Once an Active Directory Synchronization or NT Domains have been specified at the Group level, the customer can continually maintain the listing of computers that are contained in the console tree by running a Active Directory Synchronization/NT Domain task or by manually updating the synchronized group. This task synchronizes selected Windows NT domains and Active Directory containers that are mapped to System Tree groups.


In this next section, we will focus on tagging. Tags are used to identify systems with similar characteristics. If the customer organizes some of their groups by such characteristics, then they can create and assign tags based on such criteria and use these tags as group sorting criteria to ensure these systems are automatically placed within the appropriate groups. Tags are based on system properties of managed systems. Tags

• The ePO server uses “Systems Tree” grouping, Tagging, and Microsoft Active Directory synchronization to move from static management of hard-coded groups to dynamic management based on user-defined tags and system properties (including Active Directory groups and domains). You can conveniently organize systems into custom groups and build rich identifiers into reports and tasks.

• Tags are like labels that you can apply to one or more systems, automatically (based on criteria) or manually. Tag criteria can be assigned to the tag in advance. Tags are then applied to systems by hand, as a result of queries, or by the system at the time of the agent-server communication.

• Once tags are applied, you can use them to organize systems in the System Tree or run queries that result in an actionable list of systems.

• Tagging allows a user to “tag” or “virtually group” systems based on the output of a query. Customers desired a way to virtually group systems in ePO with similar attributes but to not have to move around in the system tree (the only grouping method in ePO 3.x). Tagging allows users to define a query and apply a tag to the resulting systems to virtually group them. Users can then take action on the tagged systems. Systems can have more than one tag assigned and tags can be set on just about any attribute ePO knows about that system.

• Therefore, with tags as organizational criteria, you can apply policies, assign tasks, and take a number of actions on systems with the same tags.


When working with tags: • You can use the Tag Catalog • Create tags with the Tag Builder • Exclude systems from automatic tagging • Apply tags to selected systems • Apply criteria-based tags automatically to all matching systems


The Tag Catalog page is used to view summary information of any tag, it’s used to create or edit tags, and for running sorting criteria.

• New Tag button: Launch the New Tag Builder wizard where you create new tags.

• New Subgroup button: Launch the New Subgroup dialog box where you can create a tag subgroup.

• Import button: Import a previously exported Tags.xml file.

• Export button: Download or display the tags using xml format.

• Preset: Use available preset filters.

This Tag Group Only: Display the tags in the selected tag group.

This Tag Group and SubGroups: Display the tags and subgroups in the selected tag.

• Custom drop list: Create a custom filter or None to show all Tags, Tag Groups, and subgroups. Note there are different properties for Tags and Tag Groups in the Filter Tag Criteria.

• Quick find: Type search text to filter the tag list by the search results. You can search Tags and Tag Groups. Click Clear to clear all text from the Quick find text entry box. Click Apply to perform the search.

• Filter: Show/Hide Filter Shows or hides the filter options.


Tag Grouping Feature With the tag grouping feature, you can create tag subgroups up to four levels deep, with up to 1000 individual tags in each level. The benefit of Tag Grouping is to offer a more robust management system for Tags. In many ePO environments, the amount of Tags being used tends to exceed screen real estate and previously Tags would need to be managed via a flat list. Group tags to simplify creating policies, tasks, queries, and responses. Tag groups and individual tags appear in hierarchies similar to the System Tree. You can create and edit tags and tag groups as needed, and search for or filter tags on the Tag Catalog page. Continued on next page


Customers can now group tags to simplify creating policies, tasks, queries, and responses. Tag groups and individual tags will appear in hierarchies similar to the System Tree. You can create and edit tags, and tag groups as needed, and also search for or filter tags on the Tag Catalog page. For example, Tags may be used as a way of identifying systems in a different organizational fashion than how the System Tree is setup. This set of Tags may be numerous depending on the organizational structure being identified, such as the different departments of a user's company. These Tags are important, but can distract when trying to manage tags that do not relate to the organizing methodology. Using Tag Grouping, the organizational tags can be grouped together such that they do not clutter up a flat list of Tags, where the grouping is also identifying what Tags are present within the group such that new organizational Tags can be kept with the existing organizational Tags. NOTE: The Tag Grouping is for managing Tags only and does not change how Tags are used in other features of ePO, such as in regards to group sorting.


Criteria Page (Tag Builder wizard) When creating a new tag using the Tag Builder wizard, you’ll need to define the criteria. Tags use criteria that’s evaluated against every system, either automatically at agent-to-server communication, when the Run Tag Criteria action is taken, or manually on selected systems, regardless of criteria, with the Apply Tag action. Tags without criteria can only be applied manually to selected systems. When systems are evaluated against a tag’s criteria, the tag is applied to systems that match the criteria and have not been excluded from the tag. When finished creating the tag, it will be added to the list of tags on the Tag Catalog page.


Evaluation Page (Tag Builder wizard) Use this page to specify whether the tag can be applied (specific to criteria-based application) only when the Run Tag Criteria action is taken, or also automatically on matching systems at times of agent-server communication. NOTE: The settings on this page have no affect on manual application of the tag with the Apply Tag action.

• Only when a “Run Tag Criteria” action is taken - Specifies that this tag is only applied (based on criteria) when the Run Tag Criteria action is taken. When this action is taken, the tag is applied to all systems that match the criteria and have not been excluded from tag.

• On each agent-server communication and when a “Run Tag Criteria” action is taken - Specifies that this tag is applied to systems that match the criteria and have not been excluded from the tag at whenever the system calls into the ePO server, and whenever a Run Tag Criteria is taken.


Preview Page (Tag Builder wizard) The last page of the Tag Builder wizard is the Preview page. This page allows you to view the summary information of the tag. If the tag has criteria, this page displays the number of systems that will receive this tag when evaluated against its criteria. You have the option on this page to specify the action to take when applying the new tag.

• Apply the tag now to all x systems that match the tags criteria – This applies the tag to all the systems that match the specified tag criteria.

• Reset x manually tagged and excluded systems – This resets all the manually tagged and excluded systems.


Some Powerful Uses of Tags Automatic selection - IP addresses and tags can be used as sorting and querying criteria, alone or in combination. If you want to organize your groups by characteristics, you can create and assign tags based on these criteria. Use these tags as sorting criteria to ensure systems are automatically placed within the appropriate groups.

Example: All systems with OS Type = “Windows 7”, System Name starts with “DSKTP”, and IP Address is between “192.168.4.1-192.168.1.200” should be placed into group “Chicago Office Desktops”

System identification - Use tags and system properties gathered by the McAfee Agent to locate specific types or brands of systems.

Example: By building a tag that is applied if the MAC address of a machine begins with “000C29”, you can tag virtual systems that are running under VMware ESX.

Rarefied reports - Tags help you tailor reports to be more meaningful. Just define the tag, assign it to any number of systems, and define reports to run against the tag. Tags can include operating system, selection rules (LIKE, CONTAINS, EQUALS TO, NOT EQUALS TO, IP address AND operating system=server), computer name, or wildcards. Continued on next page


Special cases - In earlier releases, if you had to move the asset into a different group, its policies might be changed inappropriately, since often the new group had different policies. In ePO 4.0.0, it is easier to assign special policies based on the use and characteristics of the system. Think about these applications:

• Relax the system security policies for mobile systems to reduce the frequency with which they must check in to the management server.

• Run separate update and scan tasks for different groups, such as servers, laptops, and clients. • Associate asset value information with high-priority assets to ensure extra monitoring oversight

and extra attention in the event of outbreak or other disruption. • Customize policies for applications. If your Exchange servers all have names beginning with EXCH,

you can use a tag to create a new group based on this prefix. You can then create a policy that declares Server AV Protection running on Exchange servers should not scan database and mail folders and apply the rule just to that group.


Use this page to view all systems with the selected tag applied. From the new page you can take actions on one or more systems listed. From the Actions button menu, you can specify the actions you want to perform on the systems with the tag, including:

• Directory Management — Specifies the actions available to manage systems in the directory. • Agent — Specifies the actions that can be taken on agents on the selected systems. • Tag — Specifies the actions available to take for system tags on systems in the network. • Export Table — Opens the Export page. Use this to specify the format and package of the files to

be exported. You can save or email the exported file. • Choose Columns — Opens the Select the Columns to Display page. Use this to select which

columns of data to display on the this tab.


There may be a case where you want to exclude systems from having specific tags applied. Alternatively, you can use a query to collect systems, then exclude the desired tags from those systems from the query results.

To exclude systems from automatic tagging: 1. Select one or more system(s). 2. Click Actions > Tag > Exclude Tag. 3. In the Exclude Tag dialog box, select the desired tag to exclude from the selected systems

from the drop-down list, then click OK. 4. Verify the systems have been excluded from the tag:

• Click Menu on the navigation bar to go to the Menu page. • Click Tag Catalog within the Systems section, then select the desired tag in the list of tags. • Next to Systems with tag in the details pane, click the link for the number of systems

excluded from criteria-based tag application. The Systems Excluded from the Tag page appears.

• Verify the desired systems are in the list.


To apply a tag manually to selected systems in the System Tree:

1. Select the desired system(s).

2. Click Actions > Tag > Apply Tag.

3. In the Apply Tag dialog, select the desired tag from the drop-down list to apply to the selected systems, then click OK.

4. Verify the tags have been applied:

• Click Menu on the navigation bar to go to the Menu page.

• Click Tag Catalog within the Systems section.

• Select the desired tag in the list of tags.

• Next to Systems with tag in the details pane, click the link for the number of systems tagged manually. The Systems with Tag Applied Manually page appears.



There may be a case where you want to remove a tag that has been applied to your systems. Alternatively, you can use a query to collect systems, then clear the desired tags from those systems from the query results. To clear the tags:

1. Select one or more systems in the Systems table.

2. Click Actions > Tag > Clear Tag.

3. In the Clear Tag dialog box, select the desired tag to remove from the selected systems from the drop-down list, then click OK.

4. Verify the systems have been removed from the tag:

• Click Menu on the navigation bar to go to the Menu page.

• Click Tag Catalog within the System Section.

• Select the desired tag in the list of tags.

• Next to Systems with tag in the details pane, click the link for the number of systems excluded from criteria-based tag application. The Systems Excluded from the Tag page appears.



Ensuring that criteria-based tags are automatically applied to new systems, or to systems whose status changes to match the tag criteria, use the “Run Tag Criteria” server task to periodically evaluate systems being managed.


The figure shows an example configuration for a server task. It’s action is to run a query. It has a sub-action to move systems and then apply tag.


Only the administrator can create or edit tags, but ePO users with permissions to part of the System Tree can:

• Create and edit tags and tag criteria. • Apply and remove existing tags to systems in the groups to which they have access. • Exclude systems from receiving specific tags. • Use queries to view and take actions on systems with certain tags. • Use scheduled queries with chained tag actions to maintain tags on specific systems within the

parts of the System Tree they have access. • Configure sorting criteria based on tags to ensure systems stay in the appropriate groups of the

System Tree. To create or edit tags, or to apply, exclude and clear tags, you must have the appropriate permissions selected in the Systems Permission Set. Administrators have these rights by default, but other administrative users may need these permissions enabled.


This next section will focus on sorting systems within the System Tree. We’ll cover:

• Criteria-based Sorting • IP Address Sorting Criteria • Sorting Options • Sorting Systems into Criteria-based Groups • How a system is first placed in the System Tree • Changing the sort order on groups • Catch-All Group • Sorting Systems Manually


For sorting to take place, sorting must be enabled on the server and on the systems. By default, sorting at each agent-to-server communication is enabled.

How Settings Affect Sorting You can choose three server settings that determine whether and when systems are sorted. Also, you can choose whether any system can be sorted by enabling or disabling System Tree sorting on selected systems in the System Tree.

Server Settings The server has three settings:

• Disable System Tree sorting: If criteria-based sorting does not meet your security management needs and you want to use other System Tree features (like Active Directory synchronization) to organize your systems, select this setting to prevent other ePO users from mistakenly configuring sorting criteria on groups and moving systems to undesirable locations.

• Sort systems on each agent-server communication: Systems are sorted again at each agent-server communication. When you change sorting criteria on groups, systems move to the new group at their next agent-server communication.

• Sort systems once: Systems are sorted at the next agent-server communication and marked to never be sorted again at agent-server communication as long as this setting is selected. However, selecting such a system and clicking Sort Now does sort the system.

Continued on the next page.


System Settings You can disable or enable System Tree sorting on any system or a collection of systems. If System Tree sorting is disabled on a system, that system will not be sorted regardless of how the sorting action is taken. If System Tree sorting is enabled on a system, that system is sorted always for the manual Sort Now action, and may be sorted at agent-server communication, depending on the System Tree sorting server settings.

Operating Systems and Software Consider grouping systems with similar operating systems to manage operating system-specific products and policies more easily. If you have some older systems running a different version of an operating system you can create a group for such legacy systems together to deploy and manage security products on these systems separately. Additionally, by giving these systems a corresponding tag, you can automatically sort them into a group.

Enabling System Tree Sorting on Server To enable System Tree sorting on the server:

1. Select Menu > Configuration, select the Server Settings tab, select System Tree Sorting tab in the Setting Categories list, then click Edit.

2. Select whether to sort systems only on the first agent-server communication or on each agent-server communication.

If you selected to sort only on the first agent-server communication, all enabled systems are sorted on their next agent-server communication and are never sorted again for as long as this option is selected. However, these systems can be sorted again manually by taking the Sort Now action, or by changing this setting to sort on each agent-server communication. If you selected to sort on each agent-server communication, all enabled systems are sorted at each agent-server communication as long as this option is selected. NOTE: System Tree sorting must be enabled on the server and the desired systems for systems to be sorted. Enabling and Disabling System Tree Sorting on Systems Use this task to enable or disable System Tree sorting on systems. The sorting status of a system determines whether it can be sorted into a criteria-based group. Alternatively, you can change the sorting status on systems in any table of systems (such as query results), and also automatically on the results of a scheduled query.

1. Select the System Tree button, select the Systems tab, then select the desired systems. 2. Click Directory Management > Change Sorting Status, then select whether to enable or

disable System Tree sorting on selected systems.

Depending on the server setting for System Tree sorting, these systems are sorted on the next agent-to-server communication. Otherwise, they can only be sorted with the Sort Now action.


You can use IP address information to automatically sort managed systems into specific groups. You can also create sorting criteria based on tags, which are like labels assigned to systems. You can use either type of criteria or both to ensure systems are where you want them in the System Tree. Systems only need to match one criterion of a group's sorting criteria to be placed in the group. After creating groups and setting your sorting criteria, take a Test Sort action to confirm the criteria and sorting order achieve the desired results. Once you have added sorting criteria to your groups, you can run the Sort Now action. The action moves selected systems to the appropriate group automatically. Systems that do not match the sorting criteria of any group are moved to Lost&Found. New systems that call into the server for the first time are added automatically to the correct group. However, if you define sorting criteria after the initial agent-to-server communication, you must run the Sort Now action on those systems to move them immediately to the appropriate group, or wait until the next agent-to-server communication. Test Sorting Systems Use this feature to view where systems would be placed during a sort action. The Test Sort page displays the systems and the paths to the location where they would be sorted. Although this page does not display the sorting status of systems, if you select systems on the page (even ones with sorting disabled) clicking Move Systems places those systems in the location identified.


Tag-based Sorting Criteria In addition to using IP address information to sort systems into the appropriate groups, you can define sorting criteria based on the tags that have been assigned to systems. Tag-based criteria can be used in conjunction with IP address-based criteria for sorting as well.


Like tag sorting criteria, IP address can be used for automated sorting into groups. In many cases, organizational units of a network use specific subnets or IP ranges, customers can create a group for a geographic location and set IP filters for it. You can use sorting criteria based on IP address information to automate System Tree creation and maintenance. Set IP subnet masks or IP address range criteria for applicable groups within the System Tree and these filters will automatically populate locations with the appropriate systems. Once configured, you can sort systems at each agent-to-server communication, or only when a sort action is manually initiated. IP address sorting criteria In many networks, subnets and IP address information reflect organizational distinctions, such as geographical location or job function. If IP address organization coincides with your needs, consider using this information to create and maintain parts or all of your System Tree structure by setting IP address sorting criteria for such groups. This functionality allows for setting of IP sorting criteria randomly throughout the system tree — you don’t need to ensure that the child group’s IP address sorting criteria is a subset of the parent’s (as long as the parent has no assigned criteria). Please know that IP address sorting criteria should not overlap between different groups. Each IP range or subnet mask in a group’s sorting criteria should cover a unique set of IP addresses. If criteria does overlap, which group those systems end up in depends on the sorting order of the subgroups on the Group Details tab.


The server uses the following search algorithm to place systems in the System Tree based on the criteria in this order:

• Group IP filter — If a group with a matching IP filter is found, the system is placed in that Group based on the criteria in this order:

• In a group named the same as the NT domain to which the system belongs. • In a group with a matching IP filter. • If no group match for IP address or domain name is found, the system is placed in the

Lost&Found group. • Group Domain name — If no group is found with a matching IP filter, the server searches for a

group with the same name as the NT domain to which the system belongs. If such a group is found, the server searches for a group with a matching IP filter and places the system within. If no group is found, the system is placed in the Lost&Found group.

• No group IP filter or domain name match is found — If the server cannot find an IP or domain name match in any group, the server adds the system to the global Lost&Found.


IP address sorting criteria should not overlap between different groups. Each IP range or subnet mask in a group’s sorting criteria should cover a unique set of IP addresses. If criteria does overlap, the group where those systems end up depends on the order of the subgroups on the System Tree Groups Details tab. You can check for IP overlap using the Check IP Integrity action in the Group Details tab. To check your IP settings select the Check IP Integrity option from the menu and this will open the IP Integrity Check dialog box and displays the output of the IP integrity check.


Once you start the Check IP Integrity you can see if there is any overlapping between groups. Click the blue Resolve hyperlink to open the Resolve Sorting Conflicts page.


On the Resolve Sorting Conflicts page, review the discrepancy and correct it as necessary. Click Save when finished.


When an agent is installed to a system with or without using the ePO console, the system will automatically connect to the ePO server, which will create an entry within the System Tree if one does not already exist. The ePO server will attempt to match the remote systems’ details to determine the most appropriate location in which to create the entry.

If a matching system is not found, the server uses an algorithm to sort the systems into the appropriate groups. Systems can be sorted into any criteria-based group in the System Tree, no matter how deep it is in the structure, as long as each parent group in the path does not have non-matching criteria. Parent groups of a criteria-based subgroup must either have no criteria or matching criteria.

NOTE: ASCI is Agent-to-Server Communications Interval. This is the user-definable interval at which the McAfee Agent will report in to the ePO server or Agent Handler. By default, the ASCI is 60 minutes.


The order in which subgroups are placed the Group tab determines the order they are considered by the server when it searches for a group with matching criteria.

1. The server searches for a system without an agent GUID (its agent has never called in before) with a matching name in a group with the same name as the domain.

2. If found, the system is placed in that group. This can happen after the first Active Directory or NT domain synchronization, or when you have manually added systems to the System Tree.

3. If a matching system is still not found, the server searches for a group of the same name as the domain from which the system originates.

4. If there is match, the system is placed in that group. 5. If such a group is not found, one is created under the Lost&Found group, and the system placed

there. 6. Properties are updated for the system.

The server applies all criteria-based tags to the system if the server is configured to run sorting criteria at each agent-server communication. What happens next depends on whether System Tree sorting is enabled on both the server and the system. If System Tree sorting is disabled on either the server or the system, the system is left where it is. If System Tree sorting is enabled on the server and system, the system is moved based on the sorting criteria in the System Tree groups. NOTE: Systems that are added by Active Directory or NT Domain synchronization have System Tree sorting disabled by default. Therefore, they are not sorted on the first agent-server communication.


The server considers the sorting criteria of all top-level groups according to the sorting order on the My Organization group’s Group Details tab. The system is placed in the first group with matching criteria or a catch-all group it considers.

• Once sorted into a group, each of its subgroups are considered for matching criteria according to their sorting order on the Group tab.

• This continues until there is no subgroup with matching criteria for the system, and is placed in the last group found with matching criteria.


If a top-level group is not found, then the subgroups of top-level groups (without sorting criteria) are considered according to their sorting. If a second-level criteria-based group is not found, then the criteria-based third-level groups of the second-level unrestricted groups are considered. NOTES:

Subgroups of groups with un-matching criteria are not considered, a group must have matching criteria or have no criteria in order for its subgroups to be considered for a system. This continues down through the System Tree until a system is sorted into a group. If the server System Tree sorting setting is configured to sort only on the first agent-server communication, a flag is set on the system and it can never be sorted again at agent-server communication unless the server setting is changed to enable sorting on every agent-server communication. If the server cannot sort the system into any group, it is placed in the Lost&Found group within a subgroup named after its domain.


Sorting Criteria chooses which systems will be placed into the selected group. In this example, systems are placed in the McAfee group based on their IP address (within the range specified), and their assigned tags. Continued on the next page


Sorting criteria page options:

Option Definition

None Specifies that no system is sorted into this group. However, systems can be sorted

into matching criteria-based subgroups.

All others Specifies that any system that was sorted this far is added to this group. In some

tables of the interface, this type of group is identified as a Catch-All. Only groups

that are at the end of the sorting order of its peers and have a parent group whose

sorting criteria is set to None can be a catch-all.

Systems that

match any of the

criteria below

Systems that match the group’s criteria are sorted into this group or into a

matching subgroup.

Add Tag Adds a criterion to the group based on a tag the user selects.

Tags Specifies the tag that is used as sorting criterion for this group.

IP addresses Specifies the beginning and ending IP addresses in the range that you want to

include in the current site or group. You can use either the IPv4 (xxx.xxx.xxx.xxx,

where x is 0 – 255; for example, 161.69.0.0 through 161.69.255.255) or IPv6

address format. For example, 3FFE:85B:1F1F::A9:1234 is displayed as

[3FFE:085B:1F1F:0000:0000:0000:00A9:1234].

Alternatively, specifies the IP subnet mask and number of significant bits that you

want to include in the current site or group. Use the format xxx.xxx.xxx.xxx/yy,

where x is 0 – 255 and y is 0 – 32. For example, the IP subnet mask of

161.69.0.0/16 equals the range 161.69.0.0 through 161.69.255.255. The IP subnet

mask of 161.69.255.0/18 equals the range 161.69.192.0 through 161.69.255.255.


Catch-all groups are groups whose sorting criteria is set to All others on the Sorting Criteria page of the group. Only subgroups at the last position of the sort order can be catch-all groups. These groups receive all systems that sorted into the parent group, but did not sort into any of the catch-all’s peers.


Test Sorting Systems Use this feature to view where systems would be placed during a sort action. The Test Sort page displays the systems and the paths to the location where they would be sorted so you can decide if you wish to apply this sorting criteria.


If necessary, you can manually move systems from one group to another.

There are two methods of moving systems from one group to another:

1. From the group’s Systems tab:

a. Select the system(s) to move and click the Actions button, choose Directory Management Move Systems.

b. Select sorting options and the group to move to.

2. Drag and drop the system onto any group in the System Tree.

a. The system will inherit the new parent groups sorting criteria and policies.


ePO has a feature called sequence checking. This basically enables the server to keep track of the number of connections the client makes and detect whether or not the connection falls out of sequence. When a managed client communicates to the ePO Server it’s going to log a sequence number for that machine. For the first time, it has a sequence number of 1 and then it’s going to change to 2. The next time it connects it’s going to change from 2 to 3 and so on. The sequence number is going to continue to increment. ePO is going to keep track of this in the database for each individual node. The agent is going to keep track of it too. The numbering should match up between the client and server at all times. However, if the McAfee Agent communicates back to the server and has a sequence count from 2 to 3 and then connects again later with a count is still 2 or 1 or maybe 4, ePO is going to detect that the sequence number the client is trying to send up is not what it has logged for that machine in the database. This will cause ePO to reject the communication from that machine. There are a certain number of things that cause sequence errors to occur.


The first thing that causes this problem is that some customers use virtual machines and they have what is called a snapshot on a virtual machine. The snapshot is going to revert the image back to a previous state, therefore taking with it the sequence number that was present on that machine at that time. When the client tries again to connect back up to the ePO Server, it’s going to pass to it the old sequence number that it was using when the snapshot was taking place. This causes a sequence error count to be logged for that machine and ePO is going to reject the communication. It does this to prevent spoofing or man-in-the-middle attacks. There’s another application on the market called Deep Freeze that does essentially the same thing. It reverts the machine back to the original state at every system restart. Another problem customers run into is that they image machines using a company image. And in their image they are including the McAfee Agent. Unfortunately, every time you install an Agent on a machine it creates a unique GUID (Global Unique Identifier) for that machine. That GUID number is supposed to be unique to every client in the environment. Continued on next page


If you install the agent to a company image and then deploy the image to many machines, each machine is going to have the same GUID. Based on the system tree placement, when the first client machine that was deployed the image connects to ePO, ePO is going to create an entry in the system tree for that node and log the GUID number for that client. The second machine that was deployed the image to connects to ePO. Based on system tree placement, ePO is going to look at the GUID on that machine first and see that it already matches the first machine that communicated in and believe it is the same machine. The problem there is that the second machine is going to have a different sequence number than what the ePO Server is expecting. From then on, it’s basically going to reject client machine communication from every machine that was deployed the image. We recommend that if the customer uses the agent in an image, to first remove the GUID from the image before finalizing. Therefore, when the image is deployed, when the machine first boots up, the GUID number is created from scratch and unique to every machine. Removing the GUID prior to finalizing the image is not ideal for customers to accomplish sometimes, so ePO has another way to deal with this problem. First, you’ll want to identify the machines with the problem. The way to do that is to add a Sequence Error column that displays a count of the number of times the node attempted communication and recorded a sequence error. Under the System Tree, highlight the affected node(s) showing sequence errors because of duplicate GUIDs and then click on the Actions menu button. Select Directory Management Move GUID to Duplicate List and Delete System. This tells ePO to blacklist that GUID and remove the system from the directory. Therefore, any client machine that communicates thereafter, using that same GUID, will be flagged. Once the agent communicates back to the server, it will automatically create a new unique GUID. TIP: For Deep Freeze and VMware image snapshot related sequence errors, it is possible to disable Sequence Checking on the ePO Server.


Documents

0.5_Creating_Populating_System_Tree_F.pdf