What is DataChannel?


Enables secure, private, bi-directional communication between a point product running on a managed endpoint and its ePO extension.


  • The data channel subsystem in the Agent requires that the SpipeSite entry in the SiteList.xml file shows that the ePO version is at least 4.5.0.  Otherwise, the subsystem will not start.  The subsystem is implemented to run alongside (asynchronously) to the Agent subsystem (the subsystem which performs ASCI communications). 
  • It is designed to allow for simultaneous ASCI and Data Channel communications for optimal efficiency and without conflict.
  • Product teams can now provide customers troubleshooting oriented UI Actions with real-time feedback. These are UI Actions designed to operate on a single end node while providing real-time status back to the ePO Admin. Examples include Update Now, Scan Now, Run Client Task Now.
  • All datachannel connections between agents and ePO occur over a standard connection to Apache, these are no different than any other secure agent-to-server connection and will be limited by apache’s threshold of 245 active connections per handler.
  • The datachannel relies on the EPOAgentHandlerDatachannelWQ table where each handler polls to receive messages and tasks from tomcat.  Responses are sent directly from the handler’s apache service to tomcat.


EPO 4.5 required connectivity from the master ePO server (tomcat service) to the agent handler directly.  This requirement has been removed in ePO 4.6, notifications from Tomcat to the AH are now sent as datachannel messages.  This means that no direct connection from the ePO server to the remote handler is required.  (responses still require that the handler can contact the master ePO server).


What is Run Client Task now and how it works?


You can now run client tasks on demand. ePO 4.6.0 includes a Run Client Task Now action which, when

using version 4.6.0 of McAfee Agent, queues the selected task to run immediately on the selected systems. If there is a network address translation layer (NAT) between the ePO server and the agent client, the task sent with Run Client Task Now runs the next time the agent communicates with the ePO server.


This will let an ePO administrator select and run a task immediately without initiating a wakeup call. 

The Run Client Task Now feature uses the datachannel to send the request and to monitor updates as the task runs on the client.Run Now tasks open a status window when they are initiated showing progress on all machines selected.This window cannot be reopened after it is dismissed, but the Server Task Log permanently logs all RCTN attempts. There is a limit of 999 simultaneously selected systems for run now

This is defined in epo\server\conf\epo\epo.properties (clienttask.runnow.system.limit)

We should not change this value.


Following are the Backend status codes sent by the agent:












In the ePO interface you will see three segments to the status indicator:


The three steps are Send / Start / Progress. The possible statuses for each step are:


Progress (grey)

Success (green)

Failure (red)


How to troubleshoot Run Client Task Now errors


A permanent store of RCTN events are available in the server task log. Important messages may also be found in the server.log

Run Now tasks may be triggered for multiple machines, but their statuses may take hours to complete.  Different machines will return results asynchronously so the task may take a long time to complete

The AutoId of this server task log entry becomes the CorrelationId for the Run Task Now event.  The Agent guid is the identifier for the subtask when a message is received.

The Correlation id links to main task then agent guid to link to correct subtask

If the services are terminated for any reason, some messages may be lost as they are temporarily held in a memory hashmap. Sometimes a task stays incomplete forever because subtasks are not complete

TASK_NO_FINAL_STATUS was added to address agent restart problem it sends this message before restarting / epo receives and assumes subtask has been completed in unknown state

AGENT ACTIONS (wakeup, push, dc message notification)

Wake-up call and push require that handler can connect directly to agent. 

Agent wake-up will use FQDN/NetBIOS/IP in that order (if present in DB) 

Push uses NetBIOS only-connection

Errors logged in server task log and server.log 

”accept connections only from the epo server”

For 4.5 and later agents only accept from handlers in sitelist.xml. Pre-4.5 agents will only accept connections from first handler in sitelist no matter how many handlers are there.


Handler selection issues:


If “use all handlers” selected, preference is given to last handler used by that agent. 

If that handler is offline or agent has never connected there is no preference and the first handler asking for work will pick up the work request.


Troubleshooting Datachannel issues


Certificates required for DataChannelAH_<Handler Server Name>. Connection problems between AH and ePO. Check server.log for entries like this:

