I'd be rather careful with this.
I've had a couple of google searches about WINSXS over the years (got rather annoyed at how much disk space it was eating up), and by and large the concensus is "touch it only at your own risk". It can cause various issues with system restore points & similar things.
There are apparently a few other directories that are safer to delete -- but that's all "Windows own file management". That's got nothing to do with us per se (our download files land in a sub-directory of "C:\Program Files (x86)\LANDesk\LDClient\sdmcache\" and get deleted from there after a specified time (usually 7 days).
The WinSXS stuff ... that's Windows' own thing. You *CAN* (as in "are able to") do stuff with / about that, and remotely execute it with us, but be aware that by and large this seems to be mostly advised against.
Do a couple of google searches & you'll see various examples on Microsoft's Technet about it easily enough.
Thank you phoffmann for the prompt responce.
I have sdmcahe clean options on the download tab and i think that is working great.
As a part of Patch installation windows 2008 boxes are growing and we have planned diskcleanup manually on many boxes
I am just curious if we can run following steps from landesk.
1. Identify winsxs folder size from a Query.
2. identify if disk cleanup is installed from a landesk query
3. push script to run disk cleanup and restart server or schedule diskcleanup to task scheduler in the server.
Please let me know if you have any ideas to share for this,
You certainly can.
"There's at least 3 different ways of doing the exact same thing in EPM for most operations" is what I tend to say, and this is one of those.
So here's a few ideas:
- Create a CUSTOM VULNERABILITY to check on the size of your WINSXS folder & return the size of it in some standardised format (you may want to round it into GB's or so). That should be a powershells script of about 5 lines or so. That gives you more control if you want / don't want it to run on certain platforms, for instance.
- Or you could have (again) a script pick up the usage data locally & store it in the registry which you can then pick up as a custom data string & have it be part of inventory (makes it potentially easier for queries).
... as for pushing a script out to "go clean things up" - sure. That's just "you writing the script" & pushing it out. That's just "regular" a software distribution task as far as we're concerned ... (i'd be hesitant to use this as the "patching" part of a custom vulnerability - though it certainly would be possible - since this MIGHT become dangerous if people are tempted to use this in an AUTOFIX sort of way).
So - easy enough either which way.
Addendum - if you've not used custom vulnerabilities, here's something to get you started -- How To: Create a Custom Vulnerability Definition in Patch and Compliance Manager .
I've recently thrown together a quick powershell-based custom vulnerability to help some folks hunt down an issue in this thread (the thread is here - Inspect not working on Windows 7 machines - see page 3 for the code to be used as an example).
So you can see that you can use custom vulnerabilities for all manner of things .