cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Level 9
Report Inappropriate Content
Message 1 of 14

Client Task configuration to downgrade product - FRP 5.1.0 to 5.0.10

Jump to solution

We want to downgrade our users from FRP 5.10 to 5.0.10. The client task that we created, does seem to work for about 50 % of the machines but not for the rest.

It is a product deployment configured like below.

   Type: Continuous

   Action 1: uninstall FRP 5.10

   Action 2: install FRP 5.0.10

   Run at every policy enforcement

   Start time: immediately

I noticed however that the sequence of specified actions switches to the wrong order each time I go into the Edit Deployment page. Looks like, you cannot actually specify an ordered sequence of actions.

I guess the question is, what is the best practice to achieve the intended downgrade?

Thank you very much in advance for your help!

1 Solution

Accepted Solutions
Highlighted
McAfee Employee
McAfee Employee
Report Inappropriate Content
Message 3 of 14

Re: Client Task configuration to downgrade product - FRP 5.1.0 to 5.0.10

Jump to solution

Hi @FA1,

Thank you for your post. First, I would recommend reaching out to FRP or Data protection team to confirm if this downgrade is recommended and possible. If you are already well aware of the same, the sequence can be achieved using Tagging.

And to explain how Tagging can be implemented, this is the best forum.

First, the current plan of action does not have high rate of success, why?

You have one task with 2 actions which does not guarantee you the chronology of execution especially when the actions are to uninstall and install.

Having 2 different tasks with the same schedule (set as run immediately) might not be helpful as well.  The cleanest way to do it would be to first assign an uninstall task to all machines that are in the newer  version 5.1.0. and set it to Run Immediately.

Now the actions need to be completed and we need to act upon these machines based on the result.

Hence create a Server task to run tag Criteria. Set the Criteria for the tag you will create to be based on FRP Version to be blank (as that is what is expected when product is removed). Let this task run once in every 2 hours.

Create a client task to Install FRP 5.0.10 and while assigning the client task, it is very important to select Send this task to only computers which have the following criteria -> has any of these tags: "the newly created Tag". the schedule can be set to Run Immediately.

This will ensure that the task you deploy is applied only to those machines with the tag applied on it.

The explanation of execution of the above is given below:

  1. Whenever the client without any tags assigned to it receives the assigned uninstallation task, it will uninstall the product.
  2. After uninstallation as per the tag schedule, the tag assignment will happen for this machine since it's FRP version is blank.
  3. Now we also have an install task that will run ONLY when the machine has the specified tag!
  4. Hence the machine should now have the required old version installed.

All this is automated and you do not have to worry about client that may communicate late after uninstallation happens. The tag application happens once in every 2 hours as it is a Server task now and the task will be run on all machines with this tag applied.

Please note: Although the machines have always been communicating with the ePO, when a tag based task is assigned, the task is not accepted the machines until it is also assigned with the relevant tag. That is how this should give you a better success rate!

I am sure this is not the shortest answer available, but really hope this helps you come up with a good plan for execution and helps in resolving your query. Sincerely hope this helps. Please feel free to reach out to me if you need any further clarifications on the above method.

EDIT:

Alternate Solution for Tagging if ePO 5.9.1 is in use:

"you would create a tag with no criteria, create a query to look for the desired systems you want to have that tag.  Then set up a server task to run that query with a sub action of apply tag.  Query would need to be a table type." - @cdinet 

@FA1 : I have added both the solutions above for your kind convenience. However, as mentioned earlier, please do not hesitate to mark both the posts as solutions as one forum can contain many solutions and can be used as desire by fellow community members who may have the same question.

Happy to be of assistance!

Was my reply helpful?
If you find this post useful, Please give it a Kudos! Also, Please don't forget to select "Accept as a solution" if this reply resolves your query!

Thanks and regards,
Adithyan T

View solution in original post

13 Replies
Highlighted
McAfee Employee
McAfee Employee
Report Inappropriate Content
Message 2 of 14

