can you expand on why you would not just use EPO to deploy it, seeing as you have to have EPO in the picture anyway?
Sure... If it has to be deployed using ePO then there is a lot more manual intervention. The person building would kick of the build which installs the McAfee agent as part of the build script, then contact the ePo admin, he would then wait for the machine to talk back or prompt it, schedule or drop the machine in a group where the deplyment task for EEPC is set and send a wake up call a few times. We have a quick new build process with over 50 engineers capable of doing the builds. If we used a third party tool or added it as part of the build script it would save this admin. I am aware you will manually need to add the user to the machine but that part is fine. Otherwise I see it as this using ePO ...
a, New laptop is built with McAfee Agent on.
b, You wait or script communication so it populates in the ePO console.
c, You drag it into a group that is set to deploy the two elements of EEPC
d, You send several Wake up calls to kick off the installs.
e, Reboot the PC
f, Machine start encryption
f, Manually add the user to the machine with the ePO Console and send Wake up call
Does that make sense?
Thanks for replying
All I can say is I agree with Superhoop. We provision via a script. (Popular 3rd party tool) and it would be helpful to provision the agent and EEPC client at the time of deployment to avoid the extra communication (and delay) with the ePO admin. Then again, I am very new at this product, I admit. I am looking to seperate the functions of the ePO admin vs. the Desktop Support (Encryption) admins. If we could deploy the product via MSI and have the option to enable (or not enable) a given policy, and file within any given group, that would be very helpful.
You can deploy through third party tools. We know we do it.
You can extract the agent and engine take the msi from the agent and the engine run those from batch files, vbs etc and the product is installed. After a reboot it will check in with ePO and if that user is assigned to the device it will kick off encryption.
Our deploy process is much like everyones, drop an image, run some batch/vbs etc to install and tweak any apps you have. Reboot and off to the user.
We take an additional step of having our SCCM/Altiris/control system reach out and run a remote job, say inventory, on the box, because the service account is part of the assigned group (root level in ePO) it will kick off encryption.
So now that you have it encrypting, now the issue becomes assigning users to the devices. If your object lands in the correct place in ePO, it can inherit users from its location in ePO, ala OUs in AD? We have to assign manually.
To address why you woulnt have ePO do it, well, we dont want to deploy to more than a few at a time, we have user education to over come, we also are reimaging each device we encrypt and it gives us an opportunity to deal with any unintended complications, say like Sonys, USB settings not configured correctly in BIOS, issues with it calling home to ePO.
You can absolutely deploy via third party tool. The process is detailed in a blog post I wrote here: https://community.mcafee.com/community/business/data/blog/2010/04/01/how-to-depl oy-endpoint-encryption-for-pc-v6-via-third-party-tool