Release notes are available as a PDF download here, and the release notes addendum is here. The updated Agent supports ePolicy Orchestrator 4.5 (Patch 2 or later) in addition to ePolicy Orchestrator 4.6, and includes the following new features:
Run now - You can now run client tasks on demand. ePolicy Orchestrator software 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 ePolicy Orchestrator server and the agent client, the task sent with Run Client Task Now runs the next time the agent communicates with the ePolicy Orchestrator server.
SuperAgent lazy caching - SuperAgent repositories now only pull content when needed from ePolicy Orchestrator servers instead of receiving all content on push replications. This reduces the bandwidth required to distribute content to SuperAgent repositories. The SuperAgent repository also caches any packages it has pulled, so subsequent requests by endpoints are served locally without pulling from the master repository. In previous versions, SuperAgent repositories pulled all content from the master repository regardless of whether it was actually needed.
Performance improvements - The Agent now uses less CPU time, and allows you to reduce Agent process priority to improve performance of your other applications.
Repository policy refactored - A new Repository policy category allows you to configure repository policies independently from general policies. You can now set your general policies globally and your repository policies locally. In addition, you can now use drag-and-drop to reorder the repository list.
Default policy type for large organizations - McAfee Agent now provides a default policy type specifically designed for large organizations called Large Organization Default. This policy is intended as a starting point from which large organizations can create their own custom policies, and includes policies in the General category.
Agent event refinements - The level of detail included in events that are generated in response to a failure has been enhanced. Property collection and
policy enforcement failure events are now reported on first instance only. Additionally, events generated from product update and product deployment failure events are more precise.
Endpoint language selection - McAfee Agent 4.6 allows you to configure, through policy settings, the language used by the agent. This is useful when your administrators or support personnel speak a different language that the one used by the endpoint users. This language selection overrides the local settings. It is used for both the agent user interface on the client, and the agent log files generated by that client. Note If you configure the agent to use a language other than the users' selected language, the text displayed in the agent user interface on their system will be in the language you selected, and not the same as the rest of the users' interface. Also, regardless of language selection, some detailed log text remains in English for troubleshooting purposes by McAfee.
Improved cluster awareness - The agent is now more aware of the network cluster environment in which it resides, and sends additional cluster and node properties back to ePolicy Orchestrator.
Agent deployment to UNIX-based systems - You can now deploy agents to some UNIX-based systems using push deployment. Push deployment is currently supported for Macintosh OS versions 10.5 (Leopard) and 10.6 (Snow Leopard), and Red Hat Linux Enterprise versions 4, 5, and 6.
UNIX-based Command Agent tool - The Command Agent tool (cmdagent) is now available on all operating systems supported by McAfee Agent 4.6. The Command Agent allows you to control the agent on the endpoint by invoking actions such as policy enforcement, collecting and sending properties, and checking for new policies and tasks on the server.
You can download the new Agent from the McAfee Downloads website here.
I’ve recently been deploying a few new Secondary Sites for our Configuration Manager environment at work, so I decided to make a quick walkthrough on how to deploy a new Secondary Site on Windows Server. I’m posting it here as well, in case anyone else can use it for their benefit.
Steps to Deploy a New Secondary Site
- Grant new server account access to AD Systems Management container (Full Control)
- Add new server account to SMS_SiteToSiteConnection_SITECODE on Primary Site
- Create 0-byte NO_SMS_ON_DRIVE.SMS and copy to the root of any drives you wish to exclude from SMS packages
- Add Windows Server Features
- BITS Server Extensions
- Remote Differential Compression
- Add Windows Server Role Services
- ASP.NET
- (and ASP if using as a reporting point)
- Windows Authentication
- IIS6 Metabase Compatibility
- IIS6 WMI Compatibility
- Install WebDAV
- Configure IIS WebDAV
- Enable WebDAV on Default Web Site (or SMSWEB if using a custom site)
- Add Authoring Rule
- All content
- All users
- Read permission
- WebDAV settings
- Allow Anonymous Property Queries – True
- Allow Custom Properties – False
- Allow Property Queries with Infinite Depth – True
- NOTE: If you receive a “WebDAV is not set up properly” error during MP setup later and you *know* you’ve configured the above properly, you may want to refer to this blog post courtesy Ithastobecool.com: http://bit.ly/iYBHRF
- Install Configuration Manager with Custom Settings and select the Secondary Site option
- Install KB 977384 (Configuration Manager 2007 R3 Prerequisite)
- Install Configuration Manager 2007 R3
- Install Configuration Manager 2007 Toolkit 2
- Copy all *.PCK files from the SMSPKG directory on the Primary Site Server to a new SMSPKG directory created on the new Secondary Site
- Execute PreloadPkgOnSite.exe from the Configuration Manager 2007 Toolkit against the *.PCK files on the Secondary Site. To automate the process, I used a modified version of the PowerShell script shown here in John Marcum’s blog post: http://bit.ly/jd3lUx
- NOTE: If you have not previously done so, you’ll need to adjust the PowerShell settings to allow for the execution of scripts using the command Set-ExecutionPolicy Unrestricted –Force
- Copy Packages via the Configuration Manager console to the new Secondary Site
- Monitor the Secondary Site’s distmgr.log for package errors
- Configure Site Roles as desired
Technet also has a reference on setting up a Secondary Site that is a good reference: http://bit.ly/mIHkjY
Release notes are available here. The patch resolves 3 issues, and includes the following new features:
SiteAdvisor Enterprise Plus
- All policies support ePolicy Orchestrator 4.5 policy assignment rules
- Rating Actions policy exceptions for red and yellow sites based on threat factors
- Event Tracking policy to track all visits to domain sites with options for private domains
- Authorize/Prohibit List policies support port numbers in site patterns
- Enforcement Messaging policy option to include a corporate logo in messages
- General policy option to hide SiteAdvisor Enterprise Plus in the Add/Remove Programs control panel
- Improvements to the client interface
- General policy option to configure SiteAdvisor Enterprise Plus to stand down from its enforcement and site rating operations
when a web gateway is detected - Improvements in the Safesearch functionality
Web Filtering for Endpoint
- Content Action policy to indicate the action (block, warn, allow) for a site based on site content
- Reports that include website content categorization
Browser support
- SiteAdvisor Enterprise Plus now supports Microsoft Internet Explorer 9, 32 bit only
Related KnowledgeBase here, release notes available here. McAfee considers this a “recommended” release. As per their ratings system, this is defined as “McAfee recommends this release for all environments. This update should be applied at the earliest convenience.” This patch addresses 11 identified issues.
The patch is available on their support portal, accessible here.
The hotfix resolves the following issues:
The hotfix is available by contacting technical support – it is not currently available via the support portal.
Release notes available here. McAfee considers Patch 9 a “Critical” release. As per their ratings system, this is defined as “McAfee considers this release to be critical for all environments. Failure to apply a Critical update may result in severe business impact.”
The Patch resolves 17 issues, including one reported security vulnerability.
The patch is available on their support portal, accessible here.
Release notes available here. McAfee considers Patch 5 a "High Priority" release. As per their ratings system, this is defined as “McAfee considers this release a high priority for all environments. Failure to apply a High Priority update may result in potential business impact.”
In addition to the 18 resolved issues in Patch 5 detailed in their release notes, McAfee reports the following improvements:
Patch package size has been reduced with the removal of ePolicy Orchestrator 3.6.x NAP and Report extension files for VirusScan Enterprise, due to ePolicy Orchestrator 3.6.x End of Support.
The ePolicy Orchestrator Reports extension file has been updated to more appropriately reflect the expected results of the current default queries.
The patch is available on their support portal, accessible here.
I manage an ePolicy Orchestrator 4.5 environment and we’ve been replacing some of our systems functioning as Rogue System Sensors with new systems running Windows 7. Unfortunately, the deployment task I’ve had to deploy the new sensors did not appear to be executing – in fact, inspecting all the C:\ProgramData\McAfee\Common Framework\Task\*.ini on the systems didn’t even show a sensor deployment task.
Eventually it was determined that Windows 7 is not a supported operating system for a Rogue System Detection Sensor on ePolicy Orchestrator 4.5, therefore the agents were not processing the task.
McAfee recently published an article, located here, which details the platforms supported for Rogue System Detection under ePolicy Orchestrator 4.5 and 4.6, but to sum it up:
Windows Server 2003, 2008, XP, and Vista are supported under ePolicy Orchestrator 4.5 as Rogue System Detection Sensors. There is no mention of support for 2008 R2.
Windows Server 2003, 2008, 2008 R2, XP, Vista, and Windows 7 are supported under ePolicy Orchestrator 4.6 as Rogue System Detection Sensors.
Sensors for both 4.5 and 4.6 can be deployed to both 32-bit and 64-bit Operating Systems, but the sensor remains a 32-bit program.
No backwards compatibility between different sensor versions
No backwards compatibility between different sensor version policies
As a result of this, it looks like I’ll be upgrading to ePolicy Orchestrator 4.6 pending management approval. I’ll post an updated blog with my findings post-upgrade, but in the meantime, I hope this information is useful to anyone else that may have experienced similar issues with Rogue System Sensor deployments.
I recently encountered an issue where packages mysteriously stopped arriving to a Branch DP which had never experienced problems in the past. I though I would share my process and the solution in case it benefits others that may experience a similar problem.
Copying packages to the related site (also a Protected DP) was successful. However, attempting to copy the same package to a Branch DP site system left the package status state at “Install Pending”. Checking the Status messages showed that the site was processing the packages successfully, but no further activity.
Checking the PeerDPAgent.log on the Branch DP in question revealed some interesting entries:
Download failed for content CTM job {XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX}, error 0x800705b4
Package XXX00000 in state 'HostingIncomplete'.
Using my handy-dandy Error Lookup tool within SMS Trace (Control-L for the ConfigMgr Ninjas), I immediately knew that 0x800705b4 translated to “This operation returned because the timeout period expired.” and it gave me a pretty decent hunch that this was boundary related.
A quick web search also led me to this thread which had some basic checklist items for a Branch DP:
Can the BDP communicate to the site server? Yup.
Does the “parent” DP have BITS enabled? Sure thing!
If the “parent” DP is a Protected DP, and if so, is the BDP within the protected boundary? Of course! Hey, wait a minute…
As it turns out, someone had taken the liberty of changing the system to use DHCP instead of the previously assigned static IP. This caused the to IP change on the BDP, and it was no longer within the protected boundary for the “parent” DP. As a result, it had no DP to pull the packages from and would eventually timeout.
I hope this information helps others out there in case they run into a similar situation – if you’re using Protected DP’s, always ensure that your BDP is within the protected boundary… and if things start getting “stuck”, don’t forget to check the IP 
(As an aside, if you’re interested in information on the internals of a Branch DP, I’d also recommend this post by Steve Rachui, it’s a great reference)
As per their notice, new features Include:
- Streamlined installation and guided configuration wizard: deliver highly efficient enterprise-class security management to new small and medium-sized customers
- Software Manager for direct access and check-in of product updates; eliminates download site visits
- Client Tasks can now be managed just like policies: import, export and manage tasks or policies from a central catalog
- Tag-Based Policy Assignment precisely targets assignment of pre-defined security profiles to systems based on their business role or at-risk status
- Modified System Information view answers customers’ requests for a single screen showing properties and history of an endpoint
- Streamlined dashboard management includes drag-and-drop editing, dynamic monitor resizing, and custom URLs, plus enhanced export features
- Advanced reporting: provides report templates customized to a user’s company and personalized for various audiences
- Customer Web APIs and python scripts: allow admins to build workflows that integrate security management into their business and automate repetitive tasks such as synchronizing endpoint information with other IT platforms; adding/deleting users; executing queries to integrate data with other tools; and adding data to ePO
- Leveraging the McAfee user community admins can share best of breed dashboards, scripts, queries, and policies with their peers.
- FIPS 140-2 level 2 validation: ePO 4.6 will be submitted for this high level security validation to support requirements of Federal customers and customers who do business with the government.
A master list of support articles related to ePolicy Orchestrator 4.6 can be found here, while the product can downloaded from here with a valid grant number.
Release Notes available here. Fixes 79 issues, available for download here with your McAfee Grant Number.
McAfee’s Stinger malware removal tool has been updated to version 10.1.0.1361. The tool is available for download here.
Today I checked in McAfee’s latest and greatest enterprise VirusScan product into my software repository. Installing the VIRUSSCAN8800(169).zip extension was a non-issue, but when I attempted to install VIRUSCANREPORTS120(136).zip, I received the below error:
Unable to install extension. Installation error: upgrade: [echo] Upgrade called for VIRUSCANREPORTS (version 1.2.0.136) BUILD FAILED C:\PROGRA~1\McAfee\EPOLIC~1\server\extensions\installed\VIRUSCANREPORTS\1.2.0.136\install.xml:730: java.sql.SQLException: Violation of UNIQUE KEY constraint 'U_OrionQueryGroup_Name'. Cannot insert duplicate key in object 'dbo.OrionQueryGroups'. Total time: 2 seconds
A little searching on the web led me to this thread in the McAfee Management Platform community and I was able to successfully install the VIRUSCANREPORTS120(136).zip extension after following the advice of trimone:
- From the ePolicy Orchestrator console, select “Queries”
- Under the “Groups” column, select “VirusScan Enterprise”
- Under “Group Actions”, select “Delete Group”
- Confirm your selection
- Retry installing the extension (Menu –> Software –> Extensions –> Install Extension)
The VirusScan Enterprise Extensions should now show “VirusScan Enterprise Reports” as 1.2.0.136.
A paper has been published by SySS GmbH illustrating that under certain circumstances this vulnerability can be exploited to escalate the privileges of the local user.
Their paper is available here for those interested in reviewing it in detail. For the rest reading, I’ll summarize it:
The SiteList.xml and ServerSiteList.xml files used by the McAfee agent have read permissions granted to all users of the local system. These files contain information regarding what repositories the client will use for product updates as well as the account credentials used to connect to them. The account password is encrypted within the file, however SySS was able to develop a python script that can decrypt the passwords with ease. This can be particularly concerning in environments using UNC repositories, as the domain account and password used to access the repository may have escalated privileges over what the local user has.
My takeaways from this?
- Don’t assume that any password hash is secure.
- Ensure that any account credentials used for repositories only have access to the repository data and nothing more.
- If you’re using UNC shares, consider using local accounts instead of domain ones.
Regarding the UNC repositories, McAfee has released KB70999, “Important Information on using Download Credentials in ePO” which details some best practices for securing UNC shares for repository use. The KB can be found here for review.
I myself am wondering what changing the ACL on the “McAfee\Common Framework” directory to something more restrictive might introduce as issues. If anyone has experience with this, I’d be interested to hear your results.
Ran into a situation where I needed to remove a DP from all packages since it have already been previously decommissioned. I’m linking to this extremely helpful script as provided by Russ Slaten here (http://blogs.msdn.com/b/rslaten/archive/2006/03/01/removing-a-retired-dp-from-all-your-packages.aspx) for future reference.
More Posts
Next page »