We have been noticing on some of our endpoints that there are large number of temp files that stay in the c:\windows\temp directory after the patch cycle.
Most of our servers are set to perform the online scan, then we patch weekly during the weekend and the devices have a set reboot time in the reboot options of the patch module.
I want to know if this is an issue with how we are patching or if I need to be running a cleanup procedure after every patch cycle?
Today we have about 22gb of temp files on a server and when I review the patch status, the machine has no pending updates or reboot action required. Just trying to understand as some machines tend to generate low disc space alert and I would rather be proactive vs reactive .
I've had the same issue myself. It's gotten so bad that I wrote a procedure to clear the CAB, tmp and lpksetup log files. So while I can't give you an answer on why the CAB files are there I do have a solution for cleanup.
executeShellCommand("forfiles /p "C:\windows\temp" /m cab* /D -7 /C "cmd /c del @path"", "Execute as System in 64-bit shell", "All Operating System". "Continue on Fail")
I have 2 additional lines substituting GL*.tmp and lpksetup*.log for cab* which clears anything over 7 days old. I have the 7 day leeway because I was still investigating what those files were from.
There was a bug earlier in the year that caused this related to the CBS logs, essentially the makecab.exe process used to make those cab files can't handle any log over 2GB and there isn't a check for it so it keeps retrying.
The fix is simply to file the log file its getting stuck in under C:\windows\Logs\CBS and delete it - just sort by size and remove anything larger then 2GB.
You may have to stop the Windows Modules Installer service if its in active use (but typically the ones that size are historical ones by the time they become a problem).
There are a lot of threads from around May or so when it started to come up if you know what to search for e.g. answers.microsoft.com/.../0e534920-f138-492c-a33e-674ba2cb0fe5
Our daily maintenance tools related to disk cleanup handle this automatically - any content in several specific folders plus all common Temp locations get's cleaned daily if it exceeds a specific age (5 days by default). Been doing the temp cleanups with this tool for more than 20 years (Pre-Kaseya), and added the CBS folder about 2 years ago.
This is excellent news. Now I can re-structure my procedure to just do a del C:\Windows\Temp\cab* and write instructions for the help desk to use.
Until this bug is resolved, possibly in the new build coming out this fall/next year. Would it be recommended to just run the following procedure on a weekly schedule for all systems to avoid further disk space issues? just wondering if these two lines would delete the right content and not affect other items.
and also run executeShellCommand("forfiles /p "C:\windows\Logs\CBS" /m log* /D -7 /C "cmd /c del @path"", "Execute as System in 64-bit shell", "All Operating System". "Continue on Fail")
The first line will delete any of the cab_####_# files that are older than 7 days. I actually changed mine to just del C:\windows\temp\cab* so any of those cab files in the folder got deleted.
I'm not sure about the second line though. I went through a few machines yesterday and the offending log files in the CBS folder had a specific structure, CbsPersist_YYYYMMDD######.log. I'm not sure if the largest log file will be older than 7 days each time.
(edit: found the name structure of the CBS log file)
I guess to Murray's point, if the file size in the CBS log file is larger than 2gb then I would want to delete it as I did find one that was above that size with a server we had problems with.
Yup, on the machine I just looked at to get the CBS log file name I found a 10GB log file and deleted it. I want to say I found a larger one on a different machine yesterday but I can't recall the file size.
The point about the CBS logs is that once they hit 2GB they are supposed to be compressed and archived and a new log started. Occasionally, this doesn't happen and the log file grows indefinitely.
I will take Trevor's approach and clean of all of the cab files as a post patch procedure and then run a report for the cbs log files and if any exceed 2gb then I can take action as I have reviewed other servers and I don't find any specific trend at the moment. I opened a case with support but they don't believe that this is a bug or issue
My co-worker is working on a PowerShell script that will look in the C:\Windows\Logs\CBS folder and look for the log files that are over 1GB and delete them. So once he's done with that my plan is to add that to my procedure that clears the log files from C:\Windows\Temp and then schedule it to run either weekly or bi-weekly on our workstations.
Ok after all of this time I've got a working procedure and PowerShell script that works. The PowerShell script is set to run from C:\Temp (Lines 1, 2 & 7). The PowerShell script will delete any files larger than 2GB from C:\Windows\Logs\CBS and deletes all of the cab_ files in C:\Windows\Temp. Then it deletes the GL*.tmp, lpksetup*.log and MSI*.log files older than 7 days in C:\Windows\Temp. Then the procedure deletes the PowerShell script from the directory.