epo 400 eval guide en us

McAfee ePolicy Orchestrator 4.0Evaluation and Walkthrough Guide

COPYRIGHT

Copyright © 2008 McAfee, Inc. All Rights Reserved.

No part of this publication may be reproduced, transmitted, transcribed, stored in a retrieval system, or translated into any language in any formor by any means without the written permission of McAfee, Inc., or its suppliers or affiliate companies.

TRADEMARK ATTRIBUTIONS

AVERT, EPO, EPOLICY ORCHESTRATOR, FLASHBOX, FOUNDSTONE, GROUPSHIELD, HERCULES, INTRUSHIELD, INTRUSION INTELLIGENCE,LINUXSHIELD, MANAGED MAIL PROTECTION, MAX (MCAFEE SECURITYALLIANCE EXCHANGE), MCAFEE, MCAFEE.COM, NETSHIELD,PORTALSHIELD, PREVENTSYS, PROTECTION-IN-DEPTH STRATEGY, PROTECTIONPILOT, SECURE MESSAGING SERVICE, SECURITYALLIANCE,SITEADVISOR, THREATSCAN, TOTAL PROTECTION, VIREX, VIRUSSCAN, WEBSHIELD are registered trademarks or trademarks of McAfee, Inc.and/or its affiliates in the US and/or other countries. McAfee Red in connection with security is distinctive of McAfee brand products. All otherregistered and unregistered trademarks herein are the sole property of their respective owners.

LICENSE INFORMATION

License Agreement

NOTICE TO ALL USERS: CAREFULLY READ THE APPROPRIATE LEGAL AGREEMENT CORRESPONDING TO THE LICENSE YOU PURCHASED,WHICH SETS FORTH THE GENERAL TERMS AND CONDITIONS FOR THE USE OF THE LICENSED SOFTWARE. IF YOU DO NOT KNOW WHICHTYPE OF LICENSE YOU HAVE ACQUIRED, PLEASE CONSULT THE SALES AND OTHER RELATED LICENSE GRANT OR PURCHASE ORDER DOCUMENTSTHAT ACCOMPANIES YOUR SOFTWARE PACKAGING OR THAT YOU HAVE RECEIVED SEPARATELY AS PART OF THE PURCHASE (AS A BOOKLET,A FILE ON THE PRODUCT CD, OR A FILE AVAILABLE ON THE WEB SITE FROM WHICH YOU DOWNLOADED THE SOFTWARE PACKAGE). IF YOUDO NOT AGREE TO ALL OF THE TERMS SET FORTH IN THE AGREEMENT, DO NOT INSTALL THE SOFTWARE. IF APPLICABLE, YOU MAY RETURNTHE PRODUCT TO MCAFEE OR THE PLACE OF PURCHASE FOR A FULL REFUND.

License Attributions

Refer to the product Release Notes.

McAfee ePolicy Orchestrator 4.02

ContentsIntroducing ePolicy Orchestrator 4.0. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7

Components of ePolicy Orchestrator. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

What's new in this release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

New layout for ePolicy Orchestrator. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Managing User Roles and Permissions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11

ePO user accounts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Global administrators. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

How permission sets work. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Contacts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Organizing the System Tree. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14

The System Tree. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Considerations when planning your System Tree. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Administrator access. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Environmental borders and their impact on system organization. . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Subnets and IP address ranges. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Tags and systems with similar characteristics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Operating systems and software. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Tags and how they work. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Active Directory and NT domain synchronization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Active Directory synchronization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

NT domain synchronization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Distributing Agents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22

Agents and SuperAgents. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

Agent-server communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

SuperAgents and broadcast wake-up calls. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Agent activity logs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

Agent policy settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

Methods of agent distribution. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

Creating Repositories. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29

Repository types and what they do. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

How repositories work together. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3McAfee ePolicy Orchestrator 4.0

Configuring Policies and Client Tasks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32

Extensions and what they do. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

Policy management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

Policy application. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

Client tasks and what they do. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

Deploying Software and Updates. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36

Deployment packages for products and updates. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

Product and update deployment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Setting Up Notifications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39

Notifications and how it works. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Throttling and aggregation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

Notification rules and System Tree scenarios. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

Reporting On System Status. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .42

Queries. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

Public and personal queries. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

Query permissions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

Query Builder. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

Multi-server roll-up querying. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

Detecting Rogue Systems. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .46

What are rogue systems. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

How detected systems are matched and merged. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

Rogue System Detection states. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

Monitoring with Dashboards. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .49

Dashboards and how they work. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

Queries as dashboard monitors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

Default dashboard monitors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

Lab Evaluation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .50

Installing and setting up. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

Configuring your network. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

Getting installation files from McAfee. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

Installing the ePO server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

Starting ePolicy Orchestrator for the first time. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

Creating your System Tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

Adding existing NT domains or Active Directory containers automatically. . . . . . . . . . . . . . . . . . . . . 56

Adding groups and systems manually . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

Organizing server and workstations into groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57


Contents

Organizing systems with tags. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

Deploying agents in your System Tree. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

Configuring the agent policy settings before deployment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

Deploying agents. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

Monitoring agent installations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

Installing agents manually on client systems. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

Setting up a master repository. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

Adding VirusScan to the master repository. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

Pulling updates from the McAfee source repository. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

Setting up a distributed repository. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

Creating a shared folder for the repository. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

Adding the distributed repository to the ePO server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

Replicating master repository data to a distributed repository. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

Configuring remote sites to use the distributed repository. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

Using VirusScan Enterprise with ePolicy Orchestrator. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

Setting VirusScan Enterprise policies before deploying. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

Deploying VirusScan Enterprise to client systems. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

Maintaining and monitoring your environment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

Creating a query to confirm your coverage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

Creating a dashboard to track coverage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

Updating DAT files with a client update task. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

Verifying that VirusScan has updated to the latest DATs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

Scheduling automatic repository synchronization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

Scheduling a pull task to update the master repository daily. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

Scheduling a replication task to update your distributed repository. . . . . . . . . . . . . . . . . . . . . . . . . . 71

Scheduling task chaining to update master and distributed repositories. . . . . . . . . . . . . . . . . . . . . . 71

Configuring global updating with SuperAgents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

Converting an agent on each subnet into a SuperAgent. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

Enabling global updating on the ePO server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

Advanced: Using ePO Notifications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

Configuring Notifications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

Creating a rule for any VirusScan event. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

Providing a sample virus detection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

Advanced: Using Rogue System Detection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

Configuring a Rogue System Detection sensor policy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

Deploying the Rogue System Detection sensor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

Configuring an automatic response. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77


Contents

Reacting to Rogue detection and remediation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78


Contents

Introducing ePolicy Orchestrator 4.0ePolicy Orchestrator 4.0 provides a scalable platform for centralized policy management andenforcement of your security products and the systems on which they reside. It also providescomprehensive reporting and product deployment capabilities, all through a single point ofcontrol.

Contents

Components of ePolicy Orchestrator

What's new in this release

New layout for ePolicy Orchestrator

Components of ePolicy OrchestratorePolicy Orchestrator comprises several components that reside on systems across your network.


ePolicy Orchestrator server

The center of your managed environment. The server delivers security policy, controls updates,processes events, and serves tasks for all managed systems.

Master repository

The central location for all McAfee product installation, update and signature packages, whichare available to managed systems using distributed repositories and agents.

Web-based consoles

The remote access point to the ePolicy Orchestrator server and reports. Use a browser sessionto configure policies, create or edit tasks, and run reports.

Threat notification

An alert message based on threat and compliance events in your environment. ePolicyOrchestrator can alert you immediately to events in your environment via standard emailmessage or SNMP trap.

Distributed repository

Repositories, distributed throughout your environment, provide managed systems access toDAT files, product updates, and product installations. These repositories distribute the impactof updating managed systems.

Rogue System Detection (RSD) sensor

The sensor resides on one system per subnet and notifies you when a rogue system enters theenvironment. It can then initiate an automatic response, such as deploying an agent to thatsystem. (RSD is unavailable at initial release, but is expected soon after.)

McAfee Agent

A vehicle of information and enforcement between the ePolicy Orchestrator server and eachsystem. The agent retrieves updates, ensures task implementation, enforces policy and forwardsevents for each managed system.

What's new in this releaseePolicy Orchestrator 4.0 has been redesigned and offers these enhanced features:

Web-based console

ePolicy Orchestrator has moved from the Microsoft Management Console (MMC) to a web-basedarchitecture.

Directory

The Directory is now the System Tree. Create, populate, and update the System Tree structurewith your Active Directory structure and system placement.

Introducing ePolicy Orchestrator 4.0What's new in this release


Users and permissions

All user accounts are distinct from permissions, which are handled by permission sets. You canassign very granular sets of permissions - for products and features - to any user. All users whoare not global administrators are assigned at least one permission set automatically.

Query system

The ePolicy Orchestrator includes a native query and report system. Included are default queriesand the Query Builder wizard, which allows you to easily create and edit queries. Unlike reportsin previous versions, results are actionable. For example, you can run a query on systems whoseagents haven't communicated with the server in a certain amount of time, then send an agentwake up call to those systems. Additionally, queries can be run on a schedule.

Dashboards

Dashboards that contain multiple monitors provide a quick overview of system status. Createmonitors for any chart-based query, or select one of the default monitors.

Server tasks

You can chain server task actions and subactions within a single task. For example, you canschedule a single server task that runs a pull task, followed by a replication task, and then runsa query against the update status of the distributed repositories and send the results to youvia email.

Tags

Tags are like labels you assign (one or more) to one or more systems manually or based oncriteria at agent-server communication. With tags, you can automatically place systems in theSystem Tree based on any combination of system properties by using criteria-based tags andparallel sorting criteria. Additionally, you can create and run queries on systems based on thetags applied to them.

New layout for ePolicy OrchestratorePolicy Orchestrator 4.0 introduces a redesigned interface and new user experience. Featuresare spread across seven sections of the software. Each contains locations where managedproducts can add functionality. These sections are accessed by the buttons along the top ofthe page after logging on. Functionality available within each section is spread across tabs.

Dashboards

Go to Dashboards to view monitors that display the results of a query and are refreshedautomatically or provide convenient status updates. You can choose from a number of defaultdashboards, or build your own with monitors created from chart-based queries.

Introducing ePolicy Orchestrator 4.0New layout for ePolicy Orchestrator


Reporting

Go to Reporting to view and work with data about your managed environment. In this sectionof the product, you can work with queries, the different logs that are accessible from theinterface, and MyAvert Security Threats.

Software

Go to Software to view and work with repositories and their contents. All deployment andupdating functionality is located here. In addition to existing functionality, you can now changecredentials on multiple distributed repositories at once, and copy only selected packages duringa pull task.

Systems

Go to Systems to organize and work with the managed systems in your environment. UnderSystems, you can work with and assign policies and client tasks, take actions on systems, setup the System Tree, its groups, and any synchronization settings or sorting criteria on them.

Network

Go to Network to view and work with items that apply to your broader environment. For example,if you have multiple ePO servers, you can register them all here for multi-server reportingpurposes.

Automation

Go to Automation to set up those items that run on a schedule or are used in automaticresponses. For example, server tasks and notification rules are both located here.

Configuration

Go to Configuration to set up user accounts, permission sets, contacts, and server settings.These are the global settings that are necessary for your ePO environment.

Introducing ePolicy Orchestrator 4.0New layout for ePolicy Orchestrator


Managing User Roles and PermissionsThe ePO server is the center of your managed environment, providing a single location fromwhich to administer system security throughout your network.

If your organization is very large or divided into multiple large sites, consider installing a separateserver at each site. This can reduce network traffic when managing agents, sending updates,and replicating to distributed repositories within a local LAN. Network traffic has a larger impacton your resources when this communication takes place across WAN, VPN, or other slowernetwork connections typically found between remote sites.

Are you configuring the ePO server for the first time?

When configuring the ePO server for the first time:

1 Decide on how to implement the flexibility of permission sets with user accounts.

2 Create user accounts and permission sets, and assign the permission sets as needed.

3 Set up your contacts list and email server settings.

Contents

ePO user accounts

How permission sets work

Contacts

ePO user accountsUser accounts provide a means for users to access and use the software. They are associatedwith permission sets, which define what users are allowed to do with the software.

You must create user accounts and permission sets to accommodate the needs of each userthat logs on to the ePO server.

There are two types of users, global administrators and everyone else.

Global administratorsGlobal administrators have read and write permissions and rights to all operations. When youinstall the server a global administrator account with the user name admin is created.

You can create additional global administrator accounts for people who require globaladministrative rights.

Permissions exclusive to global administrators include:

• Create, edit, and delete source and fallback sites.


• Change server settings.

• Add and delete user accounts.

• Add, delete, and assign permission sets.

• Import events into ePolicy Orchestrator databases and limit events that are stored there.

How permission sets workA permission set is a group of permissions that can be granted to any users by assigning it tothose users’ accounts. One or more permission sets can be assigned to any users who are notglobal administrators (global administrators have all permissions to all products and features).

Permission sets only grant rights and access — no permission ever removes rights or access.When multiple permission sets are applied to a user account, they aggregate. For example, ifone permission set does not provide any permissions to server tasks, but another permissionset applied to the same account grants all permissions to server tasks, that account has allpermissions to server tasks. Consider this as you plan your strategy for granting permissionsto the users in your environment.

When are permission sets assigned?

Global administrators can assign existing permission sets when creating or editing user accountsand when creating or editing permission sets.

What happens when I install new products?

When a new product extension is installed it may add one or more groups of permissions tothe permission sets. For example, when you install a VirusScan Enterprise extension, a VirusScanEnterprise section is added to each permission set. Initially, the newly added section is listedin each permission set with no permissions yet granted. The global administrators can thengrant permissions to users through existing or new permission sets.

Default permission sets

ePolicy Orchestrator 4.0.2 ships with four default permission sets that provide permissions toePolicy Orchestrator functionality. These are:

• Executive Reviewer — Provides view permissions to dashboards, events, contacts, and canview information that relates to the entire System Tree.

• Global Reviewer — Provides view access globally across functionality, products, and theSystem Tree, except for extensions, multi-server roll-up data, registered servers, and software.

• Group Admin — Provides view and change permissions across ePolicy Orchestrator features.Users that are assigned this permission set each need at least one more permission set thatgrants access needed products and groups of the System Tree.

• Group Reviewer — Provides view permissions across ePolicy Orchestrator features. Usersthat are assigned this permission set each need at least one more permission set that grantsaccess needed products and groups of the System Tree.

Managing User Roles and PermissionsHow permission sets work


ContactsMaintain a list of email addresses that ePolicy Orchestrator uses to send email messages tospecified users in response to events. Currently this list is used by Notifications, queries, andexport functionality.

Managing User Roles and PermissionsContacts


Organizing the System TreeePolicy Orchestrator 4.0.2 provides some new features and improvements to existing featuresto organize and manage your systems.

• The Directory has been replaced by the System Tree — The System Tree allows for easymanagement of policies and tasks, and organization of systems and groups.

• Tags — This new feature allows you to create labels that can be applied to systems manuallyor automatically, based on criteria assigned to the tag. You can sort systems into groupsbased on tags (like IP address sorting), or use tags for criteria in queries.

• NT Domain and Active Directory synchronization — This feature now allows for:

• True synchronization of the Active Directory structure.

• Control of potential duplicate system entries in the System Tree.

• Control of systems in the System Tree when they are deleted from the the domain orcontainer.

• Sorting systems into groups automatically — You can now use tags as sorting criteria inaddition to the previous functionalities of IP address sorting. Each type of sorting criteriacan be used alone or in combination.

The System Tree contains all of the systems managed by ePolicy Orchestrator; it is the primaryinterface for managing policies and tasks on these systems. You can organize systems intological groups (for example, functional department or geographic location) and sort them byIP address or tags. You can manage policies (product configuration settings) and schedule tasks(for example, updating virus definition files) for systems at any level of the System Tree.

Before configuring the software to deploy or manage the security software in your environment,you must plan how to best organize systems for management and select the methods to bringin and keep systems in the System Tree.

