Solving the Exchange C: Drive\ Resource Mystery

Morning,

Today I wanted to write up about how I reclaimed approximately 25% of my C drive in one deletion. This may upset some security experts so I can assure you I’ve got archived copies of the data I deleted!

Now you may have had Exchange in your environment for a while, you may even have had a DAG in place. You followed your best practise guidance of not installing the application on the C drive yet somehow your C drive is growing at a much faster pace than any other servers.  Sound familiar? Read on!

The Answer is IIS Logs!

By default behaviour, the IIS websites that Exchange needs for its ever so important ECP and OWA mechanisms are installed on the C drive. By itself not necessarily a problem, but the fact that since IIS 7 the default behaviour for all websites is to log indefinitely, you could have a major problem on your hands in the long-term. Now you have three realistic options so if you have a gut instinct as to what you want to do then proceed with the one you want. I’d recommend reading them all before making a decision however.

Option 1: Migrating the logging destination

Security and traceability the most important part of your day-to-day? Migrate where the logs sit to a disk you can manually monitor and migrate, saves any C drive full related outages which’d be a lot more painful than your log file not being able to be saved and you don’t compromise on your security standpoint!

It’s as simple as opening IIS Manager -> Choosing your Server -> Choose Logging -> Log File: Directory. Change %SystemDrive% to the disk you wish and the rest of the expected file path will stay intact. Apply and restart the IIS service.

Option 2: Automatic Log Deletion

Small business with limited storage? Read on! A lot of SMB’s will focus on just keeping a “reasonable window” of log file history to keep storage down. To do so create a batch file and try utilising code like this:

forfiles /p "Folder of Logfiles" /s /m *.* /c "cmd /c Del @path" /d -30

This code just requires typing in your directory and changing the /d -<number> to whichever you’d like, I’ve set this one to 30 as a default. I’ve left the folder path empty as you may even want to use this alongside option 1.

Option 3: Disabling the Logs Entirely

This one is easy enough to do but unless you’re certain of your environment and the trust in place you may find you’re kicking yourself one day when you have no access records. I recommend this only when you’re dealing with an internal only Exchange OWA/ECP as your potential for damage/loss is far more limited.

We follow the path mentioned above (IIS Manager -> Choosing your Server -> Choose Logging) but instead of changing a parameter we’ll navigate to the right hand side of the screen, you should see an actions pane, choose disable. Restart your IIS service and that’s it. No more logs!

Final Thoughts:

I hope this has helped you reclaim a lot of unnecessary disk space consumption like it did for me. I hope it’s also helped you think of different ways of tackling a problem over a long term solution instead of an initial disable/manual delete.

By micoolpaul

Technical Consultant at Nexus Open Systems. Focusing on Veeam, VMware & Microsoft Productivity and Infrastructure stacks.

Leave a comment

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 )

Google photo

You are commenting using your Google 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