20081216082409 E Srv 11528 McUpload Failed to send http request.  Error=12029 (12029)

20081216082409 E Srv 11528 NAIMSRV  ForwardDataChannelMessageToJava - Failed to send request, err=0x80004005, HTTP status code=0


This can mean a problem with certificates preventing AH from talking to ePO server .A mismatched DCRedirect extension if on the master handler.


In order to check for stuck items in datachannel:


select count(*) as count from epoagenthandlerdatachannelwq select * from epoagenthandlerdatachannelwq where Finished is NULL

One of an ePO administrator's biggest hurdles (especially in small to medium-sized environments) is dealing with the file size limitations of Microsoft’s SQL Express. However, even when dealing with licensed copies of SQL, the ePO database growing in size at an exponential rate is far from ideal. One of the most commonly-diagnosed problems with ePO is a full database – something that when analyzed with a critical eye can expose even more pressing concerns.

ePO stores the vast majority of most product and threat events in the ePOEvents table in SQL – over time, this table will grow in size as events are added from systems managed by ePO. If the number of events being parsed into the database is too high, however, it can often be a sign of misconfiguration. Too often we will avoid the true cause of the issue by simply deleting old events and moving on. Before deleting old events in order to reduce the size of your database, consider doing a bit of detective work to determine the source of the events – especially when dealing with a fast-growing database.

After working with one particular customer on a routine database maintenance issue, they told me that this was the second time in as many weeks that they had called for support. While they were running Microsoft’s SQL Express 2005 (which has a 4 GB database size limit), their database reaching this cap so quickly with only roughly 500 endpoints was alarming. We could keep running delete statements on a regular basis to simply purge the offending tables, but this avoids the real issue – what story are all these events telling me?

The most helpful tools for getting to the bottom of this are Microsoft’s SQL Management Studio and ePO’s own Query and Reports builder. Your first goal should be to use SQL to easily view the most common event ID in the table. These two queries will show you the top 10 most common event IDs for both product events and threat events, respectively:








What you’re looking for (and what we found in this customer’s environment) was that the 1092 event was disproportionately more frequent than any other event ID. Using KB52417, we noted that 1092s indicate VirusScan Enterprise’s Access Protection feature was reporting a blocked event. From there, we need to switch gears over to ePO’s query building functionality. Create a threat event query that returns an ordered list of what specific Access Protection rules were most commonly violated, and what specific EXEs were responsible.

Just like with the 1092s, the results of the query made the cause obvious: by far the most common rule being violated was “Prevent Termination of McAfee Services” – the EXEs responsible for violating the rule were even more suspect : their names were apparently randomly-generated strings of characters. Being familiar with malware, I immediately recognized this as the ZeroAccess Trojan. In other words, a handful of machines with outdated DATs and versions of VSE were responsible for generating tens of thousands of events that were flooding ePO’s database and causing performance issues on the SQL server.

Here’s an example of the style of ePO query I used in that particular instance that you can import into your own ePO server for analysis:







While not every environment may have such a clear-cut culprit, there are often tweaks to policies and settings that can be made within ePO that will reduce the number of events generated and sent to ePO, especially for VSE. It is definitely easier to just delete and forget the events responsible for filling up your database, but with a little detective work you can not only prevent the issue from reoccurring but also tweak and improve policy settings for your McAfee products.


All of the SQL and ePO queries shown above as examples are available as "queries.zip," attached to this blog post. 

If you have McAfee ePO 4.6 or higher in your environment today, and you want an accurate summary of your Intel AMT capable systems - try using a free utility provided by McAfee.


The McAfee ePO Deep Command Discovery and Report Module is a free utility that can provide dashboards and related information such as the following


While many Intel AMT detection capabilities provide only a subset of data points, McAfee's Discovery and Report utility captures over 50 data points.    Even if the Intel Management Engine Interface (MEI) driver is not present, the McAfee utility will capture basic information including the exact OEM and model of the system.

AMT data.jpg

In addition, the McAfee ePO Discovery and Report tool comes with 15 predefined queries.   Adding your own queries in connection with other McAfee ePO collected data is simple.


