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

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