Hopefully this discussion gets some attention. We are a medium sized organization and manage approximately 400 PCs/Laptops with Mcafee Drive Encryption. We saw great presenations by Mcafee sales reps of the product and we even went over options within EPO to facilitate the patching of machines that have EPO installed by using the various autoboot features. We were sold.
I've already opened up a case with Mcafee support, and the tier 2 engineer state that "Regarding the use of Automatic Booting to allow patches to be applied on a scheduled basis, your configuration is best practice." Makes me feel like we did something right...
- Mcafee Support has said with regards to Automatic Booting used for patching is best practice.
- Page 52 in the MDE 7.1 Product guide says that the Temporary Autobooting feature "Allows you to turn (on or off) the PBA screen, with a client-side utility. This eliminates the need to modify the policy in McAfee ePO, and fully automates patching and other client management scenarios."
But say for example we do patching on Friday evening at 8pm. In order for the patching system to complete it's task, the PCs being patched must be rebooted multiple times. Obviously if the pre-boot authentication screen is active during patching, most likely the user won't be there waiting around to sign the computer into the system everytime the PC is restarted because of patches. What Mcafee recomends for such common scenarios is to disable automatic booting during this patching window.
So thats what we do for patching, enable auto-boot for the duration of the patching job. Then Monday morning rolls around and the user is presented with their Windows logon screen(not the pre-boot screen because remember automatic booting was enabled for patching). The user logs onto Windows and continues with their job. Our standard domain policy is that the user must change his/her password every 90 days. So a month or two may roll by, and maybe a few more patching jobs will run within that time which requires the use of autoboot. Eventually the user will be prompted to change their password, either at initial logon, or if they change their password with the ctrl+alt+del method. So far so good right? Now maybe a few more patching jobs are run with autoboot feature enabled and the user logs into their PC the following business morning after patching and they are still in business.
Well what happens if the user needs to restart the PC, or the PC is restarted for other purposes, such as the installation of new software? Well, the user would be brought to the pre-boot screen, but this time, when it's time for them to enter their password they fail. They may try this about 5 times, entering in their password carefully. Then they call IT and we are scratching our heads wondering what is going on - why in the world is their password not sync'd? We look at the logs and don't see anything obvious.
Earlier this week, we experienced an overload of calls coming into our small IT department. We had 20+ calls all with the same symptoms! We were lucky if the user remembered their LAST windows AD password, because if they did, they could get past pre-boot, log onto Windows with their NEW password, at which point - Mcafee syncs the Windows AD password so on subsequent reboots this would not be an issue.
We are not a unique organization in our patching work flows. We can no longer reccomend this product for our business units and partners until the Mcafee Drive Encryption team comes up with a solution or a documented workaround for organizations that MUST patch for compliance, and that MUST patch for security.
For any Mcafee support representitive who responds back with, just fill out a PER, this is just an embarssment and highlights even more the products failure to integrate into an envrionment that conducts routine patches of their systems. To say that, this is how the product is designed is saying "Our product is horrible and does not integrate well into Windows AD systems that undergo routine patching."
Now I must reinvent the wheel, because I have seen no workaround from Mcafee.
I ask, what can we do to avoid this?
1. After each patching job, and when the autoboot is disabled, restart the systems so the user will sign into pre-boot with their current crednentials?
2. Restart our systems once per week, to minimize the effect?
I'd like to hear from anyone who must routinely patch their systems and use this product in a Windows AD envrionment. I want to know what your process is for patching your systems and using MDE.
Message was edited by: acsmashing on 7/16/14 4:23:14 PM CDT