McAfee EPOLICY ORCHESTRATOR 3.6, ePolicy Orchestrator User Manual

®

ePolicy Orchestrator

A product overview and quick set up in a test environment

version 3.6

Walkthrough Guide

revision 2.0

McAfee®

System Protection

Industry-leading intrusion prevention solutions

®

ePolicy Orchestrator

A product overview and quick set up in a test environment

version 3.6

Walkthrough Guide

revision 2.0

McAfee®

System Protection

Industry-leading intrusion prevention solutions

COPYRIGHT

Copyright © 2005 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 form

or by any means without the written permission of McAfee, Inc., or its suppliers or affiliate companies.

TRADEMARK ATTRIBUTIONS

ACTIVE FIREWALL, ACTIVE SECURITY, ACTIVESECURITY (AND IN KATAKANA), ACTIVESHIELD, CLEAN-UP, DESIGN (STYLIZED E), DESIGN
(STYLIZED N), ENTERCEPT, EPOLICY ORCHESTRATOR, FIRST AID, FOUNDSTONE, GROUPSHIELD, GROUPSHIELD (AND IN KATAKANA),
INTRUSHIELD, INTRUSION PREVENTION THROUGH INNOVATION, MCAFEE, MCAFEE (AND IN KATAKANA), MCAFEE AND DESIGN,
MCAFEE.COM, MCAFEE VIRUSSCAN, NET TOOLS, NET TOOLS (AND IN KATAKANA), NETSCAN, NETSHIELD, NUTS & BOLTS, OIL CHANGE,
PRIMESUPPORT, SPAMKILLER, THREATSCAN, TOTAL VIRUS DEFENSE, VIREX, VIRUS FORUM, VIRUSCAN, VIRUSSCAN, VIRUSSCAN (AND IN
KATAKANA), WEBSCAN, WEBSHIELD, WEBSHIELD (AND IN KATAKANA) are registered trademarks or trademarks of McAfee, Inc. and/or its
affiliates in the US and/or other countries. The color red in connection with security is distinctive of McAfee brand products. All other registered
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 WHICH TYPE OF LICENSE YOU HAVE ACQUIRED, PLEASE
CONSULT THE SALES AND OTHER RELATED LICENSE GRANT OR PURCHASE ORDER DOCUMENTS THAT 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 YOU DO NOT AGREE TO ALL OF THE TERMS SET FORTH IN THE AGREEMENT, DO NOT INSTALL THE SOFTWARE. IF
APPLICABLE, YOU MAY RETURN THE PRODUCT TO MCAFEE OR THE PLACE OF PURCHASE FOR A FULL REFUND.

Attributions

This product includes or may include:

