Define "unused packages" a little better please.
Do you mean as in - "packages that exist, but are not used in scheduled tasks at the moment" ? How are your criteria based ?
Hi, I want to clean up packages that haven't been deployed for a period of time.
OK - now *THAT* is tricky, based on your description.
Finding packages that aren't parts of scheduled tasks - not too hard.
But most policies (and all tasks *ARE* policies, if you're on 9.6 or newer) are just "floating, waiting to trigger".
But that depends on how you target your policies. If you target by (say) queries, then all it takes is for a device to be re-imaged and that policy to apply again (if you target users).
So ... you're going to have to go through this in a bit more structured a manner and examine your policies. How they target, etc.
Reading between the lines - based on your questions - it seems as if you're not necessarily sure how all of your tasks work and ... that seems a little risky to just "blind-guess" against.
Does that make sense?
Hi Thanks for your response, it was a bit more around finding old application packages like say Office 2003, I wanted to run a report where we could see what application packages haven't been deployed for a while and then delete them out of LANDesk and off our data storage.
Otherwise we will have old applications lingering around forever...
OK - maybe explaining it with a picture will help.
Point 1 - We don't track "the age of a package" itself.
Point 2 - What you CAN track, is "the relative age of a scheduled task". See the picture below (this is from a 2016.3 Core):
Notice that there's a "Last Update" (as in - "from the client") field associated to the task. The task COULD be a software distribution package you care about, or it could be just a "run some batch file" that someone's forgotten about 5 years ago.
HOWEVER ... *because* all of this is down to policies, we don't know how you target them. Could be static devices, could be queries. And if certain conditions are met, they will be redeployed (so if you target against LDAP users, for instance, and "employee BOB" is targeted & gets a new computer, all of his policies - and thus packages - will be applied to that new computer).
Does that make a little sense?
So you need to know (and either make an informed decision or build up information) on what your scheduled task structure looks like. How it's targeted - whether it's likely to re-target someone / a device. Whether you still need / do not need it.
In order to get rid of packages, you need to first identify whether you can delete the scheduled tasks that rely on them FIRST. And this can be greatly hindered (or helped) based on how structured (or messy) your standard for naming scheduled tasks is.
Does this make it clearer why I'm telling you to focus on scheduled tasks first? It's the TASKS that make use of packages ... we don't keep track of package "age" ... we keep track of schedled tasks & status updates from devices.
Hello thanks for your help here. I'm not sure how we are going to address this one. But I wil try through scheduled tasks as you have advised.
If you know for certain that "package X shouldn't be in much use these days", I can try to come up with a few lines of SQL that'll show you "which task(s) make(s) use of Package X" -- that shouldn't be too hard. Not fun checking 2,000+ tasks by hand if it comes down to it.
But yeah - this is the sort of reason why a sensible "filing" / task naming structure can be really helpful .