« Posts under IIS

Exchange: Handling Old Log and Other Files

In Exchange old logs can really build up fast. Not database transaction logs but rather temporary transport, client access, IIS, and other debug related crap that typically default to locations either on your system drive or Exchange install path. Of course, Powershell scripting can provide a decent solution for this problem.


More than any other version, Exchange 2013 seems to like logging information to disk. By default, much of what gets logged will not auto-rotate (or if it does, it happens infrequently) either so you end up with this slow ticking time-bomb in your environment.

I’ve been using a few one liners for a while now to pare down old logs and such from Exchange 2013 servers. In a pinch this still works just fine:

The down side to this quick approach is that you have to run this directly on each server and there is no real reporting on how much space you are saving. It also requires knowing where some of the logs are ahead of time (c:\inetpub). Finally, this only gets a small subset of the logs most likely to balloon out of control.

In any case it is all very manual and is just a quick hack. So I finally decided to put an official script together instead. And, as I tend to do with scripts, I probably over-engineered the solution. But it works for me and may be valuable to you even if you are not explicitly using it for Exchange.

Interesting Script Notes

One of the issues with existing scripts for cleaning out exchange logs is that they are based around the files being located in the same locations on every server. I get around this with some psremoting (invoke-command) to gather web logging locations and exchange install paths.

Note: Enable remoting with the following in a cmd prompt:

winrm quickconfig

Since I’m already using psremoting to get log file locations I also use it again for some of the folder size reporting to get some performance boosts. (Remotely enumerating several hundred files can take a very long time in powershell but you can get around this with Scripting.FileSystemObject run locally on a system). This only makes sense if you are looking for entire folder size information. If you are filtering folders by file type or date for utilization there is no real choice but to use builtin powershell looping.

Here is the function I put together for getting the folder size with all of these factors. I added in some logic at the very beginning to determine if the path is local or remote as well.

I’ve wrapped up a number of additional functions with this folder size function in a single script with some predefined scenarios to make the script easier to use. The scenarios included are:

RetrieveValidFolders – Gather a list of valid Exchange logging and temp folders which you can use to pipe into other functions to perform custom actions.

ReportOldLogSize – Gather a list of valid Exchange logging and temp folders and also enumerate their total size as well as the size of all the old logs that exist before the specified number of days. This includes message tracking logs.

DeleteOldLogs – Attempt to delete all logs which are older than the number of days specified. This does NOT include message tracking logs.

DeleteOldLogsTestRun – Same as DeleteOldLogs but without actually deleting anything (adds –WhatIf to all Remove-Item commands). This does NOT include message tracking logs.

These scenarios work in concert with the available parameters to give you more control of which servers will be targeted and how many days worth of logs you want to keep.

DaysToKeep – The number of days of log files you wish to retain.

ServerFilter – Target specific Exchange 2013 servers. By default all (*) servers in the environment are targeted.

FileTypes – The types of old files to report upon or delete. By default this is *.log and *.blg. You may want to manually set this to * instead to force psremoting and fast directory size enumeration.

It should be noted that I’m not even trying to rotate or save the old files with this script. This is was written to report upon and optionally delete old logs and other temporary files related to Exchange 2013. Obviously take care with what you delete in your own environment.

The default file types which will be reported upon or cleaned up are *.log and *.blg (daily performance counter files). Optionally you may want to include *.bak to get some of the perfmon counter load backup files as well.


Here is a report of logs older than 14 days. Note that the message tracking logs are included here but are not part of the actual deletion scenarios unless you make manual modifications (add in your own scenario).


Here is a more complicated example which targets one specific server. The following lines will gather only total folder size information via psremoting (thus speeding up processing time) first. We then delete any *.log, *.blg, and *.bak files older than 14 days. Finally we generate a report on the folders previous vs. its current size. Again notice that I don’t futz with message tracking at all. But since it is included in the report aspect of this script the folder for message tracking actually goes up in size!



This should be a pretty easy script to schedule via task scheduler if you so desired. To download the script in its entirety visit the technet gallery.

Exchange – The State Of External Client Access


Most within the messaging and collaboration industry are hyped up about the next wave of Microsoft collaboration and messaging products which are soon to be released. Among these products is Exchange 2013 RTM. This type of release typically precedes yet another wave of architecture upgrades across the corporate landscape. Some of these (beta testers) will be will undoubtedly upgrade to Exchange 2013.

Other corporations will start to feel the burn to upgrade as well. These will be organizations which realize that their Exchange 2003/2007 infrastructure is nearing a decade old existence and cannot meet the demands of their ever growing mobile workforce. Realizing they are behind the curve, they may feel hastened to upgrade as well, possibly just to Exchange 2010. Regardless the reason in choosing to upgrade their messaging infrastructure, there are critical design decisions which need to be made in how clients access this infrastructure both internally and externally. This article focuses solely on the external access aspect of the infrastructure.

»Read More

Exchange: Automatically Generating Configuration Scripts

I’ve started a side project which is born from personally having to redo many aspects of an Exchange migration over and over again. Most of this, I believe, can be automated. Some aspects of this process include exchange server role prerequisite procedures, co-existence configuration, DAG/CAS configuration, and other general reminders and processes.

»Read More

Exchange 2010: Even More Migration Tips

It has been a while since I passed on some personal experiences when performing Exchange 2010 migrations. I thought it was about time to update my list to include some more of the lesser known aspects of an Exchange 2010 migration.

»Read More

Exchange 2010: Changing an invalid DNS suffixed server

I ran into an interesting Exchange 2010/2007 co-existence issue today. After a new Exchange 2010 (all-in-one) server was introduced into the environment traffic would only flow from the 2010 server to the 2007 hub/cas server and not the other way around. The mail queues stated the last error to be

»Read More

Exchange 2010: Client Access Role Configuration Report

Ok, so I woke up and was wide awake at 4am this morning. I took it as a sign to lose my mind for a while and get to hacking another script. The result is a client access setting report script which includes all internal and external paths along with their authentication settings. It needs some prettying up and a bit of love but it does exactly what I’ve wanted in Exchange 2010, gives me an overall view of all client access settings (specifically related to IIS). Enjoy.

Get-Exchange2010CASURL.ps1 for reporting enjoyment

Big-IP: Custom IIS SOAP Monitor

In working on a production issue with my company’s flagship SaaS product I worked with some of the brilliant F5 engineers to isolate one web server in the load balanced pool which was intermittently failing. The F5 engineer recommended a health monitor that does more than just poll for a static page. He suggested we implement some kind of soap call to make the application pool do some work and return a result (I guess in case the IIS application pool is misbehaving but not down). So I worked with one of our developers to do just that but ran into some caveats which required yet another custom health monitor.

»Read More


Get every new post delivered to your Inbox

Join other followers