TIP: Many factors can influence how you should create and organize your System Tree. McAfeerecommends taking time to review this entire guide before you begin creating your SystemTree.

Are you setting up the System Tree for the first time?

When setting up the System Tree for the first time:

1 Evaluate the methods of populating it with your systems, and keeping it up-to-date. Forexample, through Active Directory synchronization, or criteria-based sorting.

2 Create and populate the System Tree.

Contents

The System Tree


Considerations when planning your System Tree

Tags and how they work

Active Directory and NT domain synchronization

The System TreeThe System Tree organizes managed systems in units for monitoring, assigning policies,scheduling tasks, and taking actions.

Groups

The System Tree is a hierarchical structure that allows you to group your systems within unitscalled groups.

Groups have these characteristics:

• Groups can be created by global administrators or users with the appropriate permissions.

• A group can include both systems and other groups.

• Groups are administered by a global administrator or a user with appropriate permissions.

Grouping systems with similar properties or requirements into these units allows you to managepolicies for systems in one place, rather than setting policies for each system individually.

As part of the planning process, consider the best way to organize systems into groups priorto building the System Tree.

Lost&Found group

The System Tree root (My Organization) includes a Lost&Found group. Depending on themethods for creating and maintaining the System Tree, the server uses different characteristicsto determine where to place systems. The Lost&Found group stores systems whose locationscould not be determined.

The Lost&Found group has the following characteristics:

• It can't be deleted.

• It can't be renamed.

• Its sorting criteria can't be changed (although you can provide sorting criteria for thesubgroups you create within it.)

• It always appears last in the list and is not alphabetized among its peers.

• All users with view permissions to the System Tree can see systems in Lost&Found.

• When a system is sorted into Lost&Found, it is placed in a subgroup named for the system’sdomain. If no such group exists, one is created.

NOTE: If you delete systems from the System Tree, be sure you select the option to removetheir agents. If the agent is not removed, deleted systems reappear in the Lost&Found groupbecause the agent continues to communicate to the server.

Inheritance

Inheritance is an important property that simplifies policy and task administration. Because ofinheritance, child groups in the System Tree hierarchy inherit policies set at their parent groups.For example:

Organizing the System TreeThe System Tree


• Policies set at the My Organization level of the System Tree are inherited by groups belowit.

• Group policies are inherited by subgroups or individual systems within that group.

Inheritance is enabled by default for all groups and individual systems that you add to theSystem 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 SystemTree (provided a user has appropriate permissions) to allow for customization. You can lockpolicy assignments to preserve inheritance.

Considerations when planning your System TreeAn efficient and well-organized System Tree can simplify maintenance. Many administrative,network, and political realities of each environment can affect how your System Tree isstructured. Plan the organization of the System Tree before you build and populate it. Especiallyfor a large network, you want to build the System Tree only once.

Because every network is different and requires different policies — and possibly differentmanagement — McAfee recommends planning your System Tree before implementing thesoftware.

Regardless of the methods you choose to create and populate the System Tree, consider yourenvironment while planning the System Tree.

Administrator accessWhen planning your System Tree organization, consider the access requirements of those whomust manage the systems.

For example, you may have very decentralized network administration in your organization,where different administrators have responsibilities over different parts of the network. Forsecurity reasons, you may not have a global administrator account that can access every partof your network. In this scenario, you may not be able to set policies and deploy agents usinga single global administrator account. Instead, you may need to organize the System Tree intogroups based on these divisions and create accounts and permission sets.

Questions to consider include:

• Who is responsible for managing which systems?

• Who requires access to view information about the systems?

• Who should not have access to the systems and the information about them?

These questions impact both the System Tree organization, and the permission sets you createand apply to user accounts.

Environmental borders and their impact on system organizationHow you organize the systems for management depends on the borders that exist in yournetwork. These borders influence the organization of the System Tree differently than theorganization of your network topology.

McAfee recommends evaluating these borders in your network and organization, and whetherthey must be considered when defining the organization of your System Tree.

Organizing the System TreeConsiderations when planning your System Tree


Topological borders

Your network is already defined by NT domains or Active Directory containers. The betterorganized your network environment, the easier it is to create and maintain the System Treewith the synchronization features.

Geographic borders

Managing security is a constant balance between protection and performance. Organize yourSystem Tree to make the best use of limited network bandwidth. Consider how the serverconnects to all parts of your network, especially remote locations that are often connected byslower WAN or VPN connections, instead of faster LAN connections. You may want to configureupdating and agent-server communication policies differently for remote sites to minimizenetwork traffic over slower connections.

Grouping systems first by geography provides several advantages for configuring policies:

• You can configure update policies for the group so that all systems update from one or moredistributed software repositories located nearby.

• You can schedule client tasks to run at times better suited to the site’s location.

Political borders

Many large networks are divided by individuals or groups responsible for managing differentportions of the network. Sometimes these borders do not coincide with topological or geographicborders. Who accesses and manages the segments of the System Tree affects how you structureit.

Functional borders

Some networks are divided by the roles of those using the network; for example, Sales andEngineering. Even if the network is not divided by functional borders, you may need to organizesegments of the System Tree by functionality if different groups require different policies.

A business group may run specific software that requires special security policies. For example,arranging your email Exchange Servers into a group and setting specific exclusions for VirusScanEnterprise on-access scanning.

Subnets and IP address rangesIn many cases, organizational units of a network use specific subnets or IP ranges, so you cancreate a group for a geographic location and set IP filters for it. Also, if your network isn’t spreadout geographically, you can use network location, such as IP address, as the primary groupingcriterion.

If possible, consider using sorting criteria based on IP address information to automate SystemTree creation and maintenance. Set IP subnet masks or IP address range criteria for applicablegroups within the System Tree. These filters automatically populate locations with the appropriatesystems.

Tags and systems with similar characteristicsYou can use tags for automated sorting into groups. Tags identify systems with similarcharacteristics. If you can organize your groups by characteristics, you can create and assigntags based on that criteria, then use these tags as group sorting criteria to ensure systems areautomatically placed within the appropriate groups.

Organizing the System TreeConsiderations when planning your System Tree


If possible, consider using tag-based sorting criteria to automatically populate groups with theappropriate systems.

Operating systems and softwareConsider grouping systems with similar operating systems to manage operating system-specificproducts and policies more easily. If you have legacy systems, you can create a group for themand deploy and manage security products on these systems separately. Additionally, by givingthese systems a corresponding tag, you can automatically sort them into a group.

Tags and how they workTags are a new feature of ePolicy Orchestrator 4.0.2. Tags are like labels that you can applyto one or more systems, automatically (based on criteria) or manually. Once tags are applied,you can use them organize systems in the System Tree or run queries that result in an actionablelist of systems. Therefore, with tags as organizational criteria, you can apply policies, assigntasks, and take a number of actions on systems with the same tags.

Traits of tags

With tags, you can:

• Apply one or more tags to one or more systems.

• Apply tags manually.

• Apply tags automatically, based on user-defined criteria, when the agent communicates withthe server.

• Exclude systems from tag application.

• Run queries to group systems with certain tags, then take direct action on the resulting listof systems.

• Base System Tree sorting criteria on tags to group systems into desired System Tree groupsautomatically.

Who can use tags

Users with appropriate permissions 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 withinthe parts of the System Tree to which they have access.

• Configure sorting criteria based on tags to ensure systems stay in the appropriate groupsof the System Tree.

Types of tags

There are two types of tags:

Organizing the System TreeTags and how they work


• Tags without criteria. These tags can be applied only to selected systems in the System Tree(manually) and systems listed in the results of a query.

• Criteria-based tags. These tags are applied to all non-excluded systems at each agent-servercommunication. Such tags use criteria based on any properties sent by agent. They can alsobe applied to non-excluded systems on demand.

Active Directory and NT domain synchronizationePolicy Orchestrator 4.0.2 offers improved integration with both Active Directory and NT domainsas a source for systems, and even (in the case of Active Directory) as a source for the structureof the System Tree.

Active Directory synchronizationIf your network runs Active Directory, you can use Active Directory synchronization to create,populate, and maintain part or all of the System Tree with Active Directory synchronizationsettings. Once defined, the System Tree is updated with any new systems (and subcontainers)in your Active Directory.

Active Directory integration is enhanced with the release of ePolicy Orchestrator 4.0.2. Inaddition to previous functionality, you can now:

• Synchronize with your Active Directory structure, by importing systems and the ActiveDirectory subcontainers (as System Tree groups) and keeping them up-to-date with ActiveDirectory. At each synchronization, both systems and the structure are updated in the SystemTree to reflect the systems and structure of Active Directory.

• Import systems as a flat list from the Active Directory container (and its subcontainers) intothe synchronized group.

• Control what to do with potential duplicate systems.

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

In previous versions of ePolicy Orchestrator, there were the two tasks: Active Directory Importand Active Directory Discovery. Now, use this process to integrate the System Tree with yourActive Directory systems structure:

1 Configure the synchronization settings on each group that is a mapping point in the SystemTree. At the same location, you can configure whether to:

2 Deploy agents to discovered systems.•

• Delete systems from the System Tree when they are deleted from Active Directory.

• Allow or disallow duplicate entries of systems that already exist elsewhere in the SystemTree.

3 Use the Synchronize Now action to import Active Directory systems (and possibly structure)into the System Tree according to the synchronization settings.

4 Use an NT Domain/Active Directory Synchronization server task to regularly synchronizethe systems (and possibly the Active Directory structure) with the System Tree accordingto the synchronization settings.

Organizing the System TreeActive Directory and NT domain synchronization


Types of Active Directory synchronizationThere are two types of Active Directory synchronization (systems only and systems andstructure). Which one you use depends on the level of integration you want with Active Directory.

With each type, you control the synchronization by selecting whether to:

• Deploy agents automatically to systems new to ePolicy Orchestrator. You may not want toset this on the initial synchronization if you are importing a large number of systems andhave limited bandwidth. The agent installation package is about 3.62 MB in size. However,you may want to deploy agents automatically to any new systems that are discovered inActive Directory during subsequent synchronizations.

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

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

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

Systems and structureWhen using this synchronization type, changes in the Active Directory structure are carried overinto your System Tree structure at the next synchronization. When systems or containers areadded, moved, or removed in Active Directory, they are added, moved, or removed in thecorresponding locations of the System Tree.

When to use this synchronization type

Use this to ensure the System Tree (or parts of it) look exactly like your Active Directory structure.

If the organization of Active Directory meets your security management needs and you wantthe System Tree to continue to look like the mapped Active Directory structure, use thissynchronization type with subsequent synchronizations.

Systems onlyUse this synchronization type to import systems from an Active Directory container, includingthose in non-excluded subcontainers, as a flat list to a mapped System Tree group. You canthen move these to the desired locations in the System Tree by assigning sorting criteria togroups.

If you choose this synchronization type, be sure to select not to add systems again if they existelsewhere 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 forePolicy Orchestrator, but the organizational needs for security management do not coincidewith the organization of containers and systems in Active Directory.

NT domain synchronizationUse your NT domains as a source for populating your System Tree. When you synchronize agroup to an NT domain, all systems from the domain are put in the group as a flat list. You canmanage those systems in the single group, or you can create subgroups for more granular



organizational needs. Use a method, like automatic sorting to populate these subgroupsautomatically.

If you move systems to other groups or subgroups of the System Tree, be sure to select to notadd the systems when they already exist elsewhere in the System Tree.

Unlike Active Directory synchronization, only the system names are synchronized with NT domainsynchronization — the system description is not synchronized.



Distributing AgentsManaging your network systems effectively is dependent on each system running an active,up-to-date agent.

There are several methods to distribute the agent. The ones you use depend on:

• The realities of your environment.

• Whether you are upgrading agents or distributing them for the first time.

Are you distributing agents for the first time?

When deploying agents throughout your environment for the first time:

1 Configure agent policy settings for the System Tree groups to which you are distributingagents.

2 Distribute agents with the chosen methods to the desired locations.

Contents

Agents and SuperAgents

Agent-server communication

Agent activity logs

Agent policy settings

Methods of agent distribution

Agents and SuperAgentsThe agent is the distributed component of ePolicy Orchestrator that must be installed on eachsystem in your network that you want to manage. A SuperAgent is an agent that is enabled tobroadcast wake-up calls by network broadcast segment. SuperAgents can also be used asrepositories from which to distribute products and updates.

The agent collects and sends information among the ePO server, update repositories, managedsystems, and products. Systems cannot be managed by ePolicy Orchestrator without an installedagent.

Agent language packages

Agent installation packages, both default and custom, install in English. These are in the masterrepository by default for clean installations.

Each agent language package includes only those files needed to display the user interface inthat language. Agent language packages can be replicated to distributed repositories.


After the initial agent-server communication, the agent retrieves the new package thatcorresponds to the in-use locale and applies it. In this way, the agents retrieve only languagepackages for the locales being used on each managed system.

NOTE: The interface continues to appear in the current language until the new language packagehas been applied.

Multiple language packages can be stored on managed systems to allow users to switchlanguages by changing the locale. If a locale is selected for which a language package is notavailable locally, the interface appears in English.

Agent language packages are available for these languages:

• Italian• Brazilian Portuguese

• Chinese (Simplified) • Japanese

• Korean• Chinese (Traditional)

• English • Polish

• Spanish• Dutch

• French (Standard) • Swedish

• German (Standard)

The agent installation package

The FRAMEPKG.EXE file is created when you install the server. It is a customized installationpackage for agents that report to your server. The package contains the server name, its IPaddress, ASCI port number, and other information that allows the agent to communicate withthe server.

By default, the agent installation package is installed in this location:C:\PROGRAM FILES\MCAFEE\EPO\DB\SOFTWARE\CURRENT\ ePOAGENT3000\INSTALL\0409\FRAMEPKG.EXE

This is the installation package that the server uses to deploy agents.

The default agent installation package contains no embedded user credentials. When executedon the system, the installation uses the account of the currently logged-on user.

Agent-server communicationDuring agent-server communication, the agent and server exchange information using SPIPE,a proprietary network protocol used by ePolicy Orchestrator for secure network transmissions.At each communication, the agent collects its current system properties, as well as any events,and sends them to the server. The server sends any new or changed policies, tasks, andrepository list to the agent. The agent then enforces the new policies locally on the managedsystem.

Agent-server communication can be initiated in these ways:

• Agent-to-server communication interval (ASCI)

• Agent-initiated communication after agent startup

• Agent wake-up calls

• Communication initiated manually from the managed system

Distributing AgentsAgent-server communication


Agent-to-server-communication interval

The agent-to-server-communication interval (ASCI) is set on the General tab of the McAfeeAgent policy pages. This setting determines how often the agent calls into the server for dataexchange and updated instructions. By default, the ASCI is set to 60 minutes; the agent checksinto the server once every hour.

When deciding whether to modify this policy setting, you must consider your organization’sthreat response requirements, available bandwidth, total number of managed systems, and thehardware hosting the server. Be aware that ASCI communication can generate significantnetwork traffic, especially in a large network. In such a case, you probably have agents inremote sites connecting over slower network connections. For these agents, you may want toset a less frequent ASCI. The following table lists general ASCI recommendations for commonnetwork connection speeds.

General recommended ASCI settings

Recommended ASCINetwork Size

60 minutesGigabit LAN

60 minutes100mb LAN

360 minutesWAN

360 minutesDial-up or RAS

180 minutes10mb LAN

150 minutesWireless LAN

NOTE: For complete information on balancing bandwidth, server hardware, and ASCIdetermination, see the ePolicy Orchestrator 4.0.2 Hardware Sizing and Bandwidth Usage Guide.

Agent-initiated after agent startup

After the installation, and after the agent service is stopped and restarted, the agent calls intothe server at a randomized interval within ten minutes. Subsequent communications occur withthe ASCI set in the agent policy (60 minutes by default).

Wake-up calls

Wake-up calls prompt the agents to call in to the server. Wake-up calls can be sent manuallyor scheduled as a client task. These are useful when you have made policy changes or checkedin updates that you want to apply to the managed systems sooner than the next ASCI.

Wake-up calls can also configured on query results which are scheduled in the Server TaskBuilder wizard.

