Compress and Remove Log Files (IIS and others)

Archive Log Files: Manually specify any folder(s) or automatically parse IIS log folders, group by day/month and archive them with 7-Zip. Verify the archives and delete the original log files. Compressed archive will be about 4.5% (or less) of the size of the original log files.

4.8 Star
Add to favorites
E-mail Twitter Digg Facebook
Sign in to ask a question

  • Compress-Archive
    3 Posts | Last post May 17, 2018
    • Hi,
      A big thank you for creating this very useful and comprehensive script.
      For the environment I am working for we are not able/allowed to deploy 7zip.
      So I have added the following snippets to your script in order to remove the requirements for 7zip.
      Compression Method:
      elseif ($CompressionMethod -eq "Compress-Archive") { 
          $ArchiveExtension = ".zip" 
      Archiving the files:
      elseif ($CompressionMethod -eq "Compress-Archive") { 
                     Get-Content $ArchiveList | Compress-Archive -DestinationPath $ArchiveFileName 
      I'm not very experienced with PS but I managed to write the snippets above :)
    • Thomaspriv,
      Could you please provide the script after the changing the compression.
    • @Sjaina,
      Here you go:
      Please keep in mind that I am not experienced with PS and I probably broke some parts of the script.
      And ofcourse all credits go to Bernie.
  • Default compression Instead of 7zip
    1 Posts | Last post May 15, 2018
    • Script is really good with error handling. Could you please provide the same with windows default compression.
  • 7-zip or widows compress
    1 Posts | Last post May 14, 2018
    • Thanks a lot for the amazing script!
      just a quick question.
      Is this work only with 7-zip or will it work with Windows default compress system?
  • Idea for weekly archive
    1 Posts | Last post April 11, 2018
    • Hi, 
      I like your script the best out of all the ones I've tried and found.  I see your 'to do' about weekly archives and that's what I'd like to achieve as well.  My idea is to use the 'daily' archive option, but have a 2nd routine that archives (7z store option) the past 7 days of 7z files into a single archive. That could also be configurable to any number of days if desired. For me, that's a good compromise vs. trying to figure out how approach your current method?  I'm going to try to implement this myself and reply back if I'm able to.
      Not sure if this is helpful, but I found this on researching a 'weekly' option like you're performing the monthly now. I was looking for a function to determine weeks.
  • Renaming of Archived Files
    2 Posts | Last post March 28, 2018
    • Hi Bernie
      I am executing your script to compress files for a number of applications we have. So far so good, I am managing to work fine.
      One question, I need to rename the archive file to the same name of the current log file. to give you an example, if i have an application which is creating a log file named ipsearch.log i would like the archive file to be named the same. Can this be achieved through the following?
      #$TargetTypeName = "Archived_Logs_" 
    • Hi Mark,
      Sorry for the delay - I again received no email from MS about this post.
      Currently, line 431 of the script is where the final $ArchiveFileName is defined before it's used for creating the archive. If you only have one static file that is being archived you could manually enter its name there. But if you're going through multiple directories then you'd have to change the logic of how the script builds a list of files to archive and feeds that into the archiving command. That would require a lot of rewrite that you could certainly tackle, but at that point you may as well write your own script to do so. :)
  • Script is not removing *.log.* files
    2 Posts | Last post November 20, 2017
    • Hi Bernie, 
      we are using this script (20150713) and it is working fine in our environment, but it is compressing the log files in a compressed folder but not deleting *.Log.* files.
      we have enabled the false mode only ($TestMode = $false) and the script has permission to delete the file.
      This script has any rule like if the disk space is more than 70% the script won't perform (like deleting the files)
      could you please help on this.
    • Hi Anilkumar,
      I apologize for the delayed reply - I didn't get an email notification when your question was posted. 
      That's a somewhat older version of the script. Is there any chance you could update to the latest version? As a bonus if you do (and grab a new version of 7-Zip so it'll work) you'll get a better compression ratio. 
      Here are a few other things to check.
      - Make sure the account being used to run the script has permission to delete the log files and that UAC isn't causing any issues.
      - Find the section where it tries to delete the files, it should look like this and be down in the range of lines 400-500 or so. Add -verbose after Remove-Item and run the script from the command line so you can see what happens. 
      } else { 
      	# Delete the original files. 
      	$ | Remove-Item 
      If you're still stuck, drop me an email and we can continue troubleshooting from there. If you do email me, it'd be helpful to see a copy of the script you're running - just strip any sensitive info from it before sending.
  • Check for create instead of modified date
    3 Posts | Last post April 28, 2017
    • Hi Bernie,
      The script is very useful for us but we would like to archive the script of yesterday aswell.
      We only achieved it to archive the log from 2 days ago or archive the log of yesterday and an empty logfile of today within the same zip file.
      Is it possible to change this part:
              dir $TargetArchiveFolder | where {  
                  !$_.PSIsContainer -and $_.extension -eq $FileExtension -and $ArchiveGroupingString -f $_.LastWriteTime -le $ArchiveDate  
              } | group {  
                  $ArchiveGroupingString -f $_.LastWriteTime
              } | foreach { 
                  $FilesFound = $true
      So that it takes the create date instead of the write time?
      Or if it needs to be changed elsewhere where would that be?
      Thanks and kind regards,
    • Hi Raoul,
      My apologies - I never received an email notification for your post.
      The script intentionally ignores 2 days because many log files remain open for writing for a day or two, and admins may need quick access to the most recent day or two for troubleshooting purposes without having to open an archive. 
      A quick way to change that 2 day gap is (at line 306 of the current version of the script) in the Switch($ArchiveGrouping) section for "day"
      $ArchiveDate = $CurrentDate.AddDays(-2).ToString("yyyyMMdd")
      You can change that -2 to -1 or get rid of it entirely.
      $ArchiveDate = $CurrentDate.ToString("yyyyMMdd")
      To your other point, yes, you could swap out .LastWriteTime with .CreationTime if that produces your desired behavior.
    • Hello Bernie
      Thank you very much for your answer.
      We use external Software to analyse our Logs so we don't need them in the Log Directory after the new File was created.
      The change of the CurrentDate(-1) still kept yesterdays file and getting rid of it entirely resulted in an Archive with yesterdays File and a small part of todays Log file.
      The Script is now working fine this far with the .CreationTime change.
      Kind Regards
  • Script not removing *.Log files
    3 Posts | Last post April 14, 2017
    • Hi Bernie, the script is working fine in our environment. i was configured manual method.
      post arching the script is not deleting Source *.Log files which are just archived.
      this need to be removed.
      could you kindly help on this.
    • Hi Nizamuddin,
      By default the script is set to run in "test mode" so it doesn't delete anything while you're working on getting it configured to your liking. It sounds to me like "test mode" is still enabled. In the current version of the script, at line 67, you should see the following.
      $TestMode = $true
      Change that to...
      $TestMode = $false
      If that is set to $false and the log files still aren't deleting, then please double check the permissions on the log file location(s) to make sure that the account that's running the script has permission to delete those files.
      Let me know how that goes, thanks!
    • Thank you very much for rapid response and effective advice, it's worked... Cheers...
  • Two issues on server 2008 32bit
    3 Posts | Last post April 07, 2017
    • I got the script running great on my server 2012, however, when I tried it on my 2008 32 bit server, I ran into an issue when running the "IIS" option - it fails saying  The requested target archive folder of \W3SVC does not exist.
      The folders should be F:\IIS_Logs\W3SVCx
      Next I tried the ManualRecurse option on my F:\IIS_Logs folder which has numerous subfolders with logs.   In this case it simply fails saying:  Info: No files found to archive in F:\logs_iis\  -which is true, however, shouldn't be looking to recurse the folders in that location?
    • Sorry - typo - the folder should (in all above instances) be F:\logs_iis\
    • Hi,
      It sounds like it could be a permissions issue... Can you try running the script under an elevated PowerShell prompt, as well as double checking the permissions on those folders vs. the user account being used to run the script? 
      If all of that checks out fine it'd be helpful if you could provide me a list of your IIS sites, their respective log folder settings, and the paths to those respective sites/logs. If you'd prefer to email me (found in the script header) that info for further troubleshooting instead of posting it publicly please feel free.
  • IIS 10
    4 Posts | Last post April 07, 2017
    • Bernie,
      Thanks for this script.  A small update to allow it to work properly with IIS 10:
      if ($iisVersion.MinorVersion -ge 5 -or $iisVersion.MajorVersion -eq 8) { 
      if ($iisVersion.MinorVersion -ge 5 -or $iisVersion.MajorVersion -ge 8) { 
    • Hi,
      Thanks for catching that! I haven't had a chance to test with IIS 10 yet. Have you successfully run the script against IIS 10 after making that change?
    • Yes - It works great!
    • Great to hear, thanks for following up!
1 - 10 of 58 Items