Learn more about how to discovery and report on Intel AMT capable systems in your environment - https://community.mcafee.com/docs/DOC-3297


The opinions expressed on this site are mine alone and do not necessarily reflect the opinions or strategies of Intel Corporation or its worldwide subsidiaries



About a month ago the following inquiry was made - "My customer is currently using Intel vPro Technology in a LANDesk environment for lifecycle management.   They are interested in using McAfee ePO Deep Command for endpoint security management.   How is this done?"


If the customer is already using Intel vPro Technology, specifically the Intel Active Management Technology, with LANDesk - this is an excellent first step.    It means that Intel AMT is configured, a defined Intel AMT admin password exists, and the environment very likely has TLS enabled with Intel AMT.  


Getting McAfee ePO Deep Command running is a simplified five step process:

  1. Run the Intel AMT Discovery Utility
  2. Update the Intel AMT Credentials
  3. Obtain and import the LANDesk root certificate
  4. Set and enforce Intel AMT policies
  5. Deploy the McAfee ePO Deep Command Client



Using the guidance provided at https://community.mcafee.com/docs/DOC-3316, all of Step 1 with only small parts of Step 2-4 and Appendix B need to be referenced  


Perhaps the most complicated step in the scenario mentioned above is getting the LANDesk root certificate.


Settings and Components from LANDesk Environment


The default Intel AMT configuration settings within LANDesk is to use TLS.

  1. Within the LANDesk console, check the Intel vPro Configuration similar to the following screen.   Ensure the "Use non-TLS communications..." option is unselect (i.e. you want TLS).    If this setting is set for non-TLS, review with your LANDesk administrator before making the change.    If you make a change, LANDesk will immediately start to change the Intel vPro systems to TLS.LANDesk1.png
  2. LANDesk has their own configuration engine for Intel AMT.   The root certificate must be obtained and exported.   You can obtained via an Intel AMT WebUI session or directly from the LANDesk server at the following location (Note: Do not remove or change the cacert.cer file.   If the LANDesk server later resets or updates this certificate, you will need to repeat this process)LANDesk2.png
  3. Copy the cacert.cer file to the McAfee ePO server.   It must be imported into both the Local Computer Trusted Root certificate store and ePO console Server Settings - Intel AMT Credentials.   The following image may differ slightly depending on what version of McAfee ePO and Deep Command you are running.   The process and result are the same. LANDesk3.png
  4. Update the Intel AMT Credential in the McAfee ePO console, exactly matching the Intel AMT password (see first screen shot) used by McAfee.    This is the Intel AMT admin credential
  5. Update your AMT policies on the McAfee ePO console.  
    • NOTE: LANDesk has full support for Fast-Call-for-Help, commonly called "Remote Access" in the McAfee ePO console for AMT policies.    Check with your LANDesk administrator to see if LANDesk has these settings enabled.   If so - LANDesk is the owner of the settings and these should not be changed within the McAfee console to avoid settings conflict or override
  6. To ensure McAfee ePO Deep Command is communicating to Intel AMT correctly, Enforce AMT policies.   Review the amtservice.log to ensure the communications were successful. (default location is c:\Program Files\McAfee\ePolicy Orchestrator\Logs\amtservice.log) LANDesk4.png


The above process is provided "AS-IS".   It worked in a lab environment and per customer feedback.   Validate for you environment.


If you similar questions about running McAfee ePO Deep Command in an environment where Intel AMT was already configured by another console\application, please ask.


The opinions expressed on this site are mine alone and do not necessarily reflect the opinions or strategies of Intel Corporation or its worldwide subsidiaries

While discuss the Alarm Clock feature of McAfee ePO Deep Command with a customer, an interesting question was raised.  "What if the system is in Sleep mode and in the user's bag?   Will the Alarm Clock still work and wake the system?"


The quick answer:  No - Alarm Clock will not wake the system if in Sleep mode and on battery (i.e. DC) power.    The system must be on AC power (i.e. power cord attached)


