PowerShell to the rescue to control Exchange 2013 logging

I’m sure that you, like me, pay close attention to Microsoft’s stated requirements to install Exchange 2013.  It is, after all, gripping reading of the kind that is guaranteed to lull the reader into a deep sleep within 22 nanoseconds. In short, it’s material that you try and read just once as you prepare to install Exchange. Or maybe not, if you assume that installing Exchange 2013 must be pretty similar to previous versions and therefore commit one of the cardinal sins of technologists.

The requirements state that you need to have at least 30GB free space on the disk on which you want to install Exchange 2013. The Exchange setup program is picky on this point too and won’t allow you to proceed if it feels that too little disk is being placed at its disposal. We can therefore conclude that all of the space is needed for important functions, such as logging every step that the setup program takes as it installs Exchange. You’ll be glad that this happens if a problem is encountered during setup.

But after a successful setup, when a brand spanking-new version of Exchange has been laid down on a server, you’ll find that lots of disk space can be recovered through a few simple clean-up steps. I commonly delete the contents of the ExchangeSetupLogs folder, saving just ExchangeSetup.log as a record of the installatio. In passing, I should note that from CU5 onward, Exchange is better at cleaning up as it removes the temporary scripts used by the installation. I then move on to the \Logging\Lodctr_backups folder and remove all the files there. These files are used to update Performance Monitor counters and they are absolutely unrequired once used. I can’t quite work out why the Setup program can’t clean these files up following a successful installation – the problem persists to this day, even with Exchange 2013 CU8. The same behaviour exists for Exchange 2010.

Exchange 2013 folder size

Exchange 2013 folder size

Following some spring cleaning, the size of the complete directory tree created and populated for an Exchange 2013 installation will be anything from 8 GB to 16 GB, depending on the logs that are around. The screen shot shown above is from an Exchange 2013 server after the CU8 update and after some clean-up operations were performed.

But I bet it’s not when you go and check your servers because Exchange 2013 is extraordinarily prolific when it comes to logging. Everything possible that can be logged will be logged from incoming SMTP messages to OAB generation to the work done by mailbox assistants in a set of 133 folders under the \Logging root. There used to be (only) 110 folders (CU1), so the amount of logging done on an Exchange 2013 is growing.

I have written about this topic in the past and pointed out that many of the logs generated by Exchange 2013 arise from the activities of Managed Availability and diagnostics logging. Some administrators report that it is common to find that over 25GB of log files build up relatively quickly, which means that the 30GB required for Exchange 2013 isn’t used for things like program files and the like. The vast majority is consumed by logs.

I like logs as much as the average person does. Or perhaps even a little more. But keeping quite so much information in quite so much detail seems a tad excessive, especially if you run Exchange 2013 on relatively small servers.

One obvious answer is to use larger disks for Exchange servers. After all, no self-respecting administrator would be seen dead if their servers had anything less than 1 TB available for Exchange. But the unwary amongst us and those who never go looking into the bowels of logging might just be surprised that Exchange absorbs quite so much disk space for log files.

What’s worse is that Exchange offers no method to control the log files. There’s no handy PowerShell cmdlet to clean things up like:

New-LogCleanUpOperation –TerminateUpTo 1-Oct-2014 –DontAskMeAnyIrritatingQuestions –TargetServer ExServer1

It would be even better if the Exchange Administration Center (EAC) included an option to allow the generation and clean-up of log files to be controlled on all servers across the organization. In other words, define a policy that Exchange then applies to all servers.

We can but wait for Microsoft to recognize that the issue exists and does something about it. They probably don’t care too much that the logs accumulate over time on the 100,000 servers that run inside Exchange Online because these servers are periodically taken offline, stripped to bare metal, and reinstalled with the latest versions of Windows and Exchange.

Rebuilding servers is certainly one way to remove logs. Those who seek a less dramatic solution can write some PowerShell to scan the \Logging folder tree and remove old logs. Or take advantage of the work that MVP Brian Reid has done and use his script. Seems like a good idea!

Follow Tony @12Knocksinna

About Tony Redmond

Lead author for the Office 365 for IT Pros eBook and writer about all aspects of the Office 365 ecosystem.
This entry was posted in Exchange, Exchange 2013 and tagged , , , , , , , . Bookmark the permalink.

9 Responses to PowerShell to the rescue to control Exchange 2013 logging

  1. Jack P says:

    Using forfiles.exe you can do the same in 2 lines to clean up iis and Exchange log files. It is overkill using Powershell for this 🙂

  2. Todd Nelson says:

    I’ve used Brian’s script many times before; especially for targeting multiple Exchange servers at once. It’s great.

    However, I use the ‘Get-ChildItem’ command in a one-liner. I also use it in a scheduled task as I documented it here … https://oddytee.wordpress.com/2014/09/11/references-remove-exchange-2013-diagnostic-log-files/

    • Todd Nelson says:

      It is those blasted “ExchangeDiagnosticsDailyPerformanceLog_MMDDHHMM.blg” files. Even on a server that isn’t doing much I’ve seen them over 750MB at minimum. And they are created everyday.

  3. I would prefer to have some server/org wide settings in additon to the log level configuration.

    -MaxAge 30days
    -CentralLogStore \\MYUNCPATH\ExchangeServerLogs

    Just integrate proper log maintenance into the Exchange Core libraries.

  4. Rob Adams says:

    Tony, please consider doing a comparison of building a resource mailbox (room) in exchange 2010 and Exchange 2013. We are in the process doing a POC before a major migration and have noticed that a very large number of options that were available in the Exchange 2010 management tools do not seem to be available in 2013. Examples are, delete attachments, delete comments, delete subject, remove the private flag on an accepted meeting and delete non-calendar items. These were widely used options. The Resource in-policy requests and Resource out of Policy requests also seem to be missing. What happens where we migrate 2010 resource mailboxes to exchange 2013 or office 365 servers? How do we manages these migrated mailboxes that took advantage of the features?

  5. Pingback: Weekly IT Newsletter – March 23-27, 2015 | Just a Lync Guy

  6. Pingback: NeWay Technologies – Weekly Newsletter #140 – March 27, 2015 | NeWay

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.