Re: Client Task configuration to downgrade product - FRP 5.1.0 to 5.0.10

Jump to solution

Hello,

Thanks for your post.

For downgrading, I would like to suggest you to please use two separate task one is for remove and another one is for install.

You can create a product deployment task from the Client Task Catalog and assign it to the machines, One is for remove and another one is for Install.

Was my reply helpful?
If you find this post useful, Please give it a Kudos! l Also, Please don't forget to select "Accept as a solution" if this reply resolves your query!

Highlighted
McAfee Employee
McAfee Employee
Report Inappropriate Content
Message 3 of 14

Re: Client Task configuration to downgrade product - FRP 5.1.0 to 5.0.10

Jump to solution

Hi @FA1,

Thank you for your post. First, I would recommend reaching out to FRP or Data protection team to confirm if this downgrade is recommended and possible. If you are already well aware of the same, the sequence can be achieved using Tagging.

And to explain how Tagging can be implemented, this is the best forum.

First, the current plan of action does not have high rate of success, why?

You have one task with 2 actions which does not guarantee you the chronology of execution especially when the actions are to uninstall and install.

Having 2 different tasks with the same schedule (set as run immediately) might not be helpful as well.  The cleanest way to do it would be to first assign an uninstall task to all machines that are in the newer  version 5.1.0. and set it to Run Immediately.

Now the actions need to be completed and we need to act upon these machines based on the result.

Hence create a Server task to run tag Criteria. Set the Criteria for the tag you will create to be based on FRP Version to be blank (as that is what is expected when product is removed). Let this task run once in every 2 hours.

Create a client task to Install FRP 5.0.10 and while assigning the client task, it is very important to select Send this task to only computers which have the following criteria -> has any of these tags: "the newly created Tag". the schedule can be set to Run Immediately.

This will ensure that the task you deploy is applied only to those machines with the tag applied on it.

The explanation of execution of the above is given below:

  1. Whenever the client without any tags assigned to it receives the assigned uninstallation task, it will uninstall the product.
  2. After uninstallation as per the tag schedule, the tag assignment will happen for this machine since it's FRP version is blank.
  3. Now we also have an install task that will run ONLY when the machine has the specified tag!
  4. Hence the machine should now have the required old version installed.

All this is automated and you do not have to worry about client that may communicate late after uninstallation happens. The tag application happens once in every 2 hours as it is a Server task now and the task will be run on all machines with this tag applied.

Please note: Although the machines have always been communicating with the ePO, when a tag based task is assigned, the task is not accepted the machines until it is also assigned with the relevant tag. That is how this should give you a better success rate!

I am sure this is not the shortest answer available, but really hope this helps you come up with a good plan for execution and helps in resolving your query. Sincerely hope this helps. Please feel free to reach out to me if you need any further clarifications on the above method.

EDIT:

Alternate Solution for Tagging if ePO 5.9.1 is in use:

"you would create a tag with no criteria, create a query to look for the desired systems you want to have that tag.  Then set up a server task to run that query with a sub action of apply tag.  Query would need to be a table type." - @cdinet 

@FA1 : I have added both the solutions above for your kind convenience. However, as mentioned earlier, please do not hesitate to mark both the posts as solutions as one forum can contain many solutions and can be used as desire by fellow community members who may have the same question.

Happy to be of assistance!

Was my reply helpful?
If you find this post useful, Please give it a Kudos! Also, Please don't forget to select "Accept as a solution" if this reply resolves your query!

Thanks and regards,
Adithyan T

View solution in original post

Highlighted
Level 9
Report Inappropriate Content
Message 4 of 14

Re: Client Task configuration to downgrade product - FRP 5.1.0 to 5.0.10

Jump to solution

AdithyanT,

thank you very much for the detailed and structured explanation. I only have one difficulty. I am not sure how to assign the tag to the systems after FRP has been uninstalled.

You say "Set the Criteria for the tag you will create to be based on FRP Version to be blank". My assumption is that I should go to the Tag Catalog, create a new tag and specify the necessary criteria (approximately: FRP version = blank). Unfortunately, the FRP version is not available as Tag criterion in our version of ePO (5.9).