The reason is provided below with brief explanation.   The two windows shown were actually captured at different times.

  1. The Alarm Clock on a few of my lab systems was set and the systems were put to Sleep
  2. The AC power cord was detached but the network\LAN capable stayed connected.
  3. From a remote system, I attempted to ping the target units.    Systems that were in Sleep mode and on DC\battery power did not respond.
  4. Waited until past the Alarm Clock time to confirm no response.
  5. Reconnect the AC\Power cord to the systems.
  6. While the systems were still asleep, I opened a WebUI session (this shows network connectivity and Intel AMT now functioning)
  7. In the Power Policies section of the Intel AMT WebUI, the default policies is shown




Here is a brief explanation of the selected power policy:


  • ON in S0:  This means that Intel AMT is fully powered when the system is on (i.e. the S0 system power state)
  • ME Wake in S3, S4-5 (AC Only): This means that Intel AMT is accessible when the system is in sleep, hibernate, or off... only when AC power is applied.    The ME Wake portion of the policy refers to an option of the Intel Management Engine's ability to be active yet in a lower power state as defined during the Intel AMT configuration process.


Hopefully the above explanation will answer that lingering question - "Could Intel AMT power-on my system when I'm boarding my next flight?".   Nope - Intel AMT won't.   But if you forget to power down your laptop before take-off, you'll simply have a little less battery power during your flight and the stewardess might be upset before you reach 10,000 feet



The opinions expressed on this site are mine alone and do not necessarily reflect the opinions or strategies of Intel Corporation or its worldwide subsidiaries

If you have started testing Deep Defender in your environment, you may have found a few systems with Intel VT-x disabled.  


Shown below is the McAfee Deep Defender Dashboard.   The Deep Defender Compability test has ran on 5 systems, two are compatible with Deep Defender installed and 3 are listed as incompatible.

Deep Defender Compatibility report.png

A closer look at the three incompatible systems shows VT is disabled

Not compat VT disabled.png

All system are technically compability with Deep Defender.   However, if Intel VT is disabled in the BIOS the compatibility report shows otherwise.


This setting can be changed remotely using OEM specific tools.   If the systems have not yet been deployed, the Intel VT option can be enabled in the BIOS manually or even during the system build process at the OEM.


If the systems are already deployed, a few tips that may help.


  • Lenovo systems - See the Lenovo documentation at http://support.lenovo.com/en_US/research/hints-or-tips/detail.page?&LegacyDocID= MIGR-68488
    • Per the documentation, create the ListAll.vbs and SetConfig.vbs scripts.  
    • Run cscript ListAll.vbs | Find "VirtualizationTechnology"
    • Run cscript setconfig.vbs VirtualizationTechnology Enable
    • Reboot the client to complete the change
    • Rerun the ListAll.vbs script command to confirm change
    • Build a package to automate the sequence  (check is VirtualizationTechnology disabled, enable with script, and reboot client system)
    • Example below shows Intel VT was disabled and enabled.   A reboot of the system is required to complete the change.


Lenovo Enable script.png


  • HP Systems - See the BiosConfigUtility within the HP SSM package available at http://h20331.www2.hp.com/Hpsub/cache/284133-0-0-225-121.html
    • Run BiosConfigUtility.exe /getconfig:current.txt
      • Check with HP to confirm following - if a template captured from platform, due to unique BIOS settings across generations that template can only be provided to similar models
    • Open the current.txt output file (i.e. the Template) and validate Virtualization Technology is set to disable
    • Remove the asterix (*) from disable and place in front of enable.   Save the current.txt file
    • Run BiosConfigUtility.exe /setconfig:current.txt
    • Reboot the system
    • During the system start process, the following screen may appear.   Recommend advising your end-users in advance or asking HP for further guidance

HP BIOS change confirmation.png


  • Dell Systems - Per the tool, guidance, and information provided at http://www.delltechcenter.com/page/Configuring+the+BIOS+using+the+Dell+Client+Co nfiguration+Utility+%28DCCU%29
    • Download DCCU (Dell Client Configuration Utility)
    • Install on a template system (My understanding is that a resulting installation package is specific to the platform model)
    • Once the installation completes, start the Dell Client Configuration Utility.    It will open a webpage to the localhost
    • Summary of multiple steps completed in the following screen include:
      • In the BIOS settings section, select Create BIOS Inventory Package which will generate the TaskResults.xml file in the same directory where DCCU was executed
      • Click Browse and select the TaskResults.xml file that was generated
      • Click Import Collected BIOS Inventory, and the System Information and current select values will refresh and appear below
      • Scroll to the Power and Performance section, and change CPU Virtualization to Enabled


      • Scroll to the bottom of the page.
      • In the After Running selection, change to Restart Computer
      • Click Create BIOS Settings Package to generate and save the executable package
      • Execute the package on the target systems, again aligning package to same models in the environment
        • Note: The package as configured will reboot the client after completion.   Deliver and use the package accordingly.



