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)