7 Replies Latest reply on Apr 20, 2011 11:36 AM by SafeBoot

    Modify policies on a single system??


      Hello Simon and All,


      I'm writing here in order to share my bad experience with McAfee Encryption v6.


      I'm working with ePO 4.5 and EEPC 6.0.2 installed on a specified number of machines. Yesterday I was requested to uninstall 4 machines.

      Following the guide i first started deactivating the EEAgent by modifying the product policy. After deselecting "Enable Policy" I saved the changes and went into the policy catalog to make a check.


      The bad surprise was that my policy for encrypting the machines was disabled because of my previous action of modifyinfg the policy on the single system and deselecting the Enable policy checkbox.

      So i faced the situation where all my environment would have the deactivated policy assigned. And probably on the next day I would have all the machines stating System State 'In-active'.


      And of course this is not written in the guide. Again facing same problem as usual - poor documentation and bad support.


      However the situation is not the same for the tasks and modifying the task on a single system does not reflect to the original task....










        • 1. Re: Modify policies on a single system??

          I have also experienced this. When modifying a policy on a single system in the system tree, the policy is also changed for all other systems using that policy.


          This has hopefully been addressed in the new version 6.1.


          Margarita, for decrypting and removing EEPC from machines, i would recommend that you create a seperate group in the system tree, and link a replica of your system policy to that group (call the policy something like 'Decrypt´ or 'Remove EEPC'. Then disable the 'Enable Policy' checkmark, and create client tasks for removing EEPC software and agent in that order.

          • 2. Re: Modify policies on a single system??

            Hi DPE,


            probably I shall consider your proposal.

            However I'm kind of disapponted from this poor documentation which seems to be designed for a lab environment or sth.

            In one of the many requests I have been advised not to deviate in any way from the guides but seems that the guides are not correct enough.




            • 3. Re: Modify policies on a single system??

              Hi Margarita,


              You are wrong in you complaint.  From your post I'm guessing you don't have too much experience with ePO itself.

              This what you are complaint is not actually an issue, this is the way ePO works. You cannot change settings in policy per system, like with client tasks. You can obviously change policy assignment per system which leads to that what DPE suggested you.

              What I can agree is the poor documentation (and not only for EEPC) which have many errors, lacks and often leads to confusion.



              • 4. Re: Modify policies on a single system??

                Hi SCtbe,


                My compliant is actually that again documentation is misleading. Only this sentence :"You cannot change settings in policy per system, like with client tasks" is enough to have a clear understanding on this fact.

                But in the particular instruction it is never mentioned...




                • 5. Re: Modify policies on a single system??

                  Hi Margarita,


                  I agree with you about documentation. However in this case documentation for EEPC assumes that you are familiar with ePO, and the policy assignment topic is part of the ePO documentation, so it was threated to generally in EEPC docs.


                  I'm not defending McAfee and not judging you, my intention is just to be fair in opinions.



                  • 6. Re: Modify policies on a single system??

                    I do not think I fully understand your procedure. It sounds like you went into the policy catalog and changed the setting there. This would cause all systems that use that policy to decrypt/de-activate. If you want to target the decrypt action you should do one of the following


                    Go to system tree and find your system, then check its box and go to actions > agent > modify policies on a single system > choose endpoint encryption from the drop-down menu > click "edit assignment" for the Product Settings policy > choose to break inheritance > choose new policy > this allows you to make a new policy where you would uncheck the "enable policy" option > save the change to the policy and then click save again to finish the new policy assignment.


                    You could also start by going to the policy catalog and makinga  new policy with the "enable policy" box unchecked. Then when you go in to modify the policy for one system, you just have to choose that from the drop-down menu instead of having to make a new policy each time.

                    • 7. Re: Modify policies on a single system??

                      I see this problem mostly with people coming from the V5 world - in EEPC5, each object has its own policy, the original settings for that may have been inherited from a group, but at the end of the day, every user and machine has a policy of its own, and you can usualy go to a machine or user and change that. Certainly, any changes at the user/machine level only affect the object you are working on.


                      in EPO, its all about inheritance - users and machines don't have an in-built policy - they are linked to a discrete policy object, and many may be linked to the same policy object. So, if you find the policy a machine is using in EPO and edit it, the chances are high that more than one machine is using that particular policy. You may think you're editing that machine's personal policy, but that is most often not the case.


                      That's where, as Dan says, the policy catalog comes in. The logic of EPO is you create a small number of policies, and assign many endpoint objects to them as needed.


                      It's a totally different mindset I'm afraid, but much more flexiable and also more aligned with the Microsoft AD/GPO way of thinking.