Communication initiated manually from the managed system

You can manually initiate communication from the system on which the McAfee Agent is installedwith the McAfee Agent monitor, by selecting Update Now on the agent menu, or by runningC:\Program Files\McAfee\Common Framework\CMDAGENT.EXE with the /P command-line option.



SuperAgents and broadcast wake-up callsIf you plan to use agent wake-up calls to initiate agent-server communication, consider convertingan agent on each network broadcast segment into a SuperAgent. SuperAgents distribute thebandwidth impact of the agent wake-up call, minimizing network traffic.

Instead of sending agent wake-up calls from the server to every agent, the server sends theSuperAgent wake-up call to SuperAgents in the selected System Tree segment. WhenSuperAgents receive this wake-up call they send broadcast wake-up calls to all the agents intheir network broadcast segments. This reduces network traffic. This is beneficial in largenetworks where ePolicy Orchestrator may manage agents in remote sites over lower-speedWAN or VPN connections.

Figure 1: SuperAgent and Broadcast Wake-Up Calls

1 Server sends a wake-up call to all SuperAgents.

2 SuperAgents send a broadcast wake-up call to all agents in the same broadcast segment.

3 All agents (regular agents and SuperAgents) exchange data with the server.

4 Any agents without an operating SuperAgent on their broadcast segment are not promptedto communicate with the server. (These systems require a standard wake-up call).

Best practices

To deploy sufficient numbers of SuperAgents to the appropriate locations, first determine thebroadcast segments in your environment and select a system (preferably a server) in each to



host a SuperAgent. Be aware that agents in broadcast segments without SuperAgents do notreceive the broadcast wake-up call, and therefore, do not call in to the server.

Similar to the regular agent wake-up call, the SuperAgent wake-up call uses the SPIPE protocol.Ensure the agent wake-up communication port (8081 by default) and the agent broadcastcommunication port (8082 by default) are not blocked.

Agent activity logsThe agent log files are useful for determining agent status or troubleshooting. Two log filesrecord agent activity, both are located in the agent installation folders on the managed system.

Agent activity log

The agent activity log is an XML file named agent_<system>.xml where <system> is theNetBIOS name of the system on which the agent is installed. This log file records agent activityrelated to things such as policy enforcement, agent-server communication, and event forwarding.You can define a size limit of this log file.

On the Logging tab of the McAfee Agent policy pages, you can configure the level of agentactivity that is recorded.

Detailed agent activity log

The detailed agent activity log is named agent_<system>.log file where <system> is theNetBIOS name of the system on which the agent is installed. In addition to the informationstored in the agent activity log, the detailed activity log contains troubleshooting messages.This file has a 1MB size limit. When this log file reaches 1MB, a backup copy is made(agent_<system>_backup.log).

Agent policy settingsAgent policy settings determine agent performance and behavior in your environment, including:

• How often the agent calls in to the server.

• How often the agent enforces policies on the managed system.

• How often the agent delivers event files to the server.

• Where the agent goes for product and update packages.

Before distributing a large number of agents throughout your network, consider carefully howyou want the agent to behave in the segments of your environment. Although you can configureagent policy after agents are distributed, McAfee recommends setting agent policy prior to thedistribution to prevent unnecessary resource impact.

For complete descriptions of options on the agent policy pages, click ? on the page displayingthe options. However, some of the most important policy settings are discussed here.

Priority event forwarding

The agent and security software on the managed system generate software events constantlyduring normal operation. These can range from information events about regular operation,such as when the agent enforces policies locally, to critical events, such as when a virus isdetected and not cleaned. These events are sent to the server at each agent-server

Distributing AgentsAgent activity logs


communication and stored in the database. A typical deployment of ePolicy Orchestrator in alarge network can generate thousands of these events an hour. Most likely, you won’t want tosee each of these.

Typically, you may want to know about higher severity events immediately. You can configurethe agent to forward events that are equal to or greater than a specified severity immediately(specific event severities are determined by the product generating the events). If you plan touse Notifications, enabling immediate uploading of higher severity events is necessary for thosefeatures to function as intended.

You can enable immediate uploading of events on the Events tab of the McAfee Agent policypages.

Agent policy and distributed repositories

By default, the agent can update from any repository in its repository list (SITELIST.XML) file.The agent can use a network ICMP ping command or the repository’s subnet address todetermine the distributed repository with the fastest response time out of the top five repositoriesin the list. Usually, this is the distributed repository that is closest to the system on the network.For example, a managed system in a remote site far from the ePO server probably selects alocal distributed repository. By contrast, an agent in the same LAN as the server probablyupdates directly from the master repository.

If you require tighter control over which distributed repositories the agents use, you can enableor disable specific distributed repositories on the Repositories tab of the McAfee Agent policypages, or specify the order in which repositories are used. Allowing agents to update from anydistributed repository ensures they get the update from some location. Using a network ICMPping, the agent should update from the closest distributed repository from the top five in therepository list. The agent selects a repository each time the agent service (McAfee FrameworkService) starts or when the repository list changes.

Proxy settings

To access the McAfee update sites, the agent must be able to access the Internet. Use theagent policy settings to configure proxy server settings for the managed systems. The Proxytab of the McAfee Agent policy pages includes settings to:

• Use Internet Explorer proxy settings.

• Configure custom proxy settings.

• Disable any proxy use.

The default setting is Use Internet Explorer Proxy Settings, allowing an agent to use thecurrent proxy server location and credential information currently configured in the InternetExplorer browser installed on that system. However, you may need to use ePolicy Orchestratorto configure custom proxy server settings for systems in your network. For example, maybethey use a different browser and don’t have Internet Explorer installed.

Methods of agent distributionDue to the variety of scenarios and requirements of different environments, there are severalmethods you can use to distribute the agent to the systems you want to manage. Before usingany of these methods, you should consider each.

Distributing AgentsMethods of agent distribution


The following table details the advantages and disadvantages of the different methods todistribute the agent.

Table 1: Advantages and disadvantages of agent distribution methodsDisadvantagesAdvantagesMethod

If you are creating sites by importing large NTdomains or Active Directory containers, too

Automatic; no other steps are required.Deploying agents whilecreating Directory

much network traffic may be generated for yourresources.

You must embed user credentials withadministrator rights to the desired systems.

This is an efficient method for distributingthe agent, assuming you used a phasedapproach for large deployments.

Deploying agents fromePolicy Orchestrator

Also, you must ensure that systems runningMicrosoft XP Service Pack 2, have theFRAMEPKG.EXE file added to the firewallexceptions list.

Systems that don’t log on to the networkfrequently, may not be running the mostup-to-date agent.

This is an efficient method for anenvironment where systems log on to thenetwork frequently. You do the workonce, and the agent is deployedautomatically.

Using login scripts

This is not a time-efficient method if you havemany systems.

This is an efficient method if you are notusing ePolicy Orchestrator to deploy theagent.

Installing manually

If you do not use images consistently, thismethod would not be efficient to ensurecoverage.

Prevents the bandwidth impact that otherforms of distribution can cause. Reducesthe overhead by integrating the task intoanother.

Including the agent on animage

The disabled agent may be out-of-date andrequire you run the deployment task to upgrade

Saves significant bandwidth and time.Enabling the agent onunmanaged McAfeeproducts the agent to the current release. You cannot

change the agent installation folder withoutremoving and reinstalling the agent. Agentsthat you enable may be located in a differentfolder than agents that you deploy in yournetwork by some other method.

Distributing AgentsMethods of agent distribution


Creating RepositoriesSecurity software is only as effective as the latest installed updates. For example, if your DATfiles are out-of-date, even the best anti-virus software cannot detect new threats. It is criticalthat you develop a robust updating strategy to keep your security software as current as possible.

ePolicy Orchestrator repository architecture offers flexibility to ensure deploying and updatingsoftware is as easy and automated as your environment allows. Once your repositoryinfrastructure is in place, create update tasks that determine how, where, and when yoursoftware is updated.

Are you creating repositories for the first time?

When creating and setting up repositories for the first time:

1 Decide which types of repositories to use and their locations.

2 Create and populate your repositories.

Contents

Repository types and what they do

How repositories work together

Repository types and what they doTo deliver products and updates throughout your network, ePolicy Orchestrator offers severaltypes of repositories that create a robust update infrastructure when used together. Theseprovide the flexibility to develop an updating strategy to ensure your systems stay up-to-date.

Master repository

The master repository maintains the latest versions of security software and updates for yourenvironment. This repository is the source for the rest of your environment.

The master repository is configured when ePolicy Orchestrator is installed. However, you mustensure that proxy server settings are configured correctly. By default, ePolicy Orchestrator usesMicrosoft Internet Explorer proxy settings.

Distributed repositories

Distributed repositories host copies of your master repository’s contents. Consider usingdistributed repositories and placing them throughout your network strategically to ensuremanaged systems are updated while network traffic is minimized, especially across slowconnections.


As you update your master repository, ePolicy Orchestrator replicates the contents to thedistributed repositories.

Replication can occur:

• Automatically when specified package types are checked in to the master repository withglobal updating enabled.

• On a recurring schedule with Replication tasks.

• Manually, by running a Replicate Now task.

A large organization can have multiple locations with limited bandwidth connections betweenthem. Distributed repositories help reduce updating traffic across low-bandwidth connections,or at remote sites with a large number of client systems. If you create a distributed repositoryin the remote location and configure the systems within the remote location to update fromthis distributed repository, the updates are copied across the slow connection only once — tothe distributed repository — instead of once to each system in the remote location.

If global updating is enabled, distributed repositories update managed systems automatically,as soon as selected updates and packages are checked into the master repository. You do notneed to spend additional time creating and configuring repositories or the update tasks.

Source site

The source site provides all updates for your master repository. The default source site is theMcAfeeHttp update site, but you can change the source site or create multiple source sites ifyou require. McAfee recommends using the McAfeeHttp or McAfeeFtp update sites as yoursource site.

NOTE: Source sites are not required. You can download updates manually and check them into your master repository. However, using a source site automates this process.

McAfee posts software updates to these sites regularly. For example, DAT files are posted daily.Update your master repository with updates as they are available.

Use pull tasks to copy source site contents to the master repository.

The McAfee update sites provide detection definition (DAT) and scanning engine file updates,as well as some language packs. You must check in all other packages and updates, includingservice packs and patches, to the master repository manually.

Fallback site

The fallback site is a source site that’s been enabled as the fallback, from which managedsystems can retrieve updates when their usual repositories are inaccessible. For example, whennetwork outages or virus outbreaks occur, accessing the established location may be difficult.Therefore, managed systems can remain up-to-date in such situations. The default fallback siteis the McAfee HTTP (McAfeeHttp) update site. You can enable only one fallback site.

If managed systems use a proxy server to access the Internet, you must configure agent policysettings for those systems to use proxy servers when accessing this fallback site.

Creating RepositoriesRepository types and what they do


How repositories work togetherThe repositories work together in your environment to deliver updates and software to managedsystems. Depending on the size and geography of your network, you may or may not needdistributed repositories.

Figure 2: Sites and Repositories Delivering Packages to Systems

1 The master repository regularly pulls DAT and engine update files from the source site.

2 The master repository replicates the packages to distributed repositories in the network.

3 The managed systems in the network retrieve updates from a close repository. If managedsystems can’t access the distributed repositories or the master repository, they retrieveupdates from the fallback site.

Creating RepositoriesHow repositories work together


Configuring Policies and Client TasksManaging products from a single location is a central feature of ePolicy Orchestrator and isaccomplished through the combination of product policies and client tasks. Policies ensure aproduct’s features are configured correctly, while client tasks are the scheduled actions thatrun on the managed systems hosting any client-side software.

Are you configuring policies and tasks for the first time?

When configuring policies and tasks for the first time:

1 Plan product policies and client tasks for the segments of your System Tree.

2 Create and assign policies to groups and systems.

3 Create and assign client tasks to groups and systems.

Contents

Extensions and what they do

Policy management

Policy application

Client tasks and what they do

Extensions and what they doExtensions are ZIP files you install on the ePO server in order to manage another securityproduct in your environment. The extensions contain the files, components, and informationnecessary to manage such a product. Extensions replace the NAP files of previous releases.

What functionality extensions add

When a managed product extension is installed, functionalities added can include:

• Policy pages.

• Server tasks.

• Client tasks.

• Default queries.

• New result types, chart types, and properties to select with the Query Builder wizard.

• Default Dashboards and dashboard monitors.

• Feature permissions that can be assigned to user accounts.


• Additional product-specific functionalities.

Where extension files are located

Some extensions are installed automatically when ePolicy Orchestrator is installed. For productswhose extensions are not installed by default, see the product documentation for the nameand its location on the product CD or in the product download.

Policy managementA policy is a collection of settings that you create, configure, then enforce. Policies ensure thatthe managed security software products are configured and perform accordingly.

Some policy settings are the same as the settings you configure in the interface of the productinstalled on the managed system. Other policy settings are the primary interface for configuringthe product or component. The ePolicy Orchestrator console allows you to configure policysettings for all products and systems from a central location.

Policy categories

Policy settings for most products are grouped by category. Each policy category refers to aspecific subset of policy settings. Policies are created by category. In the Policy Catalog page,policies are displayed by product and category. When you open an existing policy or create anew policy, the policy settings are organized across tabs.

Where policies are displayed

To see all of the policies that have been created per policy category, go to the Systems |Policy Catalog page, then select the desired Product and Category from the drop-downlists. On the Policy Catalog page, users can see only policies of the products to which theyhave permissions.

To see which policies, per product, are applied to a specific group of the System Tree, go tothe Systems | System Tree | Policies page, select the desired group, then select the desiredProduct from the drop-down list.

NOTE: A McAfee Default policy exists for each category. You cannot delete, edit, export orrename these policies, but you can copy and edit them.

Setting policy enforcement

For each managed product or component, choose whether the agent enforces all or none ofits policy selections for that product or component.

From the Policies page, choose whether to enforce policies for products or components onthe selected group.

In the Policy Catalog page, you can view policy assignments, where they are applied and ifthey are enforced.

When policies are enforced

When you reconfigure policy settings, the new settings are delivered to, and enforced on, themanaged systems at the next agent-server communication. The frequency of this communicationis determined by the Agent-to-server-communication interval settings on the Generaltab of the McAfee Agent policy pages, or the Agent Wakeup task schedule (depending on

Configuring Policies and Client TasksPolicy management


how you implement agent-server communication). This interval is set to occur once every 60minutes by default.

Once the policy settings are in effect on the managed system, the agent continues to enforcepolicy settings locally at a regular interval. This enforcement interval is determined by the Policyenforcement interval setting on the General tab of the McAfee Agentpolicy pages. Thisinterval is set to occur every five minutes by default.

Policy settings for McAfee products are enforced immediately at the policy enforcement intervaland at each agent-server communication if policy settings have changed.

NOTE: There is a delay of up to three minutes after the interval before policies for SymantecAntiVirus products are enforced. The agent first updates the GRC.DAT file with policy information,then the Symantec AntiVirus product reads the policy information from the GRC.DAT file, whichoccurs approximately every three minutes.

Exporting and importing policies

If you have multiple servers, you can export and import policies between them via XML files.In such an environment, you only need to create a policy once.

You can export and import individual policies, or all policies for a given product.

This feature can also be used to back up policies if you need to re-install the server.

Policy applicationPolicies are applied to any system by one of two methods, inheritance or assignment.

Inheritance

Inheritance determines whether the policy settings and client tasks for a group or system aretaken from its parent. By default, inheritance is enabled throughout the System Tree.

When you break this inheritance by assigning a new policy anywhere in the System Tree, allchild groups and systems that are set to inherit the policy from this assignment point do so.

Assignment

You can assign any policy in the Policy Catalog to any group or system (provided you have theappropriate permissions). Assignment allows you to define policy settings once for a specificneed, then apply the policy to multiple locations.

When you assign a new policy to a particular group of the System Tree, all child groups andsystems that are set to inherit the policy from this assignment point do so.

Assignment locking

You can lock the assignment of a policy on any group or system (provided you have theappropriate permissions). Assignment locking prevents other users:

