I have created a report of all our laptops across the country matching "software contains Symantec". This has generated a perfect list, we think, as it accords with the number of licenses we are showing as used for the Symantec Endpoint Protection (SEP), about 300 out of 2100 (we are divesting ourselves of this product).
The trouble is, I do not know how to assign an agent procedure we have created to uninstall SEP as I cannot call up the exact list anywhere in the Agent Procedures - Schedule/Create. And the affected 300 laptops are scattered across different groups.
I cannot use "View" because the results of that do not agree - by a factor of four - with the report. I also cannot simply blanket the whole company with the script because that would entail sending out an email to the whole company saying UAC is going to go ding on a "setup.exe" to remove a product we already removed - but for these last 300 stragglers - 18 months ago.
So I really need some method to just send the script to the people on the list. I am hoping this is a softball, obvious-didn't-think-of-that solution! But I'll take what I can get.
I think there are a couple small issues here.
First, I would fix your view so it was correct. Without knowing your View definition, I have a couple suggestions. Unfortunately, the Views use the Audit Applications instead of Add/Remove, which can make it a little tricky. If you can't get more specific with the built-in Application filters, you could create an Agent Procedure that definitively finds the application and updates a custom field and then base your View on that custom field. We have a lot of custom Views we created using "only show selected machines" and we update the database directly, nightly using a SQL job, to change the selected machines based on other criteria, such as Add/Remove, but that requires some SQL knowledge.
Second, I would wrap some logic in your agent procedure to test for the application before starting the install. This should allow you to run it on any machine without the prompt because the test for the application shouldn't require admin privileges. I would do this regardless of the View or not just as a best practice. I prefer PowerShell instead of actually in the AgentProcedure because you can check a myriad of places (WMI, file system, registry, etc) and do some searching instead of hard coded paths...and it is significantly easier to debug.
Finally, I think we get around some UAC issues by using hstart.exe with the /elevated switch and executing as system. Don't quote me on that because we have UAC turned off a lot of places and I can't remember if I've specifically tested it when UAC was fully turned on.