• Software developed by the OpenSSL Project for use in the OpenSSL Toolkit (http://www.openssl.org/). • Cryptographic software written by Eric
A. Young and software written by Tim J. Hudson. • Some software programs that are licensed (or sublicensed) to the user under the GNU
General Public License (GPL) or other similar Free Software licenses which, among other rights, permit the user to copy, modify and redistribute
certain programs, or portions thereof, and have access to the source code. The GPL requires that for any software covered under the GPL which
is distributed to someone in an executable binary format, that the source code also be made available to those users. For any such software
covered under the GPL, the source code is made available on this CD. If any Free Software licenses require that McAfee pro-+34vide rights to
use, copy or modify a software program that are broader than the rights granted in this agreement, then such rights shall take precedence over
the rights and restrictions herein. • Software originally written by Henry Spencer, Copyright 1992, 1993, 1994, 1997 Henry Spencer. • Software
originally written by Robert Nordier, Copyright © 1996-7 Robert Nordier. • Software written by Douglas W. Sauder. • Software developed by the
Apache Software Foundation (http://www.apache.org/). A copy of the license agreement for this software can be found at
www.apache.org/licenses/LICENSE-2.0.txt. • International Components for Unicode ("ICU") Copyright ©1995-2002 International Business
Machines Corporation and others. • Software developed by CrystalClear Software, Inc., Copyright ©2000 CrystalClear Software, Inc. • FEADÆ
OptimizerÆ technology, Copyright Netopsystems AG, Berlin, Germany. • Outside InÆ Viewer Technology ©1992-2001 Stellent Chicago, Inc.
and/or Outside InÆ HTML Export, © 2001 Stellent Chicago, Inc. • Software copyrighted by Thai Open Source Software Center Ltd. and Clark
Cooper, © 1998, 1999, 20 00. • Software copyrighted by Expat maintainers. • Software copyrighted by The Regents of the University of California,
© 1996, 1989, 1998-2000. • Software copyrighted by Gunnar Ritter. • Software copyrighted by Sun Microsystems, Inc., 4150 Network Circle,
Santa Clara, California 95054, U.S.A., © 2003. • Software copyrighted by Gisle Aas. © 1995-2003. • Software copyrighted by Michael A. Chase,
© 1999-2000. • Software copyrighted by Neil Winton, ©1995-1996. • Software copyrighted by RSA Data Security, Inc., © 1990-1992. • Software
copyrighted by Sean M. Burke, © 1999, 2000. • Software copyrighted by Martijn Koster, © 1995. • Software copyrighted by Brad Appleton,
© 1996-1999. • Software copyrighted by Michael G. Schwern, ©2001. • Software copyrighted by Graham Barr, © 1998. • Software copyrighted
by Larry Wall and Clark Cooper, © 1998-2000. • Software copyrighted by Frodo Looijaard, © 1997. • Software copyrighted by the Python Software
Foundation, Copyright © 2001, 2002, 2003. A copy of the license agreement for this software can be found at www.python.org. • Software
copyrighted by Beman Dawes, © 1994-1999, 2002. • Software written by Andrew Lumsdaine, Lie-Quan Lee, Jeremy G. Siek © 1997-2000
University of Notre Dame. • Software copyrighted by Simone Bordet & Marco Cravero, © 2002. • Software copyrighted by Stephen Purcell,
© 2001. • Software developed by the Indiana University Extreme! Lab (http://www.extreme.indiana.edu/). • Software copyrighted by
International Business Machines Corporation and others, © 1995-2003. • Software developed by the University of California, Berkeley and its
contributors. • Software developed by Ralf S. Engelschall <[e-mail]> for use in the mod_ssl project (http:// www.modssl.org/).

• Software copyrighted by Kevlin Henney, © 2000-2002. • Software copyrighted by Peter Dimov and Multi Media Ltd. © 2001, 2002. • Software
copyrighted by David Abrahams, © 2001, 2002. See http://www.boost.org/libs/bind/bind.html for documentation. • Software copyrighted by
Steve Cleary, Beman Dawes, Howard Hinnant & John Maddock, © 2000. • Software copyrighted by Boost.org, © 1999-2002. • Software
copyrighted by Nicolai M. Josuttis, © 1999. • Software copyrighted by Jeremy Siek, © 1999-2001. • Software copyrighted by Daryle Walk er,
© 2001. • Software copyrighted by Chuck Allison and Jeremy Siek, © 2001, 2002. • Software copyrighted by Samuel Krempp, © 2001. See
http://www.boost.org for updates, documentation, and revision history. • Software copyrighted by Doug Gregor ([e-mail]), © 2001,

2002. • Software copyrighted by Cadenza New Zealand Ltd., © 2000. • Software copyrighted by Jens Maurer, ©2000, 2001. • Software
copyrighted by Jaakko Järvi ([e-mail]), ©1999, 200 0. • Software copyrighted by Ronald Garcia, © 2002. • Software copyrighted by
David Abrahams, Jeremy Siek, and Daryle Walker, ©1999-20 01. • Software copyrighted by Stephen Cleary ([e-mail]), ©2000.

• Software copyrighted by Housemarque Oy <http://www.housemarque.com>, © 2001. • Software copyrighted by Paul Moore, © 1999.

• Software copyrighted by Dr. John Maddock, © 1998-2002. • Software copyrighted by Greg Colvin and Beman Dawes, © 1998, 1999. • Software
copyrighted by Peter Dimov, © 2001, 2002. • Software copyrighted by Jeremy Siek and John R. Bandela, © 2001. • Software copyright
Joerg Walter and Mathias Koch, © 2000-2002. • Software copyrighted by Carnegie Mellon University © 1989, 1991, 1992. • Software copyrighted
by Cambridge Broadband Ltd., © 2001-2003. • Software copyrighted by Sparta, Inc., © 2003-2004. • Software copyrighted by Cisco, Inc and
Information Network Center of Beijing University of Posts and Telecommunications, © 2004. • Software copyrighted by Simon Josefsson,
© 2003. • Software copyrighted by Thomas Jacob, © 2003-2004. • Software copyrighted by Advanced Software Engineering Limited, © 2004.

• Software copyrighted by Todd C. Miller, © 1998. • Software copyrighted by The Regents of the University of California, © 1990, 1993, with code
derived from software contributed to Berkeley by Chris Torek.

ed by

PATENT INFORMATION

Protected by US Patents 6,470,384; 6,493,756; 6,496,875; 6,553,377; 6,553,378.

Issued September 2005 / ePolicy Orchestrator® software version 3.6

DBN-002-<EN>

Contents

Walkthrough

1 Introduction 6

2 Installing or Upgrading the Server 12

Components of ePolicy Orchestrator. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

Policy, properties, and events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Policies. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Tasks, services, and accounts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10

Other times when credentials are needed . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Minimum requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Installing for the first time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Pre-installation preparation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Information to have during installation . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Upgrading from a previous version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Preparation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Information to have during the upgrade . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Upgrading issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3 Organizing the Directory and Repositories 18

ePolicy Orchestrator Directory: concepts and roles . . . . . . . . . . . . . . . . . . . . . 18

About ePolicy Orchestrator roles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19

Organizing the Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Environmental borders. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

IP address filters and sorting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Repositories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Source repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Fallback repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Master repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Distributed repository. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4 Deploying the Agent and Products 28

ePolicy Orchestrator agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

About the ePolicy Orchestrator agent. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

Agent installation folder. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

Agent language packages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

The agent installation package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Agent-server communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

SuperAgents and broadcast wakeup calls . . . . . . . . . . . . . . . . . . . . . . . . . 32

Agent activity logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

Distributing agents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

Deploying the agent from ePolicy Orchestrator. . . . . . . . . . . . . . . . . . . . . 35

Installing the agent with login scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Installing the agent manually . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Enabling the agent on unmanaged McAfee products . . . . . . . . . . . . . . . . 38

Including the agent on an image. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

iii

ePolicy Orchestrator®3.6 Walkthrough Guide Contents

Distributing the agent using other deployment products . . . . . . . . . . . . . 39

Distributing the agent to WebShield appliances and Novell NetWare servers

39

About deploying packages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

Package signing and security. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

Legacy product support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

Package ordering and dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

About deploying and updating products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

Product deployment and updating process . . . . . . . . . . . . . . . . . . . . . . . . 42

Deployment task . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

Update tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

Global updating . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

Pull tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

Replication tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

Repository selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

Repository selection by agents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

Selective updating . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

About the SITELIST.XML repository list . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

Checking in product deployment packages manually . . . . . . . . . . . . . . . . . . . 48

Configuring the deployment task to install products on client systems . . . . 49

5 Rogue System Detection 52

The Rogue System sensor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

Machine status and rogue type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

Subnet status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

Distributing Rogue System sensors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

Deploying Rogue System sensors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

Installing the sensor manually. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

Taking actions on detected rogue systems manually . . . . . . . . . . . . . . . . . . . 58

Configuring automatic responses for specific events . . . . . . . . . . . . . . . . . . . 59

6 ePolicy Orchestrator Notifications 61

About Notifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

Throttling and aggregation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

Notification rules and Directory scenarios . . . . . . . . . . . . . . . . . . . . . . . . . 63

Determining when events are forwarded . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

Determining which events are forwarded. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

Rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

Configuring ePolicy Orchestrator Notifications . . . . . . . . . . . . . . . . . . . . . 66

Default rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

Creating rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

Viewing the history of Notifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

Notification summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

Notification list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

Product and component list. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

7 Outbreaks 72

Tasks to do on a daily or weekly basis to stay prepared . . . . . . . . . . . . . . . . . 72

Server and client tasks you should schedule to run regularly . . . . . . . . . 72

Checklist — Are you prepared for an outbreak? . . . . . . . . . . . . . . . . . . . . . . . . .74

Other methods to recognize an outbreak . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .74

Network utilization key indicators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .74

E-mail utilization key indicators. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

Virus detection events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

Checklist — You think an outbreak is occurring . . . . . . . . . . . . . . . . . . . . . . . . 75

iv

ePolicy Orchestrator®3.6 Walkthrough Guide Contents

Lab Evaluation

8 Installing and setting up 78

Setting up a lab environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

Add systems to your Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

Organize systems into groups for servers and workstations . . . . . . . . . . . . . 89

Configure the agent policy settings before deployment . . . . . . . . . . . . . . . . . 91

Deploy agents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

Installing agent manually on client systems. . . . . . . . . . . . . . . . . . . . . . . . . . . 94

Add VirusScan Enterprise to the master repositor. . . . . . . . . . . . . . . . . . . . . y 95

Pull updates from McAfee source repository . . . . . . . . . . . . . . . . . . . . . . . . . . 96

Create a distributed repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

Create a shared folder on the system to use as a repository . . . . . . . . . . 98

Add the distributed repository to the ePolicy Orchestrator server. . . . . . 99

Replicate master repository data to distributed repository . . . . . . . . . . 101

Configure remote sites to use the distributed repository . . . . . . . . . . . . 101

Schedule a pull task to update master repository daily. . . . . . . . . . . . . . . . . 109

Schedule a replication task to update your distributed repository . . . . . . . . 110

Schedule a client update task to update DATs daily . . . . . . . . . . . . . . . . . . . 110

Use SuperAgents to wake up all agents on the network . . . . . . . . . . . . . . . . . 111

Convert an agent on each subnet into a SuperAgent . . . . . . . . . . . . . . . . . . .112

Enable global updating on ePolicy Orchestrator server . . . . . . . . . . . . . . . . 113

9 Advanced Feature Evaluations 114

ePolicy Orchestrator Notification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

Rogue System Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .118

v

SECTION 1

Walkthrough

This section provides a walkthrough of conceptual and best practices information.

Introduction

Installing or Upgrading the Server

Organizing the Directory and Repositories

Deploying the Agent and Products

Rogue System Detection

ePolicy Orchestrator Notifications

Outbreaks

Introduction

1

ePolicy Orchestrator 3.6 is a powerful tool that allows you to manage security policy,
assess and enforce policy, identify and take actions on rogue systems, and notify you
of certain events that occur, all across your entire network.

 Components of ePolicy Orchestrator.

 Policy, properties, and events

 Tasks, services, and accounts

Components of ePolicy Orchestrator

ePolicy Orchestrator is made up of several components that can reside on systems
across your network:

 ePolicy Orchestrator server.

 Database server.

 ePolicy Orchestrator consoles.

 ePolicy Orchestrator agent.

 Rogue System Detection (RSD) sensor.

 Master repository.

6

ePolicy Orchestrator®3.6 Walkthrough Guide Introduction

Components of ePolicy Orchestrator

 Update repositories.

Figure 1-1 ePolicy Orchestrator on your network

1

ePolicy Orchestrator server

The center of your managed environment. One server can manage up to 250,000
systems, but you may be restricted by your bandwidth and other considerations. For
example, network obstacles like firewalls and proxy servers, geographic locations of
sites, and security divisions within your organization.

The server:

 Delivers security policies.

 Controls product and DAT file updates.

 Processes events and serves tasks for all managed systems.

 Provides the mechanism for agent communication.

 Controls data access to and from the ePolicy Orchestrator database.

The ePolicy Orchestrator server should be hosted on a dedicated server. Typically, the
ePolicy Orchestrator server is accessed via remote ePolicy Orchestrator consoles
(installed on other systems), although it can be accessed from a local console as well.

For information on server sizing, see the ePolicy Orchestrator 3.6 Hardware Sizing and
Bandwidth Usage White Paper.

Database server

ePolicy Orchestrator uses a back-end database to store data, which is represented in
the console tree of the user interface. The database contains information from each
managed system.

The reporting and query features of ePolicy Orchestrator (accessed through the
consoles) allow you to view this data in ways you can customize.

7

ePolicy Orchestrator®3.6 Walkthrough Guide Introduction

Components of ePolicy Orchestrator

ePolicy Orchestrator consoles

You can have multiple consoles installed on your network. One resides on the ePolicy
Orchestrator server itself as a local console, and you can install as many as you like
remotely throughout your network.

Typically, you will want one that is accessible to anyone in your environment who needs
to access the ePolicy Orchestrator server. For example, you would want all
administrators to be able to access the ePolicy Orchestrator server from a console to
perform their management tasks. You can assign roles with different rights and
permissions to users.

ePolicy Orchestrator agent

The agent is a vehicle of information and enforcement between the ePolicy
Orchestrator and each managed system. For each of the managed systems, the agent:

 Retrieves updates.

 Executes scheduled tasks.

 Enforces policies.

 Forwards properties and events to the server.

Every system you want to manage must have this component installed.

1

Rogue System Detection (RSD) sensor

Sensors can reside on one or more systems per subnet. The active sensor notifies you
when a rogue system (a system without an ePolicy Orchestrator agent) enters the
environment, and can then initiate a user-defined automatic response on that system,
such as deploying an agent to it.

Sensors “listen” to all broadcast layer 2 communications on the subnets. Although you
can deploy multiple sensors to a subnet, only one is listening at a time. This allows a
minimum of network activity, and ensures one sensor is always listening per subnet.

Master repository

The master repository exists on the ePolicy Orchestrator server and is the central
location for all McAfee product updates. The master repository goes to the McAfee
Download Site (source repository) at defined times to retrieve all available updates and
signatures. The master repository contains a copy of the contents of the McAfee
Download Site that can be accessed by the various update repositories in your
organization.

Update repositories

Update repositories are distributed throughout your environment, providing easy
access for managed systems to pull DAT files, product updates, and product
installations. Depending on how your network is configured, you may want to set up
different types of repositories. You can create HTTP, FTP, and UNC share distributed
repositories anywhere on your network, or you can create an update repository per
subnet by converting an agent on each subnet into a SuperAgent repository.

8

ePolicy Orchestrator®3.6 Walkthrough Guide Introduction

Policy, properties, and events

Policy, properties, and events

Two main purposes of ePolicy Orchestrator are to enforce policies on the managed
systems, and to receive and process properties and events from all of the managed
systems.

Policies

A policy is a set of software configurations. The set of options differs depending on the
product and system you are managing. For example, a policy for VirusScan Enterprise
includes the configuration options for the On-Access Scanner and the On-Demand
Scanner. You can set these configuration options differently for different systems.

Policies are the security product configurations that you want to ensure each site,
group, or individual systems have. Policies are enforced during the policy enforcement
interval. This interval is set to five minutes by default. Therefore, anytime an end user
changes the settings on the system, the settings are returned to those set in the policy
within five minutes.

New to version 3.6 is the ability to create named policies, that you can assign to
independent locations of the Directory.

1

Properties

Events

Properties are collected from each system by the installed agent. These include:

 System information (system name, memory available, etc.).

 Information from installed ePolicy Orchestrator-managed security products (for

example, VirusScan Enterprise).

When a threat or compliance issue on a system is recognized by an installed and
managed security product, an event file is created by the product that the agent
delivers to the server to be processed. These events are processed and stored in the
database.

Events are processed by event parser and applied to the notification rules or ePolicy
Orchestrator Notifications. Notifications is a feature that allows you to configure rules
to alert you to events in your network.

If the event triggers a notification rule, any of the following can happen depending on
the rule’s configurations:

 Notification messages are sent to specified recipients.

 Actions, such as agent deployment, can be taken against the system.

 Specified registered executables can be launched.

9

ePolicy Orchestrator®3.6 Walkthrough Guide Introduction

Tasks, services, and accounts

Tasks, services, and accounts

Several tasks and services of ePolicy Orchestrator require authentication with specific
accounts to complete.

This information is useful if you encounter issues with the following tasks.

Task Service Account

Logging onto the
server

Deploying agents McAfee ePolicy Orchestrator 3.6.0

Upgrading agents McAfee ePolicy Orchestrator 3.6.0

Replicating UNC share
distributed repositories

Replicating FTP
distributed repositories

Replicating HTTP
distributed repositories

Replicating SuperAgent
repositories

Accessing ePolicy
Orchestrator
Notification

Reporting (with an
Authentication Type of
ePO Authentication)

Reporting (with an
Authentication Type of
SQL authentication)

Reporting (with an
Authentication Type of
NT Authentication)

Reporting (with an
Authentication Type of
Currently logged on
user)

Parsing events McAfee ePolicy Orchestrator 3.6.0

McAfee ePolicy Orchestrator 3.6.0
Server (

NAIMSRV.DLL)

ePolicy Orchestrator server
account.

Local system account.

Server (

NAIMSRV.DLL)

Local system account on

Server (

NAIMSRV.DLL)

McAfee ePolicy Orchestrator 3.6.0
Application Server (

TOMCAT.EXE)

McAfee ePolicy Orchestrator 3.6.0
Application Server (

TOMCAT.EXE)

McAfee ePolicy Orchestrator 3.6.0
Application Server (

TOMCAT.EXE)

client system.

Local system account.

Local system account.

Local system account.

McAfee Framework Service ePolicy Orchestrator server

account. (Then the local
system account installs
them.)

McAfee ePolicy Orchestrator 3.6.0
Application Server (

TOMCAT.EXE)

McAfee ePolicy Orchestrator 3.6.0
Server (

NAIMSRV.DLL)

Local system account.

ePolicy Orchestrator server
account. (This account is
used to validate the user,
then the NT or SQL
account is used.)

McAfee ePolicy Orchestrator 3.6.0
Server (

NAIMSRV.DLL)

McAfee ePolicy Orchestrator 3.6.0
Server (

NAIMSRV.DLL)

McAfee ePolicy Orchestrator 3.6.0
Server (

NAIMSRV.DLL)

SQL account.

NT account.

Account of the currently
logged in user. (This
account is used to validate
the user, then the NT or
SQL account is used.)

Local system account.

Event Parser (

EVENTPARSER.EXE)

1

Note

If the local system account’s rights are diminished, installations on client systems of
the agent or security products may fail on client systems.

10

ePolicy Orchestrator®3.6 Walkthrough Guide Introduction

Minimum requirements

Other times when credentials are needed

While performing various tasks in ePolicy Orchestrator, you may be required to provide
user credentials.

Table 1-1 Tasks and credentials

Task Credentials Location stored

Logging on to Active
Directory containers
(set in

Active Directory

Import

wizard)

Deploying agents from
the ePolicy
Orchestrator console
by manually specifying
the user name and
password.

Active Directory administrator
credentials (for each container that is
mapped to the ePolicy Orchestrator

Directory). These credentials are

stored to run as a task.

Credentials with administrator rights
to the desired systems.

If the Active Directory
Discovery task is launched
manually, it runs as the
Microsoft Management
Console.

If the task runs as
scheduled, it runs as
adi.exe using the stored
credentials from an
encrypted file.

Stored in the encrypted

CONSOLE.INI file.

1

Minimum requirements

The following are minimum hardware and software requirements for the ePolicy
Orchestrator 3.6 server.

These are the minimum requirements. The number of systems you plan to manage

Note

Table 1-2 Hardware and software minimum requirements

Hardware Software and Network

500MB free disk space (first-time
installation); 1
recommended.

512

Intel Pentium II-class processor or higher;
450

1024x768, 256-color, VGA monitor User must have administrator rights on the

100MHZ or higher NIC Static IP address recommended

NTFS partition (recommended)

as well as network considerations impact the hardware specifications your solution
requires. For more information on hardware sizing, see the ePolicy Orchestrator 3.6

Hardware Sizing and Bandwidth Usage White Paper.

GB (upgrade); 2GB

MB RAM Microsoft Internet Explorer version 6.0 or

MHZ or higher

Windows 2000 Advanced Server with SP 3 or
later, Windows 2000 Server with SP 3 or later,
Windows Server 2003 Enterprise, Windows
Server 2003 Standard, or Windows Server
2003 Web operating systems.

later.

Trust relationship with the primary domain
controller (PDC).

server.

11

Installing or Upgrading the Server

2

Whether you are installing ePolicy Orchestrator 3.6 as a new installation or upgrading
from prior versions you must understand the minimum system requirements,
preparation tasks on your network, and which pieces of information to take to the
installation or upgrade.

Information on hardware sizing and bandwidth usage are located in the Hardware
Sizing and Bandwidth Usage White Paper.

Installing for the first time

Installing or upgrading the ePolicy Orchestrator server is straight forward, using a
standard installation wizard. However, before running the installation wizard it is
important that you perform certain tasks and have certain pieces of information at hand.

Complete instructions on installing ePolicy Orchestrator are located in the ePolicy

Note

This section covers:

 Pre-installation preparation.

 Information to have during installation.

Orchestrator 3.6 Installation Guide.

12

ePolicy Orchestrator®3.6 Walkthrough Guide Installing or Upgrading the Server

Installing for the first time

Pre-installation preparation

Before installing ePolicy Orchestrator 3.6, complete the following tasks:

 Determine what database you are going to use. ePolicy Orchestrator includes the

Microsoft SQL Database Engine (MSDE) 2000 (Service Pack 3) database which can
be used for all of the reporting and data storage needs. This database has a storage
limit of 2
Orchestrator 3.6 can record approximately 12 months of data for 10,000 client
systems.

If the standard database does not meet your needs, utilize a Microsoft SQL Server
2000 database.

Note

 Update both the ePolicy Orchestrator server system and the ePolicy Orchestrator

database server system with the latest Microsoft security updates.

 Install and/or update the anti-virus software on the ePolicy Orchestrator server and

database server systems and scan for viruses.

 Install and/or update firewall software on the ePolicy Orchestrator server system.

(For example, Desktop Firewall 8.5.)

GB. This means that a standard installation and configuration of ePolicy

McAfee recommends that a dedicated server is used for the database if you are
managing more than 2,000 client systems.

2

 Notify the network staff of the ports you intend to use for HTTP communications via

ePolicy Orchestrator.

Information to have during installation

Have the following information with you during installation, some of which may take
some careful planning:

 Server password.

 Database server.

 Ports you want to use.

 E-mail address for Notifications.

Server password

During the installation wizard, you are asked to provide a password for the
Administrator account to access the ePolicy Orchestrator server. Use a password that
is memorable and contains a combination of alpha- and numeric-characters.

Note

Database server

During the installation wizard, you are asked to select the MSDE 2000 database, or use
an already installed database server on the local system or remote (MSDE 2000, or
SQL Server 2000).

Special characters (for example, %, <,>, and &) are not supported in passwords.

Consider before installing:

13

ePolicy Orchestrator®3.6 Walkthrough Guide Installing or Upgrading the Server

 If you are going to use a database other than the MSDE 2000 provided with ePolicy

Installing for the first time

Orchestrator, you should install the database software before installing ePolicy
Orchestrator.

 If you are planning on managing more than 2,000 systems, use a dedicated server

with Microsoft SQL Server 2000 with Service Pack 3 for the database.

Ports you want to use

As ePolicy Orchestrator runs, there is considerable communication between the server
and the other components. During the installation wizard, you must designate the ports
that the server uses for this communication. Although defaults are provided, we
recommend that you consider strongly the ports that you will assign to the different
types of communication.

Once ePolicy Orchestrator is installed, you cannot change some of these assignments
through the ePolicy Orchestrator console without uninstalling the software.

Make sure that the ports you assign are not already assigned to other products.

 Agent-to-Server communication port — This is the port the agent uses to

communicate with the server. The default port is
after installation.

80. This port cannot be changed

2

McAfee strongly recommends that you change this to another port due to potential
conflicts in many environments. For example, to

Note

 Console-to-Server communication port — This is the port the console uses to

82.

communicate with the server. The default port is 81. This port can be changed after
installation.

McAfee strongly recommends that you change this to another port due to potential
conflicts in some environments. For example, to

Note

installation.

 Agent Wake-Up communication port — This is the port used to send agent

wakeup calls. The default port is

 Agent Broadcast communication port — This is the port used to send

8081. This port can be changed after installation.

SuperAgent wakeup calls. The default port is

83. This port cannot be changed after

8082. This port can be changed after

installation.

 Event Parser-to-Server communication port — This is the port used by Rogue

System Detection and ePolicy Orchestrator Notifications for non-SSL user interface
communication and non-SSL sensor communication. The default port is

8080. This

port cannot be changed after installation.

 Console-to-Application Server communication port — This is the port used by

Rogue System Detection and ePolicy Orchestrator Notifications for SSL user
interface communication and SSL sensor communication. The default port is

8443.

This port cannot be changed after installation.

 Sensor-to-Server communication port — The port used by the Rogue System

Detection sensor to report host-detected messages to the Rogue System Detection
server using SSL. The default port is
installation.

8444. This port cannot be changed after

14

ePolicy Orchestrator®3.6 Walkthrough Guide Installing or Upgrading the Server

Upgrading from a previous version

E-mail address for Notifications

If you want to use the default rules of the ePolicy Orchestrator Notifications feature, you
can provide an e-mail address on the
which you want to receive notification messages when you enable any of the default
rules.

This allows you to use the feature upon implementation, while you are still learning
about it.

Set E-mail Address panel of the installation wizard to

2

Note

The e-mail address can be added or changed after installation.

For complete information and procedures to install ePolicy Orchestrator 3.6, see the
ePolicy Orchestrator 3.6 Installation Guide.

Upgrading from a previous version

You can upgrade or migrate to ePolicy Orchestrator 3.6 if you are currently using:

 ePolicy Orchestrator 3.0.2 or later.

 Protection Pilot 1.0 or later.

 Evaluation versions of ePolicy Orchestrator 3.6.

Note

This section provides information on:

 Preparation.

 Information to have during the upgrade.

You cannot upgrade from beta versions of the software.

Preparation

 Upgrading issues.

Before upgrading to ePolicy Orchestrator 3.6 complete the following tasks:

 Upgrade the database software if it does not meet the minimum requirements.

 Update both the ePolicy Orchestrator server system and the ePolicy Orchestrator

database server system with the latest Microsoft security updates. (Specifically, be
sure to install Service Pack 3 on all MSDE and SQL Server 2000 databases.)

 Install and/or update the anti-virus software on the ePolicy Orchestrator server

system and scan for viruses.

 Install and/or update firewall software on the server system. (For example, Desktop

Firewall 8.5.)

 Notify the network staff of the ports you intend to use for HTTP communications via

ePolicy Orchestrator.

15

ePolicy Orchestrator®3.6 Walkthrough Guide Installing or Upgrading the Server

Upgrading from a previous version

Information to have during the upgrade

Have the following information with you during the upgrade, some of which may take
some careful planning:

 Ports you want to use.

 E-mail address for Notifications.

Ports you want to use

As ePolicy Orchestrator runs, there is considerable communication between the server
and the other components. During the installation wizard, you must designate the ports
that the server uses for this communication. Although defaults are provided, we
recommend that you consider strongly the ports that you will assign to the different
types of communication.

Once ePolicy Orchestrator is installed, you cannot change some of these assignments
through the ePolicy Orchestrator console without uninstalling the software.

Make sure that the ports you assign are not already assigned to other products.

 Agent-to-Server communication port — This is the port the agent uses to

communicate with the server. The default port is
after installation.

80. This port cannot be changed

2

McAfee strongly recommends that you change this to another port due to potential
conflicts in many environments. For example, to

Note

 Console-to-Server communication port — This is the port the console uses to

82.

communicate with the server. The default port is 81. This port can be changed after
installation.

McAfee strongly recommends that you change this to another port due to potential
conflicts in some environments. For example, to

Note

installation.

 Agent Wake-Up communication port — This is the port used to send agent

wakeup calls. The default port is

 Agent Broadcast communication port — This is the port used to send

8081. This port can be changed after installation.

83. this port cannot be changed after

SuperAgent wakeup calls. The default port is 8082. This port can be changed after
installation.

 Event Parser-to-Server communication port — This is the port used by Rogue

System Detection and ePolicy Orchestrator Notifications for non-SSL user interface
communication and non-SSL sensor communication. The default port is

8080. This

port cannot be changed after installation.

 Console-to-Application Server communication port — This is the port used by

Rogue System Detection and ePolicy Orchestrator Notifications for SSL user
interface communication and SSL sensor communication. The default port is

8443.

This port cannot be changed after installation.

 Sensor-to-Server communication port — The port used by the Rogue System

sensor to report host-detected messages to the Rogue System Detection server
using SSL. The default port is

8444. This port cannot be changed after installation.

16

ePolicy Orchestrator®3.6 Walkthrough Guide Installing or Upgrading the Server

Upgrading from a previous version

E-mail address for Notifications

To use the default rules of the ePolicy Orchestrator Notifications feature, you can
provide an e-mail address on the
which you want to receive notification messages when you enable any of the default
rules.

This allows you to use the feature upon implementation, while you are still learning
about it.

Set E-mail Address panel of the installation wizard to

2

Note

For complete information and procedures to upgrade to ePolicy Orchestrator 3.6, see
the ePolicy Orchestrator 3.6 Installation Guide.

Upgrading issues

If your agents are not upgrading to version 3.5 agents, and you’re running VirusScan

7.0.0 on those systems, you may need to physically go to these systems and perform
the following steps:

1 Stop any of the following processes that are running:

FRMWORKSERVICE.EXE, or UPDATERUI.EXE.

2 Force uninstall the agent by running

command line. (
directory.)

3 Go back to the ePolicy Orchestrator server and deploy an agent to the system.

The e-mail address can be added or changed after installation.

NAPRDMGR.EXE,

FRMINST.EXE /FORCEUNINSTALL from the

FRMINST.EXE is located in the Common Framework installation

17

Organizing the Directory and

3

Repositories

The ePolicy Orchestrator software requires you to configure and set up several
components. Although extensive, the configurations allow you to customize the
product specifically for your environment. Carefully planning the implementation of
your ePolicy Orchestrator solution is essential before installing the software.

You should consider how your:

 Directory should be organized.

 The client systems should receive their updates.

This chapter contains the following sections:

 ePolicy Orchestrator Directory: concepts and roles.

 Repositories.

ePolicy Orchestrator Directory: concepts and roles

The Directory allows you to combine systems into sites and groups. Combining
systems with similar properties or requirements allows you to manage policies for
these groupings in one place, rather than having to set policies for individual systems.
It can also make visually browsing your Directory much easier.

Before discussing Directory organization further, it is important to define some terms:

Directory

The Directory contains all your managed network systems that you are managing with
ePolicy Orchestrator. It is possible to add all the systems to be managed by ePolicy
Orchestrator into one site in the Directory. However, this flat unorganized list makes
setting specific policies for different systems very difficult. Therefore, organizing the
systems in smaller units within the Directory is essential.

Sites

A site is a first-level group immediately under the Directory root of the console tree.
Systems contained within a site can be organized into groups. Sites can contain groups
and individual systems.

Groups

A group is a secondary grouping beneath a site. It can contain more groups
(sub-groups) and individual systems, but a group cannot contain a site.

18

ePolicy Orchestrator®3.6 Walkthrough Guide Organizing the Directory and Repositories

ePolicy Orchestrator Directory: concepts and roles

Lost&Found groups

Lost&Found groups store system names whose locations could not be determined by
the ePolicy Orchestrator server. The administrator (with appropriate rights) must move
the systems in Lost&Found groups to the appropriate place in the Directory to manage
them. Each site has a Lost&Found group, and the Directory has a global Lost&Found
group.

Inheritance

Inheritance is an important property that makes policy administration simpler. Because
of inheritance, child nodes in the Directory hierarchy inherit policies that have been set
at their parent nodes. For example:

 Policies set at the Directory level are inherited by sites.

 Site policies are inherited by groups and individual systems within that site.

 Group policies are inherited by sub-groups or individual systems within that group.

Inheritance is enabled by default for all sites, groups and individual systems that you
add to your Directory. This allows you to set policies and schedule scan tasks in fewer
places.

However, inheritance can be turned off at any location of the Directory to allow for
customization.

3

Let inheritance do the work for you. While you can assign security policies and

Note

schedule client on-demand scans or DAT file update tasks at any node of the
Directory, consider setting policies at the highest-level node possible. If you do, you’ll
have fewer changes to make. Avoid setting policies at the individual system level if
possible.

About ePolicy Orchestrator roles

If you plan to have multiple people administer ePolicy Orchestrator in your environment,
you can create multiple user accounts in the console. Fellow administrators can use
these accounts to log onto the server.

The different types of user accounts include:

 Global administrator.

 Site administrators on page 20.

 Global reviewers on page 21.

 Site reviewers on page 21.

Global administrator

Global administrators have read and write permissions and rights to all operations.
When you install the server and console, a global administrator account with the user
name

admin is created.

You can create additional global administrator accounts for other people who need
global administrative rights to all aspects of the console.

19

ePolicy Orchestrator®3.6 Walkthrough Guide Organizing the Directory and Repositories

ePolicy Orchestrator Directory: concepts and roles

Global administrators can use the console to deploy agents and security products,
change agent or product policies, create and run client tasks for updating DAT files or
performing on-demand scans for any node in any site in the Directory. In addition, only
global administrators can perform certain server-based functions.

Only global administrators can perform the following repository management
functions:

 Define, edit, or remove source and fallback repositories.

 Create, change, or delete global distributed repositories.

 Export or import the repository list from the server.

 Schedule or perform pull tasks to update the Master Repository

 Schedule or perform replication tasks to update distributed repositories

 Check packages into the master repository, move packages between branches, or

delete packages from the master repository.

Only global administrators can perform the following server management functions:

 Change server settings and work with server events.

 Schedule Synchronize Domains server tasks.

3

 Verify the integrity of IP management settings, or change site-level IP subnet masks.

 Add and delete user accounts.

 View and change all options on all tabs in the Events dialog box, if using ePolicy

Orchestrator authentication.

 Import events into ePolicy Orchestrator databases and limit events that are stored

there.

 Create, rename, or delete sites.

Site administrators

Site administrators have read, write, and delete permissions and rights to all operations
(except those restricted to global administrator user accounts) for one or more
products, and one or more sites in the Directory.

Site administrators can use the console to deploy agents and security products, change
agent or product policies, create and run client tasks for all groups or systems within
their sites in the Directory (for products to which they have permissions). Site
administrators can also run reports, but the reports show only data on systems located
within their sites. The site administrator is able to see, but not change, other sites in
the Directory.

Best practices information

Create site administrator accounts if you have a very decentralized network with no
single global administrator account or where different local administrators have local
control over their parts of the network. For example, your organization may have sites
located in different cities or countries, and these sites may have local IT or network
administrators with rights to install and manage software on systems in that part of the
network.

You can also create site administrator accounts if you have administrators who you
want to only have ePolicy Orchestrator permissions to specific products.

20

ePolicy Orchestrator®3.6 Walkthrough Guide Organizing the Directory and Repositories

ePolicy Orchestrator Directory: concepts and roles

Global reviewers

Global reviewers can view, but not edit, all settings in the console (except for Rogue
System Detection), including property settings, policy, and task settings for all nodes in
the Directory. Global reviewers can also run enterprise-wide and site-specific reports.

Site reviewers

Site reviewers can only view settings and run reports for specified products within
specified sites of the Directory.

Organizing the Directory

The Directory is a hierarchical tree structure that allows you to group your systems
within units called sites and groups. Grouping systems with similar properties or
requirements into these units allows you to manage policies for collections of systems
in one place, rather than having to set policies for each system separately.

As part of the planning process, consider the best way to divide systems into sites and
groups prior to building the Directory.

3

Sites

A site is a primary-level unit immediately under the Directory root in the console tree.
Traits of sites include:

 Sites can only be created by global administrators.

 A site can include both groups and systems.

 Sites (and their groups and systems) are administered by a global administrator or

by a site administrator who has ownership of the specific site. (Site administrators
have administrative rights only over the sites to which ownership has been
assigned.)

 Each site contains a Lost&Found group; a temporary container for systems for

which ePolicy Orchestrator wasn’t able to automatically place in the correct location
within the site.

Groups

A group is a secondary-level (or subsequent level) unit of the Directory. Traits of groups
include:

 Groups can be created by global administrators, or the site administrator of the site

to which the group belongs.

 A group can include both groups and systems.

 Groups are administered by a global administrator or by the site administrator of the

site to which the group belongs.

 Groups do not contain a Lost&Found group.

21

ePolicy Orchestrator®3.6 Walkthrough Guide Organizing the Directory and Repositories

ePolicy Orchestrator Directory: concepts and roles

Lost&Found groups

The Directory root and each site includes a Lost&Found group. Depending on the
methods you use to create and maintain Directory segments, the server uses different
characteristics to determine where to place systems within the Directory. Lost&Found
groups store systems whose locations could not be determined by the server.

Best practices information

If you delete systems from the Directory, you also need to uninstall the agent from
these systems. Otherwise, these systems continue to appear in the Lost&Found group
because the agent continues to communicate to the server.

Environmental borders

How you implement ePolicy Orchestrator and organize the systems for management
depends significantly on the borders that exist in your network. Borders influence the
organization of the Directory differently than the organization of your network topology.

McAfee recommends evaluating the following borders in your network and
organization, and whether they must be taken into consideration when defining the
organization of your Directory.

3

Topological

Your network is already defined by domains or Active Directory containers. The better
organized your network environment, the easier it is to create and use the Directory.

Geographical

If your organization includes facilities in multiple geographic locations, even on multiple
continents, this must be taken into consideration when building your Directory.
Available bandwidth and administrative roles must be considered when your
organization has multiple locations.

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

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

 You can set update policies for the site or group so that all systems update from one

or more distributed software repositories located nearby.

 If sites are located in other countries, you can deploy language-specific versions of

the agent or security software to these systems at once.

 You can configure the update and product deployment policies for these systems

once.

 You can schedule tasks to run at off-peak hours.

22

ePolicy Orchestrator®3.6 Walkthrough Guide Organizing the Directory and Repositories

ePolicy Orchestrator Directory: concepts and roles

Political

Many large networks are divided because different individuals or groups are
responsible for managing various portions of the network. Sometimes these borders
do not coincide with the topological or geographical borders. Who you want to access
and manage the various segments of the Directory can affect how you structure it.

Functional

Some networks are divided by the roles of the groups and individuals using the
network; for example, Sales and Engineering. Even if the network is not divided by
functional borders, you may need to organize the Directory by functionality if different
groups of users require different policies.

Different business groups may run different kinds of software that require special
anti-virus or security policies. For example, you may want to arrange your e-mail
exchange servers or SQL database servers into a group and set specific exclusions for
VirusScan Enterprise on-access scanning.

When planning, focus on the access individuals require or have to the ePolicy
Orchestrator server or nodes, and the borders you must accommodate.

3

IP address filters and sorting

In many networks, subnets and IP address information reflect organizational
distinctions, such as geographical location or job function. If these organizational units
reflect your needs to organize systems for policy management, consider using them to
create your Directory structure by setting IP address filters for sites and groups. ePolicy
Orchestrator provides tools, such as an IP sorting task that can automatically place
systems in the correct site or group according to IP address. This can be a very
powerful tool for automatically populating your Directory and making sure systems stay
in the intended locations.

If you use IP filters, you must set the IP filtering properties at each level of the Directory
properly. Know that:

 To set an IP filter for a group, you must also set IP filters in parent groups or sites.

 The IP ranges specified in lower-level groups must be a subset of the IP range of the

parent.

 IP filters cannot overlap between different groups. Each IP range or subnet mask in

a given site or group must cover a unique set of IP addresses that cannot be
contained in other filter settings in other sites or groups.

After creating groups and setting your IP filters, run an IP integrity check task to make
sure your IP filter hierarchy is valid. This task alerts you if there are any conflicts or
overlaps between IP filters for different sites or groups.

You can assign IP ranges or IP subnet mask values to sites and groups as you create
them, or add or edit them at any time later.

IP filtering for the first time

When the agent calls into the server for the first time, the system is placed in the
Directory location to which it has been assigned. The server searches for the
appropriate site whose IP mask or range matches the agent’s IP address.

23

ePolicy Orchestrator®3.6 Walkthrough Guide Organizing the Directory and Repositories

ePolicy Orchestrator Directory: concepts and roles

Automatically populating the Directory with this method is the result of an algorithm
that uses both IP filters you create and domain information for the NT domain to which
the new system belongs.

Be careful if you have sites or groups in your Directory with the same name as NT

Tip

domains. The domain name search rule takes precedence over the IP group rule.

If you want the system to populate the appropriate location, create the IP group under
the site or group associated with the domain, or do not create the domain group under
the site.

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

1 Site IP filter — If a site with a matching IP filter is found, the system is placed in

that site based on the criteria in this order:

a In a group named the same as the NT domain to which the system belongs.

b In a group with a matching IP filter.

If no group match for IP address or domain name is found, the system is placed in the

Note

Lost&Found group of the site.

3

2 Site Domain name — If no site is found with a matching IP filter, the server

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

3 No site IP filter or domain name match is found — If the server cannot find an IP

or domain name match in any site, the server adds the system to the global
Lost&Found.

Best practices information

This feature is useful when not using ePolicy Orchestrator to deploy agents to systems
on your network. If you use another distribution method, the agent is installed on the
system before the system is added to the Directory. After the agent installs and calls
into the server for the first time, ePolicy Orchestrator adds it to the Directory. If you set
IP filters for the sites and groups, the system is added to the appropriate location.
Otherwise, it is added to the

Lost&Found group and you must move it manually to the

appropriate group. Especially in a large network, using IP filters to get the system in the
right location can save time.

Automatic IP address sorting does not apply to systems that you add to the Directory

Note

using Active Directory integration.

24

ePolicy Orchestrator®3.6 Walkthrough Guide Organizing the Directory and Repositories

Repositories

Repositories

Before implementing the ePolicy Orchestrator software, you should decide the type of
update repositories to use, and how they should be organized.

Source repository

The source repository provides all updates for your master repository. The default
source repository for clean installations is the McAfee FTP update site (FtpSite), but
you can change the source repository or even configure multiple source repositories if
you require. McAfee recommends using the McAfee HTTP (HttpSite) or FTP (FTPSite)
update sites as your source repository.

You can download updates manually and check them into your master repository.

Note

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 repository contents to the master repository.

However, using a source repository automates this process.

3

The McAfee update sites provide virus definition (DAT) and scanning engine file
updates (SCP templates and Spam rules are also available if the corresponding
managed products are in the master repository as well). All other packages and updates
must be checked into the master repository manually.

Fallback repository

The fallback repository is a repository from which managed systems can retrieve
updates when their usual repositories are not accessible. For example, when network
outages or virus outbreaks occur, accessing your established update infrastructure may
be difficult. Therefore, managed systems can remain up-to-date in such situations. The
default fallback repository is the McAfee HTTP download site (HTTPSite) for clean
installations, upgrades keep the designated repository. You can only define one fallback
repository.

Source repositories can be used as a fallback repository, but fallback repositories
cannot be created manually.

Master repository

The master software repository maintains the latest versions of security software and
updates for your environment. This repository is the source of software and updates for
the rest of your environment. There is only one master repository for each ePolicy
Orchestrator server.

The master repository is configured when installed. However, you must ensure that
proxy server settings are configured correctly. By default, ePolicy Orchestrator uses
Microsoft Internet Explorer proxy settings.

25

ePolicy Orchestrator®3.6 Walkthrough Guide Organizing the Directory and Repositories

Repositories

Distributed repository

Distributed repositories host copies of your master repository contents (although you
can restrict which files get copied from the master repository to each of the distributed
repository). Consider using distributed repositories and placing them throughout your
network strategically to ensure managed systems are updated while network traffic is
minimized, especially across slow connections.

As you update your master repository, ePolicy Orchestrator replicates the contents to
the distributed repositories, instead of to each system.

A large organization can have multiple locations with limited bandwidth connections
between them. Distributed repositories limit updating traffic across low-bandwidth
connections. If you create a distributed repository in the remote location and configure
the systems within the remote location to update from this distributed repository, the
updates are copied across the slow connection only once — to the distributed
repository — instead of once to each system in the remote location.

Systems to use for distributed repositories

Use an existing server to host the distributed repository. Although you do not need to
use a dedicated server, the server should be large enough for the desired systems to
connect for updates. Servers are better than workstations because they are more likely
to be running all the time.

3

Types of distributed repositories

ePolicy Orchestrator supports four different types of distributed repositories. Consider
your environment and needs when determining which type of distributed repository to
use. You are not limited to using one type, and may have the need to use several,
depending on the nature of your network.

SuperAgent repositories

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

McAfee recommends using SuperAgent repositories and global updating together to

Note

SuperAgent repositories have several advantages over other types of distributed
repositories:

 Folder locations are created automatically on the host system before adding the

 File sharing is enabled automatically on the SuperAgent repository folder.

 SuperAgent repositories don’t require replication or updating credentials.

ensure your managed environment is up-to-date.

repository to the repository list.

Note

Although SuperAgent broadcast wakeup call functionality requires a SuperAgent in
each broadcast segment which contains managed systems, this is not a requirement
for SuperAgent repository functionality. Managed systems only need to “see” the
system hosting the repository.

26

ePolicy Orchestrator®3.6 Walkthrough Guide Organizing the Directory and Repositories

Repositories

SuperAgents and global updating use a proprietary protocol, SPIPE.

FTP repositories

If you are unable to use SuperAgent repositories, you can use an existing FTP server to
host a distributed repository. Use your existing FTP server software such as Microsoft
Internet Information Services (IIS) to create a new folder and site location for the
distributed repository. See your web server documentation for details to create a site.

HTTP repositories

If you are unable to use SuperAgent repositories, you can use an existing HTTP server
to host a distributed repository. Use your existing HTTP server software such as
Microsoft Internet Information Services (IIS) to create a new folder and site location for
the distributed repository. See your web server documentation for details to create a
site.

UNC share repositories

If you are unable to utilize SuperAgent repositories, create a UNC shared folder to host
a distributed repository on an existing server. Be sure to enable sharing across the
network for the folder so that the ePolicy Orchestrator server can copy files to it.

3

Unmanaged repositories

If you are unable to use managed distributed repositories, ePolicy Orchestrator
administrators can create and maintain distributed repositories that are not managed
by ePolicy Orchestrator.

If a distributed repository is not managed, a local administrator must keep the
repository up-to-date manually.

Once the distributed repository is created, you can use ePolicy Orchestrator to
configure managed systems of a specific Directory site or group to update from it.

McAfee recommends that you manage all distributed repositories through ePolicy

Tip

Orchestrator. Managing distributed repositories with
global updating, or scheduled replication tasks frequently ensures your managed
environment is up-to-date. Only use non-managed distributed repositories if your
network or organizational policy do not allow managed repositories.

ePolicy Orchestrator and using

27