• With appropriate permissions at the same level of the System Tree from inadvertentlyreplacing a policy.

• With lesser permissions (or the same permissions but at a lower level of the System Tree)from replacing the policy.

Assignment locking is inherited with the policy settings.

Configuring Policies and Client TasksPolicy application


Assignment locking is valuable when you want to assign a certain policy at the top of the SystemTree and ensure no other users replace it anywhere in the System Tree.

Assignment locking only locks the assignment of the policy, but does not prevent the policyowner from making changes to its settings. Therefore, if you intend to lock a policy assignment,ensure that you are the owner of the policy.

Policy ownership

All policies for products and features to which you have permissions are available from thePolicy Catalog page. To prevent any user from editing other users’ policies, each policy isassigned an owner — the user who created it.

Ownership provides that no one can modify or delete a policy except its creator or a globaladministrator. Any user (with appropriate permissions) can assign any policy in the PolicyCatalog page, but only the owner or a global administrator can edit it.

If you assign a policy that you do not own to managed systems, be aware that if the owner ofthe named policy modifies it, all systems where this policy is assigned receive these modifications.

Therefore, if you wish to use a policy owned by a different user, McAfee recommends that youfirst duplicate the policy, then assign the duplicate to the desired locations. This provides youownership of the assigned policy.

Client tasks and what they doePolicy Orchestrator allows you to create and schedule client tasks that run on managed systems.

You can define tasks for the entire System Tree, a specific group, or an individual system. Likepolicy settings, client tasks are inherited from parent groups in the System Tree.

Which extension files are installed on your ePO server determines which client tasks are available.

Client tasks are commonly used for:

• Product deployment.

• Product functionality. (For example, the VirusScan Enterprise On-Demand Scan task.)

• Upgrades and updates.

See the product documentation for your managed products for information and instructions.

Configuring Policies and Client TasksClient tasks and what they do


Deploying Software and UpdatesIn addition to managing security products, ePolicy Orchestrator can deploy products to yournetwork systems. Use ePolicy Orchestrator to deploy products and their updates.

Are you deploying products for the first time?

When deploying products for the first time:

1 Configure pull and replication tasks.

2 Check in product and update packages to the master repository.

3 Configure deployment and update tasks.

Contents

Deployment packages for products and updates

Product and update deployment

Deployment packages for products and updatesThe ePolicy Orchestrator deployment infrastructure supports deploying products and components,as well as updating both.

Each McAfee product that ePolicy Orchestrator can deploy provides a product deploymentpackage ZIP file. ePolicy Orchestrator can deploy these packages to any of your managedsystems, once they are checked in to the master repository. The ZIP file contains the productinstallation files, which are compressed in a secure format.

ZIP files are used for both detection definition (DAT) and engine update packages.

You can configure product policy settings before or after deployment. McAfee recommendsconfiguring policy settings before deploying the product to network systems. This saves timeand ensures that your systems are protected as soon as possible.

These package types can be checked in to the master repository with pull tasks, or manually.

Supported package types

OriginationDescriptionPackage type

McAfeeFtp and McAfeeHttp update sites,and the McAfee website. Use a pull task

The regular, daily DAT files released byMcAfee.

Detection definition (DAT) files

File type: ZIPto download DAT files directly into themaster repository, or download and checkthem into the master repository manually.


OriginationDescriptionPackage type

McAfeeFtp and McAfeeHttp update sites,and the McAfee website. Use a pull task

The updated scanning engine forMcAfee anti-virus products, such as

Scanning engine

File type: ZIPto download engine files directly into themaster repository, or download and checkthem into the master repository manually.

VirusScan Enterprise. Engines areusually updated once or twice a year.

McAfee website. Download and checkSuperDAT files into the master repositorymanually.

The SuperDAT files contain both DATand engine files in one update package.If bandwidth is a concern, McAfeerecommends updating DAT and enginefiles separately.

SuperDAT (SDAT.EXE) files

File type: SDAT.EXE

McAfee website. Download and checksupplemental virus definition files in to themaster repository manually.

The EXTRA.DAT files address one ormore specific threats that haveappeared since the last DAT file wasposted. If the threat has a high severity,

Supplemental detectiondefinition (EXTRA.DAT) files

File type: EXTRA.DAT

distribute the EXTRA.DAT immediately,rather than wait until that signature isadded to the next DAT file. EXTRA.DATfiles are from the McAfee website. Youcan distribute them through ePolicyOrchestrator. Pull tasks do not retrieveEXTRA.DAT files.

Product CD or downloaded product ZIPfile. Check product deployment packages

A product deployment package containsthe installation software of a McAfeeproduct.

Product deployment packages

File type: ZIPin to the master repository manually. Forspecific locations, see the documentationfor that product. Only the agent andSystem Compliance Profiler deploymentpackages are checked in to the masterrepository as part of the ePO serverinstallation.

Master repository — checked in atinstallation. For future versions of the

An agent installation package containsthe installation software for the agent.

Agent installation package

File type: ZIPagent, you must check agent installationpackages in to the master repositorymanually.

Master repository — checked in atinstallation. For future versions of the

An agent language package containsfiles necessary to display agentinformation in a local language.

Agent language packages

File type: ZIPagent, you must check agent languagepackages into the master repositorymanually.

Package signing and security

All packages created and distributed by McAfee are signed with a key pair using the DSA (DigitalSignature Algorithm) signature verification system, and are encrypted using 168-bit 3DESencryption. A key is used to encrypt or decrypt sensitive data.

You are notified when you check in packages that are not signed by McAfee. If you are confidentof the content and validity of the package, continue with the check-in process. These packagesare secured in the same manner described above, but are signed by ePolicy Orchestrator whenthey are checked in.

Digital signatures guarantee that packages originated from McAfee or were checked in by you,and that they have not been tampered with or corrupted. The agent only trusts package filessigned by ePolicy Orchestrator or McAfee. This protects your network from receiving packagesfrom unsigned or untrusted sources.

Deploying Software and UpdatesDeployment packages for products and updates


Package ordering and dependencies

If one product update is dependent on another, you must check in their packages to the masterrepository in the required order. For example, if Patch 2 requires Patch 1, you must check inPatch 1 before Patch 2. Packages cannot be reordered once they are checked in. You mustremove them and check them in again, in the proper order. If you check in a package thatsupersedes an existing package, the existing package is removed automatically.

Product and update deploymentThe ePO repository infrastructure allows you to deploy product and update packages to yourmanaged systems from a central location. Although the same repositories are used, there aredifferences.

Comparison of product deployment and update packages

Update packagesProduct deployment packages

DAT and engine update packages can be copied from thesource site automatically with a pull task. All other update

Must be manually checked in to the master repository.

packages must be checked in to the master repositorymanually.

Can be replicated to the distributed repositories andinstalled automatically on managed systems with globalupdating.

Can be replicated to the distributed repositories andinstalled on managed systems with global updating.

If not implementing global updating for product updating,an update client task must be configured and scheduledfor managed systems to retrieve the package.

If not implementing global updating for productdeployment, a deployment task must be configured andscheduled for managed systems to retrieve the package.

Product deployment and updating process

Follow this high-level process for distributing DAT and engine update packages:

1 Check in the update package to the master repository with a pull task or manually.

2 Do one of the following:

• If using global updating, nothing else is required for systems on the network. You should,however, create and schedule an update task for laptop systems that leave the network.

• If not using global updating, use a replication task to copy the contents of the masterrepository to the distributed repositories, then create and schedule an update task foragents to retrieve and install the update on managed systems.

Deploying Software and UpdatesProduct and update deployment


Setting Up NotificationsThe ePolicy Orchestrator Notifications feature alerts you to events that occur on your managedsystems or on the ePolicy Orchestrator server . You can configure notification rules in ePolicyOrchestrator to send email messages or SNMP traps, as well as run external commands whenspecific events are received and processed by the ePolicy Orchestrator server. The ability tospecify the event categories that generate a notification message and the frequencies withwhich such messages are sent are highly configurable.

This feature is designed to notify specific individuals when the conditions of a rule are met.These include, but are not limited to:

• Detection of threats by your anti-virus software product. Although many anti-virus softwareproducts are supported, events from VirusScan Enterprise include the IP address of thesource attacker so that you can isolate the system infecting the rest of your environment.

• Outbreak situations. For example, 1000 virus detected events are received within five minutes.

• High-level compliance of ePolicy Orchestrator server events. For example, a replication taskwas not completed.

You can also configure notification rules to execute commands and launch registered executableswhen the specified conditions are met.

Are you setting up Notifications for the first time?

When setting up Notifications for the first time:

1 Understand Notifications and how it works with the System Tree and your network.

2 Plan your implementation. Which users need to know about which events?

3 Define an SNMP server, registered executables, and external commands if you plan toimplement Notifications features that use them.

4 Create notification rules.

Contents

Notifications and how it works

Notifications and how it worksBefore you plan the implementation of Notifications, you should understand how this featureworks with ePolicy Orchestrator and the System Tree.

NOTE: This feature does not follow the inheritance model of policy enforcement.


Events that occur on systems in your environment are delivered to the server, and the notificationrules (associated with the group that contains the affected systems and each parent above it)are triggered by the events. If the conditions of any such rule are met, a notification messageis sent, or an external command is run, per the rule’s configurations.

This design allows you to configure independent rules at the different levels of the System Tree.These rules can have different:

• Thresholds for sending a notification message. For example, an administrator of a particulargroup wants to be notified if viruses are detected on 100 systems within 10 minutes on thegroup, but a global administrator does not want to be notified unless viruses are detectedon 1000 systems within the entire environment in the same amount of time.

• Recipients for the notification message. For example, an administrator for a particular groupwants to receive a notification message only if a specified number of virus detection eventsoccur within the group. Or, a global administrator wants each group administrator to receivea notification message if a specified number of virus detection events occur within the entireSystem Tree.

Throttling and aggregationYou can configure when notification messages are sent by setting thresholds based onaggregation and throttling.

Aggregation

Use aggregation to determine the thresholds of events at which the rule sends a notificationmessage. For example, configure the same rule to send a notification message when the serverreceives 1000 virus detection events from different systems within an hour and whenever ithas received 100 virus detection events from any system.

Throttling

Once you have configured the rule to notify you of a possible outbreak, use throttling to ensureyou do not receive too many notification messages. If you are administering a large network,then you may be receiving tens of thousands of events during an hour, creating thousands ofnotification messages based on such a rule. Notifications allows you to throttle the number ofnotification messages you receive based on a single rule. For example, you can specify in thissame rule that you don’t want to receive more than one notification message in an hour.

Notification rules and System Tree scenariosTo show how this feature functions with the System Tree, two scenarios are used.

For both scenarios, we can assume that each group of the System Tree has a similar ruleconfigured. Each rule is configured to send a notification message when 100 virus detectionevents have been received from any product within 60 minutes. For reference purposes, each

Setting Up NotificationsNotifications and how it works


rule is named VirusDetected_<groupname>, where <groupname> is the name of thegroup as it appears in the System Tree (for example, VirusDetected_Subgroup2c).

Figure 3: System Tree for Notification Scenarios

Scenario one

For this scenario, 100 virus detections are detected in Subgoup2C within 60 minutes in a singleday.

Conditions of the rules VirusDetected_Subgroup2C, VirusDetected_Group2, andVirusDetected_MyOrganization are met, sending notification messages (or launchingregistered executables) per the rules’ configurations.

Scenario two

For this scenario, 50 virus detections are detected in Subgroup2C and 50 virus infections aredetected in Subgroup3B within 60 minutes in a single day.

Conditions of the VirusDetected_MyOrganization rule are met, sending notification messages(or launching registered executables) per the rules’ configurations. This is the only rule thatcan be applied to all 100 events.

Setting Up NotificationsNotifications and how it works


Reporting On System StatusePolicy Orchestrator 4.0.2 ships with its own querying and reporting capabilities. These arehighly customizable and provide flexibility and ease of use. Included is the Query Builderwizard which creates and runs queries that result user-configured data in user-configured chartsand tables.

To get you started, McAfee includes a set of default queries which provide the same informationas the default reports of previous versions.

Are you setting up queries for the first time?

When setting up queries for the first time:

1 Understand the functionality of queries and the Query Builder wizard.

2 Review the default queries, and edit any to your needs.

3 Create queries for any needs that aren’t met by the default queries.

Contents

Queries

Query Builder

Multi-server roll-up querying

QueriesQueries are configurable objects that retrieve and display data from the database. The resultsof queries are displayed in charts and tables. Any query’s results can be exported to a varietyof formats, any of which can be downloaded or sent as an attachment to an email message.Some queries can be used as dashboard monitors.

Query results are actionable

Query results are now actionable. Query results displayed in tables (and drill-down tables) havea variety of actions available for selected items in the table. For example, you can deploy agentsto systems in a table of query results. Actions are available at the bottom of the results page.

Queries as dashboard monitors

Use almost any query (except those using a table to display the initial results) as a dashboardmonitor. Dashboard monitors refresh automatically on a user-configured interval (five minutesby default).


Exported results

Query results can be exported to four different formats. Exported results are historical data andare not refreshed like when using queries as dashboard monitors. Like query results andquery-based monitors displayed in the console, you can drill down into the HTML exports formore detailed information.

Unlike query results in the console, data in exported reports is not actionable.

Reports are available in several formats:

• CSV — Use this format to use the data in a spreadsheet application (for example, MicrosoftExcel).

• XML — Use this format to transform the data for other purposes.

• HTML — Use this report format to view the exported results as a web page.

• PDF — Use this report format when you need to print the results.

Sharing queries between servers

Any query can be imported and exported, allowing you to share queries between servers. Anyquery needs to be created only once in a multi-server environment.

Public and personal queriesQueries can be personal or public. Private queries exist in the user’s My Queries list, and areonly available to their creator. Pubic queries exist in the Public Queries list, and are availableto everyone who has permissions to use public queries.

Most default queries are only made available to the global administrator, who must make thesedefault queries public for other users to access them. Several queries are public by default foruse by the default dashboards.

Only users with appropriate permissions can make their personal queries public ones.

Query permissionsUse query permissions to assign specific levels of query functionality to permission sets, whichare assigned to individual users.

Available permissions include:

• No permissions — The Query tab is unavailable to a user with no permissions.

• Use public queries — Grants permission to use any queries that have been created andmade public by users with the same permissions.

• Use public queries; create and edit personal queries — Grants permission to use anyqueries that have been created and made public by users with the same permissions, aswell as the ability to use the Query Builder wizard to create and edit personal queries.

• Edit public queries; create and edit personal queries; make personal queries public— Grants permission to use and edit any public queries, create and edit any personal queries,as well as the ability to make any personal query available to anyone with access to publicqueries.

NOTE: To run some queries, you also need permissions to the feature sets associated with theirresult types. Also, in a query’s results pages, the available actions to take on the resulting itemsdepend on the feature sets a user has permission to.

Reporting On System StatusQueries


Query BuilderePolicy Orchestrator provides an easy, four-step wizard with which to create and edit customqueries. With the wizard you can configure which data is retrieved and displayed, and how itis displayed.

Result types

The first selection you make in the Query Builder wizard is a result type. This selection identifieswhat type of data the query will be retrieving. This selection determines what the availableselections are in the rest of the wizard.

Result types include:

• Audit Log Entries — Retrieves information on changes and actions made by ePO users.

• Compliance History — Retrieves information on compliance counts over time. This querytype and its results depend on a Run Query server task that generates compliance eventsfrom the results of a (Boolean pie chart) query. Additionally, when creating a ComplianceHistory query, be sure the time unit matches the schedule interval for the server task. McAfeerecommends creating the Boolean pie chart query first, followed by the server task thatgenerates the compliance events, and finally the Compliance History query.

• Events — Retrieves information on events sent from managed systems.

• Managed Systems — Retrieves information about systems running the McAfee SecurityAgent.

• Notifications — Retrieves information on sent notifications.

• Repositories — Retrieves data on repositories and their status.

• Rolled-up Compliance History — Retrieves information on compliance counts over time fromregistered ePO servers. This query depends on server tasks being run on this ePO serverand the registered servers.

• Rolled-up Managed Systems — Retrieves summary information on systems from registeredePO servers.

