cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Former Member
Not applicable
Report Inappropriate Content
Message 61 of 63

Re: VSE 8.8 Patch 2

Jump to solution

Thanks for the info - and yep I use tags during testing but my overall system is fairly flat therefore I don't segregate jobs that run too much.  I also have used SuperAgents in the past but in many different areas this isn't an option either.  Thanks for the sanity check and I guess I may need to use tagging a bit more to help with these issues going forward.

Appreciate the insight!

Former Member
Not applicable
Report Inappropriate Content
Message 62 of 63

Re: VSE 8.8 Patch 2

Jump to solution

I have been using the method of tagging suggested in the "Intelligent way" paragraph for some time, going back to ePO 4.5 days.  It works like a charm.   For deployments I further limit the query to just certain groups (containers).  Then every deployment day just add the new groups.  Eventually the whole tree is in scope and I remove the group restrictions in the query.   Then I just let it run until the next patching cycle.  Automatically catches the road warriors when they finally come into the office.  Catches machines when someone reimages with an old image.  If you are not using this,  you should be.

Thanks

Herb

Former Member
Not applicable
Report Inappropriate Content
Message 63 of 63

Re: VSE 8.8 Patch 2

Jump to solution

Hello,

We created for each software we deploy, a compliant tag (just a tag we created like C_AGENT to indicate that this system has a compliant agent)

We created a server task we run once a day with two steps for each product we deploy :

* step 1 : run query to see if systems are NOT runnning the desired software we want and REMOVE the TAG C_xxx (ex C_AGENT if the agent software is not up to date)

* step 2 : run query to see if systems are runnning the desired software we want and ADD the TAG C_xxx (ex C_AGENT if the agent software is up to date)

The deployment task are checking NOT to have the C_xxx tag for that component and DO have the tag "MANAGED" (see at the end of this explanation how the "managed" tag is used and is only needed if you want to delay updates after fresch installs/stagings)

When we check in a new software, this is not deployed until we change the compliant query for that software.

This way of working eliminates :

* that every client is checking multiple times a day if it is running the lates software

* that the McAfee update process interferes with the staging/updating process in the company (resulting in MSI conflicts during staging, updating, ....) because the task are becomming active after the dayly server taks run.

For newly staged machines we extended this process with two extra TAG's. 

Every night we check with a server taks for machines that :

* step 1 : have the tag "NEW" (next lines explain how systems get that tag), give them the tag "MANAGED" and remove the tag "NEW

* step 2 : have the status "managed" (NOT the TAG managed) and dont' have the tag "Managed".  These systems get the tag "NEW"

Message was edited by: jj4sec on 10/19/12 4:02:37 PM CEST
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