If you have a different OEM beyond what is listed above,  contact them on available tools or procedures for enabling Intel VT without physically touching each system.


In each case, validate the process on a few test clients before wide deployment and usage.


The opinions expressed on this site are mine alone and do not necessarily reflect the opinions or strategies of Intel Corporation or its worldwide subsidiaries

Come join the ePO Tool Exchange to browse and share dashboards, queries, and Web API scripts that you find useful in your environment. You can see tools others have posted, and request permission to post your own.


Be sure to test any tools thoroughly before loading them in your production environment. McAfee Support can't help you with problems as a result of using these custom tools.


Read the FAQ for more information. See you there!

The ePolicy Orchestrator server always acts as the master information repository. It keeps the master copy of all the content needed by your agents. The server replicates content to other repositories (there are 4 types) distributed throughout your environment. As a result, your agents can retrieve updated content from an alternate and closer repository source.


SuperAgents are one of the four different types of respositories, and offer distinct advantages. If you are starting with a new installation, with no repositories, use a SuperAgent because they are easy to configure and reliable.

SuperAgent repositories

A SuperAgent is a way of creating a McAfee ePolicy Orchestrator repository. The advantage of a SuperAgent is that it is created with the McAfee ePO server and the McAfee Agent.

Using a McAfee SuperAgent reduces the chance of error because you don’t rely on other protocols. Also, the process is less prone to human error because there is minimal data entry, no shares to create beforehand, and no user permissions to adjust. A SuperAgent simply uses any existing McAfee Agent in your environment and does not require any additional software other than the agent itself.

For example, if you have 20,000 McAfee Agents you can easily choose a few to designate as SuperAgents via policy.

SuperAgents have these advantages:

  • Any machine running a McAfee Agent can be designated as a SuperAgent just by changing its policy.
  • You don’t have to connect to the machine to create any shares, set up permissions, or rely on any Microsoft technology such as UNC shares.
  • You don’t have to open ports to enable the SuperAgent functionality. The SuperAgent needs only one open port, the agent wake-up call port you already defined for all your agents (8081 is thedefault port).
  • You don’t have to replicate credentials to SuperAgents. Since your McAfee ePO server is instantly aware of your SuperAgents, it manages replication and adjusts which SuperAgent your clients choose to use for their downloads.

To create a SuperAgent requires these four general tasks. See McAfee ePolicy Orchestrator 4.5 Product Guide for detailed configuration steps.

  1. Create a new SuperAgents policy.
  2. Create a new group in the System Tree, for example named SuperAgents.
  3. Assign the new SuperAgents policy to the new SuperAgents group.
  4. Drag a system into the new "SuperAgents" group.


The following sections describe this process.


Creating a new SuperAgent policy
A SuperAgent policy allows you to assign that policy to client machines to convert them to SuperAgents.


  1. From the Policy Catalog, click McAfee Agent and from the Category list, select General to create a new policy.
  2. Give the new policy a distinctive name, for example SuperAgent policy. A common mistake is accidentally changing your primary McAfee Agent policy and turning all your nodes into SuperAgents.
  3. From the General tab, click Convert agents to SuperAgents and Use systems running SuperAgents as distributed repositories, then type a folder path location for the repository.


Superagents 1.bmp
Creating a new group in the System Tree

With a SuperAgent group in your System Tree you can assign the SuperAgent policy to the group.

Create a new group in the System Tree called 1_SuperAgents.



  1. From the System Tree, click System Tree Actions | New Subgroup and give it a distinctive name, for example 1_SuperAgents.

Superagents 2.bmp

  1. Click OK. The new group appears in the System Tree list.