I wonder therefore whether will need to use a query in someway to accomplish the tagging. Or, is it possible to assign client tasks to query results directly?

 

 

Highlighted
McAfee Employee
McAfee Employee
Report Inappropriate Content
Message 5 of 14

Re: Client Task configuration to downgrade product - FRP 5.1.0 to 5.0.10

Jump to solution

Yea, only 5.10 epo version has ability to create tag criteria based on product versions.  So, you would create a tag with no criteria, create a query to look for the desired systems you want to have that tag.  Then set up a server task to run that query with a sub action of apply tag.  Query would need to be a table type.

Was my reply helpful?
If this information was helpful in any way or answered your question, will you please select Accept as Solution in my reply and together we can help other members?

Highlighted
Level 9
Report Inappropriate Content
Message 6 of 14

Re: Client Task configuration to downgrade product - FRP 5.1.0 to 5.0.10

Jump to solution

So, there is no way to directly use the query result as a target for a client task. Correct?

 

If not, that would be a nice enhancement.

 

Thank you!

Highlighted
McAfee Employee
McAfee Employee
Report Inappropriate Content
Message 7 of 14

Re: Client Task configuration to downgrade product - FRP 5.1.0 to 5.0.10

Jump to solution

Yes, you can - you can set the sub action to run client task, but that would not be advisable if you are sending it to a lot of systems at once.  Run client task now is meant for small one-off deployments, not a lot at once.  If that is the case, go for it.  

Was my reply helpful?
If this information was helpful in any way or answered your question, will you please select Accept as Solution in my reply and together we can help other members?

Highlighted
Level 9
Report Inappropriate Content
Message 8 of 14

Re: Client Task configuration to downgrade product - FRP 5.1.0 to 5.0.10

Jump to solution

Actually, I was thinking to use it for a scheduled task.

Highlighted
McAfee Employee
McAfee Employee
Report Inappropriate Content
Message 9 of 14

Re: Client Task configuration to downgrade product - FRP 5.1.0 to 5.0.10

Jump to solution

I don't believe assigning a client task assignment as a scheduled task is an option in the server task actions.  So you would need to have it apply the tag, then have the client task set to assign only if that tag is applied.  In that case, it effectively is assigning a scheduled task.

Was my reply helpful?
If this information was helpful in any way or answered your question, will you please select Accept as Solution in my reply and together we can help other members?

McAfee Employee
McAfee Employee
Report Inappropriate Content
Message 10 of 14

Re: Client Task configuration to downgrade product - FRP 5.1.0 to 5.0.10

Jump to solution

Hi @FA1,

I guessed I typed too slow! @cdinet has already cleared off your queries I presume. and Scheduled task would be a bad idea. Reason: You would have a lesser success ratio with it. Endpoints that never received that task because of communication gap are going to fail. We can not nail the difference of time for both these tasks as we would not know when the clients would sync up with server, thereby we have every chance of running the tasks in reverse order - Back to square 1. hence I would recommend tagging here!

Was my reply helpful?
If you find this post useful, Please give it a Kudos! Also, Please don't forget to select "Accept as a solution" if this reply resolves your query!

Thanks and regards,
Adithyan T
You Deserve an Award
Don't forget, when your helpful posts earn a kudos or get accepted as a solution you can unlock perks and badges. Those aren't the only badges, either. How many can you collect? Click here to learn more.

Community Help Hub

    New to the forums or need help finding your way around the forums? There's a whole hub of community resources to help you.

  • Find Forum FAQs
  • Learn How to Earn Badges
  • Ask for Help
Go to Community Help

Join the Community

    Thousands of customers use the McAfee Community for peer-to-peer and expert product support. Enjoy these benefits with a free membership:

  • Get helpful solutions from McAfee experts.
  • Stay connected to product conversations that matter to you.
  • Participate in product groups led by McAfee employees.
Join the Community
Join the Community