Chart types

ePolicy Orchestrator provides a number of charts and tables to display the data it retrieves.These and their drill-down tables are highly configurable.

NOTE: Tables do not include drill-down tables.

Chart types include:

• Bar chart

• Boolean pie chart

• Grouped bar chart

• Grouped summary table

• Line chart

• Pie chart

• Summary table

• Table

Reporting On System StatusQuery Builder


Table columns

Specify columns for the table. If you select Table as the primary display of the data, thisconfigures that table. If you selected a type of chart as the primary display of data, this configuresthe drill-down table.

Query results displayed in a table are actionable. For example, if the table is populated withsystems, you can deploy or wake up agents on those systems directly from the table.

Filters

Specify criteria by selecting properties and operators to limit the data retrieved by the query.

Multi-server roll-up queryingePolicy Orchestrator 4.0.2 includes the ability to run queries that report on summary data frommultiple ePO databases.

NOTE: Having multiple servers is the exception rather than the rule. Use multiple servers onlywhere required because of network size, topology, or geographic location.

Use these result types in the Query Builder wizard for this type of querying:

• Rolled Up Managed Systems

• Rolled Up Compliance History

Query results from these types of queries are not actionable.

How it works

To roll up data for use by roll-up queries, you must register each server (including the localserver) you want to include in the querying.

Once the servers are registered, you must configure Data Roll Up server tasks on the reportingserver (the server that performs the multi-server reporting). Data Roll Up server tasks retrievethe information from all databases involved in the reporting, and populates the eporollup_ tableson the reporting server. The roll-up queries target these database tables on the reporting server.

NOTE: Use of the Rolled Up Compliance History type of query, requires an additional query (onManaged Systems with a Boolean pie chart) and an additional Run Query server task (with thesubaction to generate a compliance event) to run on each server whose data you want toinclude in the Rolled Up Compliance History type of query.

Reporting On System StatusMulti-server roll-up querying


Detecting Rogue SystemsUnprotected systems are often the weak spot of any security strategy, creating entry pointsthrough which viruses and other potentially harmful programs can access your network. Evenin a managed network environment, some systems might not have an active McAfee Agent onthem. These can be systems that frequently log on and off the network, including test servers,laptops, or wireless devices.

Rogue System Detection provides real-time detection of rogue systems through use of theRogue System Sensor installed throughout your network. The sensor listens to network broadcastmessages and DHCP responses to detect systems connected to the network.

When a sensor detects a system on the network, it sends a message to the ePolicy Orchestratorserver. The server then checks whether the system has an active agent installed and managed.If the system is unknown to the ePO server, Rogue System Detection provides information toePolicy Orchestrator to allow you to take remediation steps, including alerting network andanti-virus administrators or automatically deploying an agent to the system.

Contents

What are rogue systems

How detected systems are matched and merged

Rogue System Detection states

What are rogue systemsRogue systems are systems that access your network, but are not managed by your ePO server.A rogue system can be any device on your network that has a network interface card (NIC).On systems that have multiple NICs, each resulting interface can be detected as a separatesystem. When these interfaces are detected, they can appear as multiple rogue interfaces.

Identifying these systems and their interfaces, and managing them with Rogue System Detectionand ePolicy Orchestrator helps provide the network security your organization needs.

How detected systems are matched and mergedWhen a system connects to your network, Rogue System Detection automatically checks theePO database to determine whether the incoming system is new or corresponds to a previouslydetected system. If the system has been previously detected, Rogue System Detection matchesit to the existing record in the ePO database automatically. When a detected system is notmatched automatically, you can manually merge the system with an existing detected system.


Matching detected systems

Automatic matching of detected systems is necessary to prevent previously detected systemsfrom being identified as new systems on your network. By default, systems are first matchedagainst an agent’s unique ID. If this unique ID does not exist, the ePO database uses attributesspecified in the Rogue System Matching server settings. You can specify which attributes thedatabase uses for matching, based on which attributes are unique in your environment.

If a system on your network has multiple NICs, each system interface can result in separatedetections. You can specify how the system interfaces are matched in the same manner usedfor specifying the matching of detected systems.

Merging detected systems

When the ePO server cannot automatically match detected systems, you can merge themmanually. For example, the ePO server might not be able to match a detected system interfacegenerated by a system with multiple NICs based on the matching attributes you have specified.

Rogue System Detection statesRogue System Detection categorizes systems, sensors and subnets on your network withdifferent states to make monitoring and managing your network easier. These states determinethe following:

• Overall system status

• Rogue System Sensor status

• Subnet status

Detecting Rogue SystemsRogue System Detection states


The Detected Systems homepage displays information on each of these states via correspondingstatus monitors. This page also displays the 25 subnets with the most rogue system interfacesin the Top 25 Subnets list and the adjacent Rogue System Interfaces by Subnet table.

Figure 4: Detected Systems homepage

Detecting Rogue SystemsRogue System Detection states


Monitoring with DashboardsDashboards allow you to keep a constant eye on your environment. Dashboards are collectionsof monitors. Monitors can be anything from a chart-based query, to a small web application,like the MyAvert Security Threats, that is refreshed at a user-configured interval.

Users must have the appropriate permissions to use and create dashboards.

Are you setting up dashboards for the first time?

When setting up dashboards for the first time:

1 Decide which default dashboards and default monitors you want to use.

2 Create any needed dashboards and their monitors, and be sure to make active any youwant available as tabs from the navigation bar.

Contents

Dashboards and how they work

Dashboards and how they workDashboards are collections of user-selected and configured monitors that provide current dataabout your environment.

Queries as dashboard monitorsUse any chart-based query as a dashboard that refreshes at a user-configured frequency, soyou can use your most useful queries on a live dashboard.

Default dashboard monitorsThis release of ePolicy Orchestrator ships with several default monitors:

• MyAvert Security Threats — Keeps you aware of which DATs and engines are available, whatthreats they protect, and the versions that are currently in your master repository.

• Quick System Search — A text-based search field that allows you to search for systems bysystem name, IP address, MAC address, or user name.

• McAfee Links — Hyperlinks to McAfee sites, including ePolicy Orchestrator Support, AvertLabs WebImmune, and Avert Labs Threat Library.


Lab EvaluationThis section describes how to install and deploy ePolicy Orchestrator in a test environment andthen to maintain and monitor it. It provides steps to get ePolicy Orchestrator 4.0 up and runningquickly, and presents important features of the product.

What is covered and what is not covered

This guide does not cover everything that ePolicy Orchestrator can do, including many advancedfeatures and installation scenarios typical in real-world deployments. For your live deployment,you can follow many of these basic steps, but you might need more information. For completeinformation on all aspects of the product, refer to the ePolicy Orchestrator 4.0 Product Guide.

NOTE: ePolicy Orchestrator manages not only anti-virus software but also McAfee products forhost intrusion prevention, anti-spyware, website protection, data loss prevention, and networkaccess control. In addition, the open design of ePolicy Orchestrator allows for easy managementand reporting integration of non-McAfee products, including Symantec clients.

CommentWhat is not coveredWhat is covered

In a test environment, oneserver is enough.

Setting up multiple ePolicy Orchestrator serversconsoles.

Setting up a single ePolicyOrchestrator server.

Using the SQL 2005 Expressdatabase packaged with ePolicy

Running SQL Server databases or remotedatabase servers.

Running SQL 2005 Expressdatabase (an installation optionfor ePolicy Orchestrator 4.0) on Orchestrator is simpler forthe same server as ePolicyOrchestrator.

testing in a small (fewer than500 systems) lab network.

Manually installing the agent isalso covered.

Using login scripts or third-party tools to deployagents and VirusScan Enterprise.

Using ePolicy Orchestrator todeploy agents and VirusScanEnterprise.

These examples use NT domainsand Active Directory to illustratekey product features.

Setting up UNIX, Linux, or NetWare environments.Setting up a simple networkenvironment with NT domainsand Active Directory.

See the ePolicy Orchestrator 4.0 Installation Guide for complete software and hardwarerequirements for the ePolicy Orchestrator server and agent. See the VirusScan Enterprise 8.5Installation Guide for software and hardware requirements for VirusScan Enterprise 8.5.

Contents

Installing and setting up

Creating your System Tree

Deploying agents in your System Tree

Setting up a master repository

Setting up a distributed repository

Using VirusScan Enterprise with ePolicy Orchestrator

Maintaining and monitoring your environment


Scheduling automatic repository synchronization

Configuring global updating with SuperAgents

Advanced: Using ePO Notifications

Advanced: Using Rogue System Detection

Installing and setting upBefore you install and test ePolicy Orchestrator, you must first create a safe test network.Planning and testing a live deployment is an involved process, especially in a large organization.However, you can create a small test environment in a matter of hours, and if you identifyexisting systems in your network for testing, the process takes even less time.

The lab environment used in these examples consists of one NT domain and one Active Directorycontainer, each with several servers and several workstations. Having multiple NT domains orActive Directory containers in your lab environment is not required to test ePolicy Orchestrator.

A test environment should include:

• One server system to host the ePolicy Orchestrator server.

• One or more client systems (servers or workstations) to which you deploy agents andVirusScan Enterprise 8.5.

NOTE: See the installation guides for ePolicy Orchestrator 4.0 and VirusScan Enterprise 8.5 forcomplete software and hardware requirements for the ePolicy Orchestrator server, the agent,and VirusScan Enterprise 8.5.

Tasks

Configuring your network

Getting installation files from McAfee

Installing the ePO server

Starting ePolicy Orchestrator for the first time

Configuring your networkBefore setting up your test environment, ensure your network is correctly configured for ePolicyOrchestrator. Use this task to verify network settings before installing ePolicy Orchestrator.

Task

1 Create trusted domain connections to any remote NT domains.

To deploy the agent to systems outside the local NT domain (where the ePolicy Orchestratorserver resides), you must create a trusted connection between the domains. This connectionis required for the server to deploy agents and install software on remote systems. Seeyour Microsoft Windows documentation for instructions. You must also have a user accountwith administrator rights in the remote domain.

2 Install Microsoft Windows 2000 or Windows XP on client systems.

To use operating systems earlier than Windows 2000, refer to the ePolicy Orchestrator 4.0Installation Guide for information.

3 Test network connectivity.

Lab EvaluationInstalling and setting up


From the system where you plan to install the ePolicy Orchestrator server, ping clientsystems where you plan to deploy agents.

• On the server, open a command window (Start | Run) and type cmd at the prompt.

• Type ping commands to test the system name and IP address:

• ping MyComputer

• ping 192.168.14.52

4 Confirm that client NT Admin$ share folders are accessible from the server.

From the system on which you plan to install the ePolicy Orchestrator server, test accessto the default Admin$ share folder on each client system. This access is required for theePolicy Orchestrator server to install agents, and testing confirms your administratorcredentials.

• On the ePolicy Orchestrator server, open a command window (Start | Run).

• Type the path to the client Admin$ share (use system name or IP address):

• \\MyComputer\Admin$

• \\192.168.14.52\Admin$

If systems are properly connected over the network and your credentials have sufficientrights, the Admin$ share folder is present and you see a Windows Explorer dialog box.

Getting installation files from McAfeeBefore you start installing, get the installation files for ePolicy Orchestrator and VirusScanEnterprise from the McAfee website or your product CD, if you have one. If you want to usethe 30-day evaluation versions for your tests, download them from the McAfee website. Thefiles you need are:

• EPO400E.ZIP. The installation files necessary for installing the ePolicy Orchestrator 4.0 serverand database.

• VSE85iEML.ZIP. The VirusScan Enterprise 8.5 installation files to check in to ePolicyOrchestrator 4.0 for deployment to clients. Note that this version of VirusScan is not supportedon Windows 95, Windows 98, or Windows ME.

Task

1 From the system on which you plan to install the ePolicy Orchestrator server, open a webbrowser and go to https://secure.nai.com/apps/download/free_evaluations/default.asp.

2 Select ePolicy Orchestrator Enterprise Edition 4.0.0 under Free Product Evaluationsand click the TRY link.

3 Fill out the form and follow directions to download the EPO400E.ZIP file.

4 Repeat step 1, select McAfee VirusScan Enterprise 8.5i under Free Product Evaluationsand click the TRY link.

5 Fill out the form and follow directions to download the VSE85iEML.ZIP file.

6 Extract the contents of the downloaded .ZIP files into a temporary folder on the systemyou plan to use as your test ePolicy Orchestrator server.

NOTE: You need to access files in these folders at various times during the deploymentprocess covered in this guide.



Installing the ePO serverInstall the ePolicy Orchestrator server and database on the system you plan to use as yourePolicy Orchestrator server. In the examples used in this guide, we install the ePolicy Orchestratorserver to the system called ePOServer that is running the Windows 2003 Server SP2 operatingsystem.

Task

1 Log on to the desired system using a user account with local administrator permissions.

2 Run SETUP.EXE using one of these methods:

• From the product CD, select the desired language in the autorun window, then selectInstall ePolicy Orchestrator 4.0.

• From software downloaded from the McAfee website, go to the location containing theextracted files and double-click SETUP.EXE.

NOTE: If any prerequisite software is missing from the installation target computer, a listof those items appears.

3 Click Install. The installation process for each software item not listed as Optional beginsautomatically. For optional items, a dialog box appears where you can allow installation orreject it. Accept the installation of SQL Server 2005 Express.

4 When the Welcome window of the ePolicy Orchestrator Installation Wizard appears, clickNext.

5 In the End User License Agreement dialog box, select the appropriate license type andthe location where you purchased the software. The license type must match the licenseyou purchased. If you are unsure, contact the person who sold you the software.

6 Accept the agreement and click OK to continue. The Choose Destination Locationdialog box appears.

7 Accept the default installation path or click Browse to select a different location. If thelocation does not yet exist, type the path of the intended location in the Browse dialogbox, then click Next. The Set Administrator Information dialog box appears

8 Type and verify the password for logging on to ePolicy Orchestrator, then click Next.

9 In the Set Database Information dialog box, identify the type of account andauthentication details that the ePolicy Orchestrator server will use to access the database.

a Use the drop-down list to select a server. If SQL Express was installed, the name of thedatabase is <computername>\ EPOSERVER.

b Select the type of authentication:

• Windows authentication(Recommended): Specify the NetBIOS name of theDomain associated with the desired domain administrator user account, then provideand verify a password.

• SQL authentication: Provide the User name that the ePolicy Orchestrator softwarewill use to access the database, then provide a password. If the installer cannotidentify the port used for communication to and from the server, you may beprompted to provide that information. Otherwise, the SQL server TCP port field showsthe port and is disabled.

10 Click Next.



11 Set the HTTP Configuration. Designate the port to be used by each function, then clickNext.

NOTE: It is basically safe to accept all default settings. If you choose default port 80 forAgent-to-Server communication and IIS is installed on the server, you will receive an errorindicating that the port is in use. Either disable IIS or choose another port.

PortFunction

Configurable. McAfee recommends using a port otherthan 80, typically an unused port above 1024.

Agent-to-Server communication port

Configurable.Agent Wake-Up communication port

Configurable port used to send SuperAgent wake-upcalls.

Agent Broadcast communication port

Configurable.Event Parser-to-Server communication port

Configurable.Console-to-Application Server communicationport

Configurable port used by the Rogue System Sensor toreport host-detected messages to the Rogue SystemDetection server using SSL.

Sensor-to-Server communication port

Port 8801. Non- configurable port used by McAfee AvertLabs to provide information on security threats and the

Security Threats communication port

required DAT and engine versions to protect againstthem.

Port 1433. Non-configurable.SQL server TCP port

12 In the Default Notification Email Address dialog box, configure the recipient of ePolicyOrchestrator notifications or leave the default. For a new recipient, complete these options:

a Provide the default destination for messages.

b Select Setup email server settings now, otherwise leave the default address.

c Type the Fully Qualified Domain Name (FQDN) of the mail server and specify the Portto use for email.

d Select This server requires authentication if needed, then type the User nameand Password required to access the server.

e Click Next.

For more information, see the Notifications chapter in the ePolicy Orchestrator 4.0 ProductGuide.