Assigning the new SuperAgents policy to the new SuperAgents group

When you assign the SuperAgents policy to the new SuperAgents group you complete the configuration of the SuperAgent group.
Assign the new SuperAgents policy to the new SuperAgents group.



  1. From the SuperAgent group you created, click the Assign Policies tab and select McAfee Agent from the product list.
  2. From the Actions column, click Edit Assignments. The McAfee Agent : General dialog box appears.
  3. Click Break inheritance and assign the policy and settings below, select the SuperAgent policy you created from the Assigned Policy list, and click Save.

Superagents 3.bmp


Dragging a system into the new SuperAgents group

With the SuperAgent group configured you can assign the SuperAgent policies to individual client systems simply by dragging them into that group. This converts the client systems into SuperAgents. Change an existing system into a SuperAgent.



  1. In the System Tree, click the Systems tab and find the system you want to change to a SuperAgent repository.
  2. Drag that row with the system name and drop it into the new SuperAgent group you created in the System Tree. Once the system communicates with the McAfee ePO server it changes to a SuperAgent repository.
  3. To confirm the system is now a SuperAgent repository, click Menu | Software | Distributed Repositories and select SuperAgent from the Filter list. The new SuperAgent repository appears in the list.

Superagents 4.bmp

Distributed repositories are file shares that you create to store and distribute important security content for your managed client systems.

They play an important roll in your McAfee ePO infrastructure. How you configure them, and which type you use, depend on the needs of your environment.


About repositories

Repositories are where the agents on your managed systems obtain the security content that keeps your managed environment up to date.

Repository content includes:

• Managed software to be deployed to your clients

• Security content such as DATs and signatures

• Patches and any other software needed to carry out the client tasks you create using ePolicy Orchestrator software

One common misconception some users have is that a repository is created by installing an ePolicy Orchestrator server on a system. However, this is not how repositories are created. A repository is

nothing more than a file share located in your environment somewhere that your clients can access easily. Unlike your server, repositories do not manage policies, collect events, or have code installed

on them.



Calculating bandwidth for client pulls of updates

The bandwidth used to update a new product dramatically increases when updating a new product to clients.

But you can calculate the bandwidth if you know the size of the patch or product being downloaded.

At a minimum, each of your clients must download 200 Kb per day for DAT files. The following examples show how to calculate the bandwidth used for the client updates using this formula:




(Size of update file) x (Number of nodes) = Amount of data pulled per day

The following examples use this formula to calculate the amount of data pulled per day and describe if creating a local repository would reduce the bandwidth.


Example 1 — A small office in India

The small office in India needs to download the 200 Kb per day for DAT files to its 200 nodes. Using the formula:


(200 Kb) x (200 nodes) = 40 MB of data randomly pulled per day to India


In the small office in India you could add a repository but you must replicate the DAT file from the McAfee ePO server to the repository. This file replication uses approximately 70 MB of bandwidth per

day over a slow WAN link could negatively impact the WAN link to India since it would occur all at once.

Instead have the agents connect across the WAN link to the next closest repository to download their DAT file updates. The next office might be in a larger office, for example the Tokyo. The agents can

randomly pull their DAT files throughout the day, and their total bandwidth use is only 40 MB. See Client task to configure the download.


In this case do not use a repository in India.


Example 2 — A large office in Tokyo


The large office in Tokyo needs to download the 200 Kb per day for DAT files to its 4,000 nodes, using

the formula:


(200 Kb) x (4,000 nodes) = 800 MB of data randomly pulled per day to Tokyo


In the large office in Tokyo with 4,000 nodes uses 800 MB of bandwidth per day just to update the DAT files alone. Since replication of the DAT file to Tokyo only uses 70 MB of bandwidth per day it is much more efficient to have a repository in the Tokyo office so all DATs can be pulled across the LAN instead of across the slower WAN link.


Example 3 — A large office in New York City


The large office in New York City needs to download a 23 MB patch update for VirusScan Enterprise to its 1,000 nodes. Using the formula:


(23 MB) x (1,000 nodes) = 23 GB of data pulled to the New York City office


