McAfee Agent 4.0 - Comments and Complaints
Recently I deployed McAfee Agent 4.0 to one of our company's ePO 4 Server and Windows workstation clients after a bit of testing with relative success.
For those interested, the master list of support articles for the 4.0 Agent is located here:
https://knowledge.mcafee.com/SupportSite/dynamickc.do?externalId=615002&sliceId=SAL_Public&command=show&forward=nonthreadedKC&kcId=615002
Release notes are available here:
https://knowledge.mcafee.com/SupportSite/dynamickc.do?sliceId=SAL_Public&command=show&forward=nonthreadedKC&externalId=615005
Major changes to the Windows agent include the ability to detect laptops and x64 OS's and query/tag based on those properties (which also means you can now leverage things like only deploying PreScan to Win32 clients, or only applying HIPS to laptops without using a 3rd party deployment tool), changes to the sitelist.xml format that allow for DNS and NetBIOS-based entries instead of solely IP-based, as well as changes to the installer format.
Since the new McAfee Agent 4.0 enters itself in Add/Remove Programs, I created a WQL query to create a collection that would identify those that did not have the McAfee Agent listed in ARP. In the future, I'll need to change this to query on version but currently this is how I'm identifying clients that need the upgrade:
select SMS_R_System.ResourceID,SMS_R_System.ResourceType,SMS_R_System.Name,SMS_R_System.SMSUniqueIdentifier,SMS_R_System.ResourceDomainORWorkgroup,SMS_R_System.Client from SMS_R_System where Name not in (select SMS_R_System.Name from SMS_R_System inner join SMS_G_System_ADD_REMOVE_PROGRAMS on SMS_G_System_ADD_REMOVE_PROGRAMS.ResourceID = SMS_R_System.ResourceId where SMS_G_System_ADD_REMOVE_PROGRAMS.DisplayName = "McAfee Agent")
This WQL statement will definitely need to be revised in the near future to account for version variations. When I make the adjustments, I'll post them here.
Incidentally, McAfee Windows Agent 4.0 Hotfix 1 has been released. (FYI The build version for this particular hotfix is 4.0.0.1318 vs. 4.0.0.1180 for the shipping version)
You'll need to open a case with PrimeSupport in order to receive it however as it is not yet available via the PrimeSupport portal. More details here:
https://knowledge.mcafee.com/article/200/616270_f.SAL_Public.html
Resolved issues:
- Issue: The McAfee Agent's ability to perform updates is blocked when the name of the installation or data folders includes an extended ASCII character. (Reference: 404111)
Resolution:The McAfee Agent's ability to update is no longer blocked if the installation or data folder names include an extended ASCII character. - Issue: The McAfee Agent process "RunPullTask" would run, but it wouldn't copy SiteStat.xml to the specified mirror location. (Reference: 409637)
Resolution:The McAfee Agent process "RunPullTask" now creates a SiteStat.xml file in the appropriate mirror location. - Issue:When a managed product's plug-in required a reboot, the user was prompted, but the computer rebooted even when the user selected No. (Reference: 410573)
Resolution:The McAfee Agent now responds correctly based on the user's selection.
Impressions of McAfee Agent 4.0:
Although I can't say installation went off flawlessly (more on that in a moment), the installation was completely transparent to the end user and the new x64 and IsLaptop properties seem to be detected correctly on clients, as I have tags automatically applied based on these criteria and they began functioning immediately. I cannot speak for the changes to the sitelist.xml as we're not basing our repositories on DNS or NetBIOS, I can only say that the clients are still updating properly post-installation.
Gripes about installation:
Just like many McAfee updates before, despite the fact that I alter my deployment and update tasks accordingly, often days and/or weeks before checking an update package into the server, I still find that the update will be applied to numerous machines where the task explicitly states not to update that particular component. In this case, checking in Agent 4 resulted in it being deployed to numerous machines where the deployment task should have prevented its installation. One of the advantages of ePolicy Orchestrator 4 is the ability to view task inheritance and review that no task inheritance is broken (or at least only those you want broken), and I verified this days before checking in the package. In an environment such as ours where due to compliance issues we tightly regulate the deployment of *ANY* software update, this is unacceptable.
It isn't as if I haven't observed this many times in the past in multiple environments, but it is disappointing to see that it is still an issue. I don't know if this is a remnant of the glitches I've observed in 3.6, but I'm hopeful that the 4.0 agent may address this glaring flaw moving forward. I guess I'll find out when I begin applying McAfee VirusScan 8.5 Patch 6.1...