13 In the Set Windows Authentication dialog box, specify the WINS server or Domainto be used with ePolicy Orchestrator, then click Next.

14 In the Start Copying Files dialog box, click Install to begin the installation.

15 In the Installation Complete dialog box, view the Readme file for the steps to start thesoftware, then click Finish to complete the installation.

Starting ePolicy Orchestrator for the first timeUse this task to log on to the ePO server. You must have valid credentials to do this. You canlog on to multiple ePO servers by opening a new browser session for each ePO server.



Task

1 Open an Internet browser and go to the URL of the server. The Log On to ePolicyOrchestrator dialog box appears.

2 Type your User name and Password.

NOTE: Passwords are case-sensitive.

3 Select the Language you want the software to display.

4 Click Log On.

Creating your System TreeThe System Tree organizes managed systems in units for monitoring, assigning policies,scheduling tasks, and taking actions. These units are called groups, which are created andadministered by global administrators or users with the appropriate permissions and can includeboth systems and other groups.

Grouping systems with similar properties or requirements into these units allows you to managepolicies for systems in one place, rather than setting policies for each system individually.

Before you start managing anti-virus policies for client systems on your network, you must addthose systems to your ePolicy Orchestrator System Tree.

To organize your systems, place them into groups. You can create a hierarchy of groups, muchlike you would create a hierarchy of folders in Windows Explorer. Grouping is useful for assigningpolicies and tasks. You can group systems according to any criteria that makes sense for yourorganization.

This guide uses two common types of grouping:

• NT Domain/Active Directory containers. Using your existing NT network domains orActive Directory network containers as sites makes creating your System Tree fast and easy.Having your System Tree structure mirror your network structure can also mean you onlyhave to remember one hierarchy, not two.

• Geographical divisions. If you have locations in various portions of the world, or in multipletime zones, you might want to organize your System Tree according to those divisions. Someof your policy or task coordination is much easier across multiple time zones if you placethese systems in such sites.

Other typical methods of grouping include, but are not limited to:

• Security divisions. If users have various levels of security access in your environment,creating your System Tree structure to mirror those levels can make enforcing policy mucheasier.

• Functional divisions. If users have various groups of users in your environment, such asEngineering and Finance, creating your System Tree structure to mirror those levels canmake determining policies much easier.

Along with groups, you can add Tags to your systems to further identify them with some traitbased on the system's properties.

The first step in creating your System Tree is to add systems from your network. Try one ofthese methods:

• Automatically add existing NT domains or Active Directory containers to your System Tree.Useful if all or part of your environment is controlled by Active Directory and if you wantportions of your System Tree to mirror portions of your Active Directory.

Lab EvaluationCreating your System Tree


• Manually add individual systems to your System Tree. While this method can be too slowwhen deploying ePolicy Orchestrator in a live network, it is fast enough for adding a handfulof systems in your test network.

Tasks

Adding existing NT domains or Active Directory containers automatically

Adding groups and systems manually

Organizing server and workstations into groups

Organizing systems with tags

Adding existing NT domains or Active Directory containersautomatically

Use this task to import systems from NT domains or Active Directory containers into the SystemTree as your test client systems in your lab network. This is an easy way to add all the systemsin your network to the System Tree at once as a flat list with no system description.

Task

1 Go to Systems | System Tree | Group, then select or create a group in the SystemTree.

2 With My Organization in the System Tree selected, click New Subgroup.

3 Name the group MyNetwork and click OK.

4 Select the MyNetwork group in the System Tree, and next to Synchronization type clickEdit. The Synchronization Settings page for the selected group appears.

5 Next to Synchronization type, select NT Domain or Active Directory. The NT Domainor Active Directory page appears.

6 Select these options on the page:

If you selected Active DirectoryIf you selected NT Domain

1 Select Move systems from theircurrent System Tree location tothe synchronized group.

1 Select Move systems from theircurrent System Tree location tothe synchronized group.

2 2 In Active Directory domain, typethe fully-qualified domain name ofyour Active Directory domain.

Type the name of your domain or clickBrowse to select a domain accessibleby the ePolicy Orchestrator server.

3 In Active Directory credentials,type the Active Directory usercredentials that ePolicy Orchestratoruses to retrieve the Active Directoryinformation.

4 Next to Container, click Browse andselect a source container in the SelectActive Directory Container dialogbox, then click OK.

7 Click Synchronize Now.



8 Click Save. All your systems have been added to the System Tree. To manage them youneed to deploy a McAfee agent to them. See the Deploying Agents section for details.

Adding groups and systems manuallyInstead of populating the System Tree automatically by importing your NT domains or ActiveDirectory containers, you can add groups and systems manually. Use this task to add groupsand then add systems to the groups.

Task

1 Go to Systems | System Tree | Group, then select a group in the System Tree, underwhich to create another group.

2 Click New Subgroup at the bottom of the page. The New Subgroup dialog box appears.

3 Type a name for the group, then click OK. The new group appears in the System Tree.

4 Repeat as necessary until you are ready to populate the groups with systems.

5 Select a group in the System Tree and click New Systems.

6 Under Systems to add, type the name of your systems (NetBIOS names) separated byspaces, or click Browse to locate the systems by Domain.

7 Click OK to save the changes.

Organizing server and workstations into groupsYou now have a list of systems in your System Tree; however, what happens to new systemsthat call in to the ePolicy Orchestrator server that haven't yet been put into the System Tree?This could occur if you installed the agent manually on systems whose name you had not yetadded to the System Tree. ePolicy Orchestrator has a powerful group sorting function thatallows you to set up rules about how systems sort themselves into your System Tree. For detailson this feature, refer to this topic in the ePolicy Orchestrator 4.0 Product Guide.

For evaluation purposes, you will create a top-level group named New Systems Go Here intowhich all systems with the Workstation or Server tags will be sorted. The system sorting rulethat you create does not function until a system calls in to the ePO server that is not alreadyin the System Tree. Use this task to create this group and the sorting rule.

Task

1 Go to Systems | System Tree | Group, then select a group in the System Tree, underwhich to create a New Systems Go Here group.

2 Click New Subgroup at the bottom of the page. The New Subgroup dialog box appears.

3 Type New Systems Go Here, then click OK. The new group appears in the System Tree.

4 Select the New Systems Go Here group in the System Tree, and next to Sorting Criteriaclick Edit.

5 Select Systems that match any of the criteria below (IP addresses and/or tags)and click Add Tag.

6 Select Workstation, click the plus sign, then select the Server.

7 Click Save.



8 In the Sorting Order list for the group that contains the New Systems Go Here group, clickthe Move Up link for New Systems Go Here until it is at the top of the list. Now the NewSystems Go Here group is the first to be evaluated once systems get to the System Tree.

Organizing systems with tagsePolicy Orchestrator offers a very helpful way to make sure that the systems in your groupsunder the System Tree are organized, and remain organized to your liking. This is accomplishedthrough the use of tags.

One of the benefits of tags is that you can use a system's own properties to dynamically examineit against a set of criteria and then take actions on it, including moving it around the SystemTree. For example, you could apply the tag Workstations to one group for Workstations andthe tag Servers for another group, then have the systems sorted into these groups automaticallyon every communication with the ePolicy Orchestrator server.

ePolicy Orchestrator 4.0 ships with two default tags, Workstation and Server, as sample tags.For this exercise we will create a Low Disk Space tag that will be applied automatically to anysystem with less than one gigabyte of free hard drive space. If you have particular policies setto apply to such systems, application of these policies will be done automatically.

Task

1 Go to Systems | Tag Catalog.

2 Click New Tag.

3 Name the tag Low Disk Space, and click Next.

4 Under Available Properties, click Free Disk Space (MB).

5 From the comparison value list, select Less than or Equals.

6 Under Value type 1024 (1024 MB = 1 GB).

7 Click Next, then select On each agent-server communication and when a "Run TagCriteria" action is taken.

8 Click Next, then click Save.

Every time a system calls in to ePolicy Orchestrator as part of the normal communication interval,it will be evaluated against this tag and it will be applied to them if they have one gigabyte orless free hard drive space.

Deploying agents in your System TreeBefore you can manage the client systems in your System Tree, you must install an ePolicyOrchestrator agent on each client system. The agent is a small application that resides on theclient system and periodically checks in with the ePolicy Orchestrator server for updates andnew instructions.

Deploying the agent from the ePolicy Orchestrator server requires the following:

• A network account with administrator privileges. You must specify administrator credentialswhen you deploy agents.

• Domain trusts to other NT domains, if necessary. To deploy agents outside the local NTdomain that hosts your ePolicy Orchestrator server, you must have a domain trust relationshipconfigured between the local and target domains.

Lab EvaluationDeploying agents in your System Tree


From the System Tree, you can install the agent on each system in a group at once. To do this,send an agent install command to the group. Because of inheritance, you can specify an agentinstallation at the parent group level and all child systems inherit the command.

Alternatively, if you do not plan to use ePolicy Orchestrator to deploy the agent, you can installthe agent manually from the client system.

Tasks

Configuring the agent policy settings before deployment

Deploying agents

Monitoring agent installations

Installing agents manually on client systems

Configuring the agent policy settings before deploymentYou can deploy agents with default policy settings. For testing purposes, however, modify thepolicy settings to allow the agent tray icon to appear in the Windows system tray on the clientsystem. Not only will this expose you to setting agent policies, it also makes it easier to seewhen the agent is installed on your client systems. When you make a policy change at thegroup level, it applies to all test systems within the group unless you have specifically assignedanother policy below that point. This allows you to configure the policy settings once, thendeploy them to all your systems within a group.

Task

1 Go to Systems | Policy Catalog, then from the Product list select McAfee Agent.

2 For the My Default policy, click Edit.

3 Under General Options, select Show the McAfee system tray icon.

4 Click Save.

Deploying agentsDeploy agents to all your test systems in a group at once by initiating the agent installation atthe group level in the System Tree. This method uses Windows NT push technology.

Task

1 Go to Systems | System Tree, then select the group to which you want to deploy theagent.

2 Click Deploy Agents. The Deploy McAfee Agent page appears.

3 Specify Credentials for agent installation that have rights to the systems. Thesecredentials, typically that of a domain administrator, are used to copy the agent packageto the client system's ADMIN$ share folder and run the agent installation files.

4 Click OK to send the agent installation package to the selected systems. After the installationis complete, agents call back in to the ePO server with their properties within 10 minutes.This time can vary depending on your environment. For deployments of less than 100



systems on a 100Mbit network, all systems should be installed and calling in within about20 minutes.

TIP: If agents are not installing on client systems, be sure that you can browse to theADMIN$ share on those systems from the ePO server using the credentials you providedand that you have added the FRAMEPKG.EXE file to the firewall exceptions list..

Monitoring agent installationsIt can take up to 20 minutes for all the agents to be installed on all systems in your test sites,and for the System Tree to update with the new system properties. In the meantime, you cancheck the ePolicy Orchestrator server's audit log, which can alert you of failed agent deployment.Use this task to view the audit log.

Task

1 Go to Reporting | Audit Log.

2 View any audit log where the success type is Failure and where the action type is DeployAgents.

When agent deployment is complete and the agents have called back to the ePO server for thefirst time, the systems in your System Tree display information about the system. If the agentshave been installed and the System Tree does not reflect this, manually refresh the SystemTree by clicking the refresh button in the top right of the browser window.

You can also watch the installation from any of your client systems. The default policy suppressesthe installation interface; however, you can open the Task Manager on the client system andwatch the CPU usage spike briefly as the installation begins. After the agent is installed andrunning, two new services appear in the Processes window: UPDATERUI.EXE andFRAMEWORKSERVICE.EXE. Also, because of we modified the agent policy before deploying,the agent icon appears in the system tray after installation.

Installing agents manually on client systemsInstead of using ePolicy Orchestrator to deploy the agent, you could install it manually at eachclient system. Some administrators might want to install software on client systems manuallyand use ePolicy Orchestrator to manage policies only. Use this task to create an installationpackage and run it locally on a system.

Task

1 Go to Systems | System Tree and click New Systems.

2 Select Create and download agent installation package, deselect Use Credentials,then click OK.

3 Right-click the FramePkg link and save the file to a location for distribution to clientsystems.

4 Copy the FRAMEPKG.EXE file to the local client or to a network folder accessible from theclient.

5 Double-click FRAMEPKG.EXE and wait a few moments while the agent is installed. Withinten minutes, the agent calls in to the ePolicy Orchestrator server for the first time.

6 As needed, bypass the ten-minute interval by forcing the agent to call in by running theCMDAGENT/p command.



Setting up a master repositoryNow you have agents installed on your client systems, but what can they do? The purpose ofan agent is to manage client security software policies centrally through ePolicy Orchestrator.But until you have security software installed on the client systems, your agents have nothingto do. The next step is to use ePolicy Orchestrator to deploy VirusScan Enterprise 8.5 anti-virussoftware to your client systems.

Software deployed with ePolicy Orchestrator is stored in software repositories. There are manyways to set up your repositories. This guide demonstrates a typical example that you can usein your test environment.

This section illustrates using a master repository and the next section discusses distributedrepositories for deploying software and updating. Repositories store the software, such as theagent or VirusScan installation files, and updates, such as new virus definition (DAT) files, thatyou plan to deploy to client systems. The master repository is located on the ePolicy Orchestratorserver, and is the primary storehouse for your software and updates. Distributed repositoriesare copies of the master that reside in other parts of your network. Systems in those otherparts of your network can update more quickly from local servers than across a WAN. By default,client systems update from the nearest repository based on ping time.

Systems in the System Tree can be geographically separated from the ePO server's networkand connected via a WAN. In this case, create a distributed repository, which is a copy of themaster repository, on a system in the remote location. Systems in the remote location,RemoteLocation in our example, can update from the distributed repository instead of havingto copy updates across the WAN.

NOTE: This section assumes that you have a group in your System Tree named RemoteLocation.See the section Adding groups and systems manually to your System Tree for details.

Systems not in the RemoteLocation group receive updates and product deployments directlyfrom the master repository, located on the ePolicy Orchestrator server. Systems located in theRemoteLocation group, however, receive them from a distributed repository.

Tasks

Adding VirusScan to the master repository

Pulling updates from the McAfee source repository

Adding VirusScan to the master repositoryThe VirusScan Enterprise 8.5 extension allows you to manage VirusScan Enterprise 8.5 policiesonce it has been installed on client systems in your network. However, to be able to use ePolicyOrchestrator to deploy VirusScan Enterprise 8.5 to those client systems, you must also checkin the VirusScan Enterprise deployment package to the master software repository. Thedeployment package file is called VSE85iEML.zip and is the file you downloaded from McAfee.

Use this task to check in the VirusScan package to the ePO repository.

Task

1 Go to Software and click Check in Package.

2 Browse to the location of the VSE85iEML.zip file.


Lab EvaluationSetting up a master repository


Pulling updates from the McAfee source repositoryUse the McAfee HTTP or FTP site as your source repository, from which you can update yourmaster repository with the latest DAT and engine files. Initiate a pull from the source repositoryto your master repository to:

• Test that your ePolicy Orchestrator server can connect over the Internet to the sourcerepository.

• Update your master repository with the latest DAT files. DAT files are updated often, andthe DAT files included in your VirusScan Enterprise installation files are not the latest. Pullthe latest DAT files from the source repository before deploying VirusScan Enterprise to yournetwork.

By default ePolicy Orchestrator uses your Internet Explorer proxy settings. If you have not yetdone so, configure your LAN connection for Internet Explorer. Be sure to select the Use proxyfor all protocols (both FTP and HTTP) and the Bypass proxy for local addresses options.

Alternatively, you can manually specify proxy server information using the Configure ProxySettings option. Refer to the ePolicy Orchestrator 4.0 Product Guide for information on howto do this.

Use this task to create a pull task to update the mastery repository with the latest DAT andproduct files.

Task

1 Go to Software | Master Repository, then click Pull Now at the bottom of the page.The Pull Now wizard appears.

2 Click Next to accept the default settings on the first page.

3 Click Next to accept the default settings on the next page.

4 Click Start Pull. You are taken to the Server Task Log where you can drill into the taskfor details or watch the summary. Refreshing this page updates the status. Depending onyour available download bandwidth and the number of packages that your repository isupdating, the initial pull task usually takes between 5 and 30 minutes

Setting up a distributed repositoryIf systems are located in a different network than ePolicy Orchestrator server and are in differentsubnets or a WAN-connected location, it may be more efficient to create a distributed repositorythat is more easily accessible to these systems. As a general rule, if you have systems thatattempt to update over the WAN, you should determine if having a local network distributedrepository would have bandwidth savings

Now we need to create a distributed repository for a RemoteLocation group so that thosesystems can update from there. Your test network, with only a few client systems and oneePolicy Orchestrator server, is small enough not to require a distributed repository structure.However, you can use the distributed repository examples in this guide to simulate a probablereal-world scenario. Such a scenario could include systems in remote domains that cannotupdate efficiently over a WAN-connected master repository on the ePolicy Orchestrator server.

You can use FTP, HTTP, or UNC to replicate data from the master repository to your distributedrepositories. This guide describes creating a UNC share distributed repository on one of thesystems in the RemoteLocation group.

Lab EvaluationSetting up a distributed repository


Tasks

Creating a shared folder for the repository

Adding the distributed repository to the ePO server

Replicating master repository data to a distributed repository

Configuring remote sites to use the distributed repository

Creating a shared folder for the repositoryBefore you add the UNC distributed repository to ePolicy Orchestrator, you must first createthe folder to use. In addition, you must set the folder to enable sharing across the network sothat your ePolicy Orchestrator server can copy files to it. Use this task to create a folder andenable sharing.

NOTE: If need to secure the shared folder, consider enabling read access for users and writeaccess for administrators.

Task

1 From the system on which you plan to host the repository, create a new folder.

2 Right-click the folder and select Sharing.

3 On the Sharing tab, select Share this folder.

4 Click OK.

Adding the distributed repository to the ePO serverOnce you have created the folder to use as the UNC share, add a distributed repository andpoint it to the folder. Use this task to create the distributed repository point it to the sharedfolder.

Task

1 Go to Software | Distributed Repositories.

2 Click New Repository.

3 Name the repository TestRepository, select UNC, and click Next.

4 Type the UNC path name and click Next.

5 Type the download credentials for the UNC share.

NOTE: Click Test Credentials to check them. If the test fails, check that the system, sharename, and credentials are correct, that the credentials give access to the UNC share, andthat the UNC share is accessible from the ePO server's network.

6 Type the replication credentials for the UNC share.

NOTE: Click Test Credentials to check them. This writes a file to the UNC share. If thetest fails, check that the credentials are correct and that the share is not set to read-only.

7 Click Next, click Next again, then click Save.



Replicating master repository data to a distributed repositoryYou have created a UNC share on a system to host a distributed repository, and added therepository location to your ePolicy Orchestrator database. Now, all that is missing in the newrepository is data. If you browse to the share folder you created, you can see that it is stillempty.

Use this task to manually update your distributed repositories with the latest contents fromyour master repository. Later, we’ll schedule a replication task so this happens automatically.

Task

1 Go to Software | Distributed Repositories.

2 Click Replicate Now.

NOTE: For this button to be enabled, you must have at least one distributed repository.

3 Select TestRepository and click Next.

4 Click Next, then click Start Replication.

5 After the task is complete, open the UNC share folder to verify that the ePO repository fileshave been copied there.

Configuring remote sites to use the distributed repositoryNow that you have a distributed repository, you should make sure it gets used. Your test networkis too small to really require distributed repositories. But for the sake of simulating how theywork, you can configure your updating to ensure that systems in one group update only fromthe distributed repository instead of the master repository.

To simulate this in your test environment, use this task to configure the agent policy for theRemoteLocation group to use only the new distributed repository.

Before you begin

You must have at least one system in the RemoteLocation group. If you need to add a system,refer to the section Adding groups and systems manually to your System Tree.

Task

1 Go to Systems | Policy Catalog and select McAfee Agent.

2 Click Edit for the My Default policy.

3 On the Repositories tab, disable all repositories except TestRepository, and click Save.

4 Go to Systems | System Tree | Policies.

5 Select the RemoteLocation group in the System Tree and click Edit Assignment forthe General Category.

6 Select Break inheritance and assign the policy and settings below, then click Save.After the policy is applied, when the systems in the RemoteLocation group require updates,they retrieve them from the distributed repository.

NOTE: Forcing updates from certain repositories is shown here only for the purpose ofsimulating distributed repositories in a lab network. This is not something you would do ina production environment, where you would want to have some repository redundancyavailable for failover. Because of faster local network connections, client systems wouldlikely update from a local distributed repository, rather than over a WAN to the master



repository, even if not specifically configured to do this. On the other hand, if the distributedrepository were unavailable for any reason, the client could still update from otherrepositories on the network if necessary.

Using VirusScan Enterprise with ePolicyOrchestrator

This section describes how to set a VirusScan policy, deploy VirusScan software and policies tosystems, and verify that the software was installed using ePolicy Orchestrator.

Tasks

Setting VirusScan Enterprise policies before deploying

Deploying VirusScan Enterprise to client systems

Setting VirusScan Enterprise policies before deployingNow that you have created your repositories and added the VirusScan Enterprise deploymentpackage to them, you are almost ready to deploy VirusScan Enterprise to your client systems.Before deploying VirusScan Enterprise, however, let’s modify the policies slightly.

We can use policies to configure how VirusScan Enterprise functions after it is installed on theclient system. To demonstrate, we’ll use a simple example: changing the policies for workstationsto install VirusScan Enterprise 8.5 with minimal user interface. Servers keep the default policy,which is to display the full interface. This could be a potentially useful implementation in yourreal network, where you might want to hide the system tray interface on your workstations toprevent users from changing policies or disabling features.

For this example, we will modify the VirusScan User Interface Policies category. We willmake changes to the My Default policy, which is currently set at the My Organization levelof the System Tree. This ensures that all systems with VirusScan Enterprise 8.5 receive thispolicy.

Task

1 Go to Systems | System Tree | Policies and select the My Organization group in theSystem Tree.

2 Select VirusScan Enterprise 8.5.0 from the Product list.

3 Next to User Interface Policies, click the My Default link under Policy.

4 Select settings for Workstation, and under System tray icon select Show the systemtray icon with minimal menu option.

5 Click Save.

Deploying VirusScan Enterprise to client systemsYou have created master and distributed repositories, added the VirusScan Enterprise 8.5package to your master repository, and replicated this to a new distributed repository. Yoursystems are added to your System Tree and they all have ePolicy Orchestrator agents installed

Lab EvaluationUsing VirusScan Enterprise with ePolicy Orchestrator


on them. You have defined your VirusScan Enterprise policies for servers and workstations.Now, use this task to deploy VirusScan Enterprise on all the client systems in your test network.

For convenience you can deploy VirusScan Enterprise from the My Organization level of theSystem Tree to install it on all the systems in your System Tree at once.

If you want, you can send the agents an immediate agent wake-up call. This forces the agentsto check in immediately with the ePolicy Orchestrator server, rather than wait for the nextregularly scheduled agent callback, which by default could be as long as 60 minutes. When theagents call back, they see that the VirusScan Enterprise deployment is set to install rather thanignore. The agents then pull the VirusScan Enterprise setup file from the repository and installVirusScan Enterprise.

You can send an agent wake-up call to any group or individual system in your System Tree.Since we want to wake up all systems in the System Tree, we will initiate a single group wake-upaction from the My Organization level.

NOTE: Performing an immediate wake-up call to all systems in your System Tree is not a goodidea for a production server with thousands of systems. Typically you would wake up individualgroups and randomize the call over several minutes to reduce the number of simultaneousrequests across the network. Refer to the ePolicy Orchestrator 4.0 Product Guide for moredetails on agent wake-up.

Task

1 Go to Systems | System Tree | Client Tasks and select the My Organization groupin the System Tree.

2 Click New Task.

3 Name the taskDeploy VirusScan Enterprise 8.5, select Product Deployment (McAfeeAgent) under type, then click Next.

4 Select VirusScan Enterprise 8.5.0 under Products and be sure the Action is set toInstall.

5 Click Next.

6 Set the Schedule type to Run Immediately and click Save. You have now configuredyour default deployment task to install VirusScan Enterprise on all client systems in yourtest site. The deployment occurs the next time the agents call back to the ePolicyOrchestrator server for updated instructions.

7 (Optional) Initiate an agent wake-up call to have the deployment occur immediately.

a Go to Systems | System Tree | Group and select the My Organization group inthe System Tree.

b Click Wake Up Agents.

c Click OK.

8 To verify that the VirusScan Enterprise 8.5 software was successfully installed on yourclient systems, check the following:

From ePolicy OrchestratorOn the client system

Under Systems | System Tree | Systems the propertiesof a selected system indicates that VirusScan is installed.

The MCSHIELD.exe process is running and visible inthe Processes tab of your Windows Task Manager.

Run a query to list the systems with VirusScanEnterprise 8.5.

A VirusScan folder has been added under C:\ProgramFiles\McAfee.

Lab EvaluationUsing VirusScan Enterprise with ePolicy Orchestrator


From ePolicy OrchestratorOn the client system

NOTE: To verify any installation information, the ePolicyOrchestrator server needs to communicate with the

A VirusScan icon appears under the McAfee icon in thesystem tray. You might need to restart for the icon toappear. agents after the installation is complete. In the

communication after installation, the agents send upproperties showing that VirusScan Enterprise is installedand the ePolicy Orchestrator stores those properties inthe database. The data in the ePO server is only asfresh as the last communication with the client systems.

Maintaining and monitoring your environmentUse these tasks to confirm and track coverage, as well as get and distribute DAT files.

Tasks

Creating a query to confirm your coverage

Creating a dashboard to track coverage

Updating DAT files with a client update task

Verifying that VirusScan has updated to the latest DATs

Creating a query to confirm your coverageePolicy Orchestrator 4.0 uses a reporting system that is based on the creation of queries thatreport information in various formats such as pie charts, bar charts and tables. Queries cansimplify your tasks such as researching your environment, finding specific systems, or ensuringthat your systems are running specific McAfee software. After running the queries, you can alsoexport the results to other formats, such as PDF, HTML or CVS.

To get a feel for how the Query system works, and how easy it is to craft your own query,create one to determine if your systems have VirusScan Enterprise installed. Use this task tocreate and run a compliance query that displays the data in a pie chart.

Before you begin

Be sure you have the latest information from the systems. Run an agent wake up call, as outlinedin the previous task, to be sure the data is up-to-date.

Task

1 Go to Reporting and click New Query.

2 Select Managed Systems, then click Next.

3 Under Display Results as, select Boolean Pie Chart.

4 For Label for matching slice, type Using VSE 8.5; for Label for non-matching slice,type: Not using VSE 8.5.

5 Click Configure Criteria.

6 Under Available Properties, scroll down to the grouping for VirusScan EnterpriseProperties and click Product Version (VirusScan Enterprise) to add it to the right-handpane.

Lab EvaluationMaintaining and monitoring your environment


7 In the right-hand pane under Comparison for Product Version (VirusScan Enterprise),select Equals; under Value for Product Version (VirusScan Enterprise), type 8.5.

8 Click OK, then click Next.

9 Under Available Columns, select the following:

• Computer Properties: IP Address

• Computer Properties: User Name

• VirusScan Enterprise Properties: Product Version

10 Click Next, then click Run. A pie chart that reflects the deployment of VirusScan 8.5 inyour environment should appear. You can click on the segments of the pie chart to drilldown into them.If you have a red pie slice, click it to see which systems do not have VirusScan Enterprise8.5. You can save this query by clicking Save. (You have to create a query and have itsuccessfully run to save it.) After saving the query, it will show up in the query list underMy Queries.

TIP: If no information is shown except for the system name when you drill down, thisusually indicates that the agent has not yet successfully communicated with the ePO server.You might want to find out if the agent is installed properly.

Creating a dashboard to track coverageDashboards allow you to keep a constant eye on your environment. Dashboards are collectionsof monitors, which can be anything from a chart-based query to a small web application likeMyAvert Security Threats, that are refreshed at a specified interval.

For this evaluation, use this task to add a query monitoring VirusScan Enterprise complianceto an existing dashboard.

Task

1 Go to Dashboards, then select Manage Dashboards from the Options list.

2 Click Edit, then from the Size list select a layout so that a New Monitor button appears.

3 Click New Monitor.

4 In the New Monitor section, select Queries from the Category list, select VSE: Version8.5 Compliance from the Monitor list, then click OK. The VSE: Version 8.5 Compliancemonitor appears in the Dashboard.

5 Click Save, then click Close. The VSE: Version 8.5 Compliance monitor has a pie chartdisplay of systems that meet VirusScan 8.5 compliance. This monitor now appears in thedashboard and is refreshed at the default setting of every five minutes.

Updating DAT files with a client update taskA common things to do with ePolicy Orchestrator is to update DAT files. VirusScan Enterpriseby default performs an update task immediately after it is installed. If you followed the stepsto configure your repositories and pulled the latest DAT files to your master repository beforedeploying, VirusScan Enterprise is up-to-date shortly after being deployed.

After VirusScan Enterprise is installed, however, you need to update DAT files frequently. Todo this you should schedule an automatic client update task to occur regularly on a daily orweekly basis.



Use this task to schedule a regular automatic client update task to occur daily, repeated at 2hour intervals, and then wake up the managed systems to receive the new task.

Task

1 Go to Systems | System Tree | Client Tasks, and select My Organization in theSystem Tree.

2 Click New Task.

3 Name the taskUpdatemy Client Systems, select Update (McAfee Agent) under type,then click Next.

4 Select All Packages under Package Types, then click Next.

5 Select the following options:

• Schedule Type: Daily

• Options: Run missed tasks X minutes delay and set delay to 5.

• Schedule: Repeat and set to 1:00 AM and 11:00 PM every 2 hours.


7 Go to Systems | System Tree | Group, and select My Organization in the SystemTree.

8 Click Wake Up Agents, then click OK.

Verifying that VirusScan has updated to the latest DATsNow that your client systems have update schedules, you need to ensure that your client systemshave up-to-date DAT files. To do this you can run a query for DAT compliance. Use this taskto create and save a query to confirm that clients have the latest DAT version.

Before you begin

For this exercise, up-to-date DAT files are the DAT files in your master repository. To ensurethat your systems are receiving the latest DATs from McAfee, verify that:

• You have a pull task scheduled to happen at least once a day.

• You have a replication task scheduled to copy new information from your master repositoryto your distributed repositories if clients update from distributed repositories.

Task

1 Go to Reporting and click New Query.

2 Select Managed Systems, then click Next.

3 Under Display Results as, select Boolean Pie Chart.

4 For Label for matching slice, type: DAT up-to-date; for Label for non-matching slice,type: DAT not up-to-date.

5 Click Configure Criteria.

6 Under Available Properties, scroll down to the grouping for VirusScan EnterpriseProperties and click DAT Version (VirusScan Enterprise) to add it to the right-handpane.

7 In the right-hand pane under Comparison for DAT Version (VirusScan Enterprise), selectIs within X versions of repository; under Value for DAT Version (VirusScan Enterprise),type 0.



8 Click OK, then click Next.

9 Under Available Columns, select the following:

• Computer Properties: IP Address

• Computer Properties: User Name

• VirusScan Enterprise Properties: DAT Version (VirusScan Enterprise)

10 Click Next, then click Run. The pie chart is generated.

11 Click Save, title the query My DATs, and click Save again. You can now run the queryany time by going to the query under Reporting and clicking Run.

Scheduling automatic repository synchronizationYou now have a fully-functional installation of ePolicy Orchestrator deployed in a your testnetwork. You have agents deployed to client systems, and these agents are active and callingback to the server for updated instructions regularly. You have also used ePolicy Orchestratorto deploy VirusScan to your client systems, and have created a small software repository thatyou can use to deploy updates and additional software to your client systems.

The next step is to schedule regular pull and replication tasks to synchronize your source,master, and distributed repositories so that all your repositories are up-to-date.

Tasks