This 23 MB patch is significantly larger than the 200 Kb daily DAT files. You probably have a repository

in New York depending on the speed of the WAN link to New York and how quickly the patch needs to

be pushed out. You might find a balance if you carefully craft your client tasks to pull updates and

patches at a gradual pace instead of deploying the patch to all nodes in one day. See Deploying

products for detailed information.



Some ePolicy Orchestrator users put a repository at geographic sites that have only a few dozen nodes. If your site does not have at least 200 to 300 nodes it cannot benefit from the bandwidth saved using a repository. If there is no local repository, the agents will go to the next nearest repository for their updates. This repository might be across a WAN link but it will still use less bandwidth since you don’t have to replicate the entire repository across the WAN.


The exception to this rule is if you are deploying a larger software package. For example, the VirusScan Enterprise client software is 23 MB. In this case it would be more efficient to place a repository temporarily at a smaller site so the clients software can download the 23 MB file locally.

Then disable this repository once the client is rolled out.


The history ePolicy Orchestrator software



ePolicy Orchestrator software was originally released in 1999, when computer security was just beginning as an industry. McAfee had already released one of its first anti-virus client products, and it was being deployed worldwide using floppy disks exchanged by users. Soon users asked, “how do I manage my anti-virus software once I have it deployed?” McAfee's response to this question was the foundation for ePolicy Orchestrator software.


The first version of McAfee's management tool was called Management Edition 1.0. This tool was useful and generally met the initial needs of customers, but users immediately wanted more. As a result, McAfee rewrote the management server product and the ePolicy Orchestrator software 1.0 was born. Today, McAfee ePO software has evolved to manage many McAfee security products, including:


• McAfee VirusScan Enterprise — Used with Microsoft Windows, Macintosh, and Linux versions

• McAfee Host Intrusion Prevention and Windows Firewall — Provides multiple operating system support

• McAfee SiteAdvisor — Provides URL reputation filtering on the endpoint

• McAfee Policy Auditor — Provides comprehensive systems auditing on multiple operating system’s

• McAfee Network Access Control — Controls access to network resources based on policy

• McAfee Application Control — Prevents unauthorized programs from running

• McAfee Endpoint Encryption — Provides full disk encryption to prevent data loss systems

• McAfee Data Loss Protection — Controls USB devices and unauthorized removal of data

• McAfee Encrypted USB Drives — Manages USB drives with hardware encryption

This list does not include the numerous integrations with McAfee Security Innovation Alliance (SIA)

Partners and integration with McAfee Network products. Some of these McAfee integrated products

include Web Gateway, Network Intrusion Prevention, and Vulnerability Manager.


Overview of the product architecture

The architecture of the ePolicy Orchestrator software and its components provides all the functionality

needed to manage and protect your environment.

The ePolicy Orchestrator server provides these major functions:

• Manages and deploys product policies

• Enforces those policies on all your endpoints

• Distributes all the McAfee software including new products, upgrades, patches, and new content

• Reports on the enterprise network using many predefined reports or customized reports you create

The following figure shows the major ePolicy Orchestrator components.



1 ePO server — Connects to the McAfee update server to download the latest security content

2 ePO Microsoft SQL database — Stores all the data about the managed systems on your network

3 McAfee Agents — Provides policy enforcement, product deployments and updates, and reporting on your managed systems

4 Agent-server secure communication (ASSC) connections — Provides communications that occur at regular intervals between your systems and server

If remote Agent Handlers are installed in your network, agents communicate with the server through their assigned Agent Handlers.

5 Web console — Allows users to log on to the ePolicy Orchestrator console to perform security management tasks, such as running queries to report on security status or working with your managed software security policies

6 McAfee update server — Hosts the latest security content so your ePolicy Orchestrator can pull the content at scheduled intervals.

7 Distributed repositories — Installed throughout your network to host your security content locally, so agents can receive updates more quickly

8 Remote Agent Handlers — Helps to scale your network to handle more agents with a single ePolicy Orchestrator server

9 Ticketing system — Connects to your ePolicy Orchestrator server to help manage your issues and tickets

10 Automatic responses — Provides notifications sent to security administrators when an event occurs



Filter Blog

By date:
By tag: