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.
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.
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.
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...
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.
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.
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.