Scheduling a pull task to update the master repository daily

Scheduling a replication task to update your distributed repository

Scheduling task chaining to update master and distributed repositories

Scheduling a pull task to update the master repository dailyPull tasks update your master repository with the latest DAT and engine updates from thesource repository. By default, your source repository is the McAfee web site. Use this task tocreate a scheduled pull task to check for the latest updates from the McAfee web site once perday.

Before you begin

For new ePolicy Orchestrator 4.0 installs, there is a default server task to update your masterrepository on a daily basis. To use this existing task instead of creating a new one, enable theUpdate Master Repositoryserver task.

Task

1 Go to Automation | Server Tasks.

2 Click the Edit link for the Update Master Repository server task.

3 Select Enabled, and click the Next.The server action is Repository Pull and the source we are pulling from is theMcAfeeHttpsource site, depositing pulled files into the Current branch of the master repository. Notethat this task is set to pull All packages.

4 Click Next.

Lab EvaluationScheduling automatic repository synchronization


This task is set to run every day at 1:00 AM. Change this time if you want or modify theschedule type to check every few hours.


Scheduling a replication task to update your distributedrepository

With your pull task, your ePolicy Orchestrator server is configured to automatically update themaster repository with the latest updates from the source repository on the McAfee web site.The task runs once a day (unless you modified the schedule) and keeps your master repositorycurrent.

But an up-to-date master repository won't be of any use to those client systems on your networkthat get their updates from a distributed repository, such as the systems in the RemoteLocationgroup in your sample test network. The next step is to make sure the updates added to yourmaster repository are also automatically replicated to your distributed repository. Use this taskto create a replication task and schedule it to occur every day after the scheduled pull task youhave already created.

Task


2 Click the New Task.

3 Name the task Replicate to distributed repositories, and click Next.

4 For the first Action select Repository Replication, then click Next.This task is set to run every day at 1:00 AM.

5 Change the time from 1:00 AM to 2:00 AM so the replication occurs about an hour afterthe pull task runs.

6 Click Save.

Scheduling task chaining to update master and distributedrepositories

Now you have one pull task that updates your master repository and one task that does areplication to update your distributed repositories from your master repository. But you haveto make sure to keep the schedules tied together to update your distributed repositories soonafter your master repository receives an update. For an easier way to keep these actions insync there are two possibilities: Global Updating and Server Task Chaining. For this evaluation,you will look at the advanced feature of server tasks called Task Chaining.

Use this task to add a replication action to the server pull task, so that after the pull task isfinished the replication action begins immediately.

Task


2 Click the Edit link for the Update Master Repository server task.

3 Click Next.

4 Click the + sign next to the right of Repository Pull. This adds a new action row for thetask.

Lab EvaluationScheduling automatic repository synchronization


5 In the new row, select Repository Replication.

6 Click Save.

You now have a single pull task that will be immediately followed by a replication task, keepingall of your repositories up to date and on a single schedule.

Configuring global updating with SuperAgentsGlobal updating can automatically update all your client systems every time you check in newupdates to your master repository.

When configurable items are checked into your master repository, ePolicy Orchestrator replicatesthe contents automatically to any distributed repositories. It then alerts all agents deployed inyour network that have managed products, such as VirusScan Enterprise 8.5, to perform animmediate update task.

The global updating feature is useful in a virus outbreak situation. Assume that McAfee's AVERTLab team has posted updated DAT files in response to a newly-discovered virus. With globalupdating enabled, you simply initiate a pull task from your ePolicy Orchestrator console toupdate your master software repository with the new DAT files. ePolicy Orchestrator's globalupdating feature does the rest, updating the DAT files for all systems running active,communicating agents on your network within an hour.

Here's is what happens with global updating:

1 A new item is checked in to your master repository (either manually or through a pull task).

2 This item matches the criteria that triggers global updating.

3 A replication task is initiated to all distributed repositories.

4 After the replication is complete, a special SuperAgent wake-up call is sent out to yournetwork.

5 SuperAgents receive the wake-up call and send out a request for all agents on their subnetto initiate an update immediately.

The benefit is that it requires no manual intervention from you to get new updates out to yournetwork as soon as your master repository is updated.

ePolicy Orchestrator requires use of a SuperAgent for a global updating. To make global updatingwith SuperAgents work you need to convert an agent on each subnet to a SuperAgent and thenfrom the ePO server enable global updating. For details, see the ePolicy Orchestrator 4.0Product Guide.

Tasks

Converting an agent on each subnet into a SuperAgent

Enabling global updating on the ePO server

Converting an agent on each subnet into a SuperAgentYou can make any regular ePolicy Orchestrator agent into a SuperAgent. Use the ePolicyOrchestrator Agent policy pages to do this. Since you only need one SuperAgent per networksubnet, be sure to configure SuperAgents for individual systems in your System Tree, and notfor groups as you did when deploying agents or VirusScan Enterprise. For example, in thesample test network, convert one agent io a SuperAgent in the RemoteLocation group.

Lab EvaluationConfiguring global updating with SuperAgents


Use this task to create a policy for SuperAgents and then apply it to a single test system.

Task

1 Go to Systems | Policy Catalog and select McAfee Agent.

2 Click New Policy.

3 Create the policy based on McAfee Default, name the policy SuperAgent, and click OK.

4 In the policy page select these options:

• Show the McAfee system tray icon (Windows only)

• Convert agents to SuperAgents (Windows only)

5 Click Save. With this policy in place you now need to assign it to a single system.

6 Go to Systems | System Tree and select the RemoteLocation group.

7 Select the checkbox of a system to make it a SuperAgent, then select More Actions |Modify Policies on a Single Systems.

8 In the policy assignment page under Product, select McAfee Agent, and click EditAssignment.

9 Select Break inheritance and assign the policy and settings below, and underAssigned Policy select SuperAgent.

10 Click Save, then click Close.

You have changed the policy assignment for a system and it needs to communicate with theePO server to get the new policy. You can either wake it up manually or you can wait for thescheduled agent-to-server-communication interval (ASCI). After the system communication,the policy is enforced and that agent becomes a SuperAgent. The color of the agent icon changesto reflect its new status.

Enabling global updating on the ePO serverGlobal updating is a feature that triggers an automatic replication to distributed repositorieswhen changes occur in the master repository. This is followed by a wake-up call to SuperAgentsin your System Tree, which in turn wake up agents in their local subnets to receive the updates.

Use this task to select the global updating option on the ePO server settings.

Task

1 Go to Configuration | Server Settings.

2 Select Global Updating, then click Edit.

3 Under Status, select Enabled.

4 Change the Randomization interval (minutes) to 0. This tells agents to updateimmediately after the SuperAgent wake-up call. If you are working with more than 100systems, you should introduce randomized delay to avoid bandwidth issues during theclient updates.

5 Click Save.

Now any time DAT or engine files in your master repository change, the changes automaticallyreplicate to your distributed repositories. After that replication is complete, SuperAgents receivea wake-up call and in turn send out a wake-up call to all agents in the local subnet. Thoseagents then run an update using an authorized repository. This global update process shouldtake no longer than one hour.

Lab EvaluationConfiguring global updating with SuperAgents


Advanced: Using ePO NotificationsReal-time information about threat and compliance activity on your network is essential to yoursuccess.

You can configure rules in ePolicy Orchestrator to notify you when user-specified threat andcompliance events are received and processed by the ePolicy Orchestrator server. The abilityto set aggregation and throttling controls on a per rule basis allows you to define when, andwhen not, notification messages are sent.

Although you can create any number of rules to notify you of almost any threat or complianceevent sent by your security programs, the focus in this guide on this feature centers on an emailnotification message in response to a virus detected event.

Tasks

Configuring Notifications

Creating a rule for any VirusScan event

Providing a sample virus detection

Configuring NotificationsBefore setting up any rules, you must define who is going to receive the notification messageand what the message communicates. Use this task to specify to whom to send the emailnotification.

Task

1 Go to Configuration | Server Settings | Email Server.

2 Under SMTP server name, type the name of a mail server to which ePolicy Orchestratorcan route, and under From address type the email address you want to appear in theFrom line of the message.

3 Click Save, then click Contacts at the top of the tab. This page allows you to specify allthe addresses to include in the address book from which you select recipients during rulecreate.

Creating a rule for any VirusScan eventUse this task to create a rule that triggers an event if a virus is detected.

Task

1 Go to Automation | Notification Rules, then click New Rule.

2 Type a unique name for the rule, Virus Detected, then click Next.

3 On the Filters page under Products, select VirusScan, and under Categories select Anycategory, then click Next.

4 Click Next to accept the default settings on the Thresholds page.

TIP: The Thresholds page allows you to limit the number of notification messages youreceive for the rule. For example, you can define any rule to send you messages only whenthe number of events or the number of affected systems has reached a specified numberwithin a specified timeframe (Aggregation). You can further limit the number of messagesthat are sent by specifying an amount of time to elapse before receiving another message

Lab EvaluationAdvanced: Using ePO Notifications


(Throttling). Throttling is always recommended by McAfee to prevent a flood of messagesduring an outbreak situation.

5 On the notifications page, enter this information:

Do this...For this option...

Select Email Message.Type of notification

Click the browse button to select recipients.Recipients

Type Threat detected by VirusScan.Subject

Type a message that appears in the email.Body

Select Affected systems names and click Insert.This places the name of the affected systems in thebody of the message.

Insert Variable

6 Click Next, then click Save. The rule now appears in the Notification Rules list.

Providing a sample virus detectionNow that you have configured notifications and created a rule to trigger on VirusScan events,you are ready to trigger the rule and see the results.

Task

• Download EICAR.COM to one of the workstation test systems. Each time you download thisfile, you create a sample detection. The file is at:http://www.eicar.org/anti_virus-test_file.htm.

NOTE: This file is not a virus.

The on-access scanner detects and quarantines the EICAR test virus when EICAR.COM isdownloaded, and an event is sent to ePolicy Orchestrator. Because the event is handled andnot critical, it is uploaded on the next ACSI. Within a few minutes of receipt of the event bythe ePO server, a notification message is sent to the email recipient you indicated.

Advanced: Using Rogue System DetectionIn any managed network there is inevitably a small number of systems that do not have anePolicy Orchestrator agent on them. These can be systems that frequently log on and off thenetwork, such as test servers, laptop systems, or wireless devices. Users also uninstall or disableagents on their workstations. These unprotected systems are the vulnerable entry points bywhich viruses and other potentially harmful programs can gain access to your network.

The Rogue System Detection system helps you monitor all the systems on your network—notonly the ones ePolicy Orchestrator manages, but the rogue systems as well. A rogue system isany system that is not currently managed by an ePolicy Orchestrator agent but should be.Rogue System Detection integrates with your ePolicy Orchestrator server to provide real-timedetection of rogue systems by means of a sensor placed on each network broadcast segment.The sensor listens to network broadcast messages and spots when a new system has connectedto the network.

When the sensor detects a new system on the network, it sends a message to the Rogue SystemDetection server. The Rogue System Detection server then checks with the ePolicy Orchestrator

Lab EvaluationAdvanced: Using Rogue System Detection


http://www.eicar.org/anti_virus_test_file.htm

server to determine whether the newly-identified system has an active agent installed and ismanaged by ePolicy Orchestrator. If the new system is unknown to ePolicy Orchestrator, RogueSystem Detection allows you to take any number of remediation steps, including alerting networkand anti-virus administrators or automatically deploying an ePolicy Orchestrator agent to thesystem.

Tasks

Configuring a Rogue System Detection sensor policy

Deploying the Rogue System Detection sensor

Configuring an automatic response

Reacting to Rogue detection and remediation

Configuring a Rogue System Detection sensor policyUse this task to configure Rogue System Detection policy settings. Policy settings determinehow the sensor obtains and reports information about systems detected on your network.

Task

1 Go to Systems | Policy Catalog, then from the Product drop-down list select RogueSystem Detection 2.0.0, and from the Category drop-down list select General. Allcreated policies for Rogue System Detection appear.

2 Edit an existing policy, or create a new policy.

• To edit an existing policy, locate the policy and click Edit in its row.

• To create a new policy, click New Policy and, from the Create a policy based onthis existing policy drop-down list, select an existing policy on which to base the newpolicy. Name the new policy and click OK.

3 Configure any settings and click Save.

Deploying the Rogue System Detection sensorUse this task to install sensors to specific systems on your network. This task creates adeployment task that installs the sensor to the selected systems, then performs an immediateagent wake-up call on them.

Getting thereThis task can be performed from:

Go to Network | Detected Systems and click anysubnet category in the Subnet Status monitor, thenselect any subnet and click View Managed Systems.

Managed Systems for Subnet xxx.xxx.xxx.xxx page

Go to Systems | System Tree | Systems and click anysystem.

Systems Details page

Go to Systems | System Tree.Systems page

Task

1 Select the systems where you want to install sensors, then click Rogue Sensor Install.

• In the Systems Details page, you can install the sensor only from the system you areviewing.



• In the Managed Systems for Subnet xxx.xx.xx.x page, select the systems whereyou want to install sensors.

• In the Systems page, select a group in the System Tree and select the systems whereyou want to install sensors.

NOTE: If the button is not visible, click More Actions and select Rogue Sensor Install.

2 In the Action pane, click OK.

Configuring an automatic responseUse this task to set up automatic responses to Rogue System Detection events using theResponse Builder wizard. You can configure Rogue System Detection to generate an automaticresponse when:

• A system is added to the Exceptions list.

• A system is detected.

• A subnet falls into the uncovered state.

Task

1 Go to Automation | Responses and click New Response. The Response Builderwizard opens.

2 In the Description page:

a Type a name for the new response, and any notes.

b From the Event group drop-down list, select Rogue System Events.

c From the Event type drop-down list, select an event type.

Table 2: Event type option definitionsDefinitionOption

Triggers a response any time a system is added to the Exceptionslist.

Add to Exceptions

Triggers a response any time a subnet does not have any activesensors monitoring it.

Subnet Falls Into Uncovered State

Triggers a response any time a rogue system is detected.Rogue System Detected

d Select Enabled to activate the response, then click Next.

3 On the Filter page from the Available Properties list, click the properties you want touse to filter events, then click Next.

4 In the Aggregation page, specify how you want events to be aggregated, the click Next.

5 In the Actions page, select the action to perform when this response is triggered, thenclick Next.

Table 3: Action resultsResultAction

Adds the detected system to the Exceptions list.Add to Exceptions

Adds the detected system to the System Tree.Add to System Tree

Removes the detected system associated with this event.Delete Detected System

Deploys a McAfee Agent to the detected system.Deploy Agent



ResultAction

Opens the Query McAfee Agent Results page, which provides the name and IPaddress of the detected system and details about the agent installed on it.

Query Agent

Removes the detected system from the Exceptions list.Remove from Exceptions

Sends an email to user-configured recipients with a customized subject andmessage.

Send Email

6 In the Summary page review the response details, then click Save.

Reacting to Rogue detection and remediationNow you need to introduce a system into the test environment that does not have an agent.You can do this by several methods, such as joining a new laptop to the test network, or bymoving a system from an outside domain to the test domain you created earlier.

Task

1 Add a system that does not have an ePolicy Orchestrator agent to the test network.

2 Go to the Machine tab, then click List. When the sensor has detected a rogue system, itreports back to the server and places the system in the Machine List. Once it appears inthis list, take a five minute break to provide time for the agent installation. When the agentinstallation is complete, the system has a Rogue Type of Managed.

3 When the system’s Rogue Type changes to Managed, it is placed in Rogue Systems underLost&Found in the System Tree. The Lost&Found group is a holding place for systemsePolicy Orchestrator has discovered, but doesn’t know where to place within the SystemTree.

4 Click and drag the system to a site or group in your ePolicy Orchestrator Directory.

Congratulations! You have successfully configured the sensor, deployed the sensor, configuredan automatic response taken on the rogue you introduced, and placed the newly managedsystem into its appropriate spot in the System Tree.



epo 400 eval guide en us

Documents

mcafee epolicy orchestrator

trademarks of mcafee

mcafee red

written permission of

epolicy orchestrator9

system status

retrieval system

license attributions