Running an Exchange Server requires that you build it according to what Microsoft requires. Why you may ask? Many companies or admins want to take the easy way out and give Exchange Servers as little space as possible but in fact, Exchange is a busy program. With the newer versions of Exchange, they write a whole lot of log files, including performance logs, IIS logs, and many other logs. The other big source of Exchange Server log files are the transport logs and its database.
Admins tend to build servers as we did in the old days where you would build a server and allocate 80GB. Problem is once the operating system is installed and you are left with maybe 65GB of free space you then need to install Exchange and that number reduces your free space even further. Before you know it, the C: drive is full.
How did this happen? First, you need to take into account that not only does Exchange write a whole lot of logs but you also have your pagefile to take into consideration. Once it hits that threshold, Exchange then hits back pressure and mail flow stops working and stores begin to dismount. The newer versions of Exchange from 2013 onward write a lot of log files. You can tune it but if you have not properly spec’d your server, you are going to do cleanups every day and this is going to become a tedious task.
Exchange 2013 introduced the performance logs that write 1GB of data a day. Times that by 7, and its 7GB of space per week you have utilized without even doing anything.
The next thing is IIS logs. These log files grow to big sizes but if you have a problematic ActiveSync device or an issue, the growth rate is going to be even higher and you going to use quite a bit of space here. In the logging directory, Exchange has many places it writes logs to. Let’s say that you have allocated a 600GB drive to Exchange and you moved your transport logs and queues to another disk. If something happens with the underlying storage, Exchange will fill up that 600GB drive in a day as it writes log files because it cannot get to the drive. The transport services will start and stop and that will generate event logs even though those are overwritten when it gets to the set threshold.
Other things can fill up the space on the drive, for example admins using it as a storage facility to keep installs or restores that they never clean it out or you have a corrupt AV product that writes big log files to the Temp directory, or the Temp directory silently fills up and is never monitored or cleaned up on a regular basis.
The biggest problem with Exchange Server log files growth comes when admins have the attitude of “I will extend it later,” but the SAN space gets allocated to newer projects or they are physical servers with not enough space and it cannot be extended. When it comes to Exchange, you need to plan it properly. From CPU to memory and storage. If you are procuring new hardware dedicated for Exchange if it is physical or if you are building a virtual machine on your Hyper-V/VMware environment, ensure that you ask for what you need.
Remember, oversubscribing can also become an issue. You may think, “Oh, I will just give Exchange this and that,” but at the end of the day, you also end up with other application issues as overallocation of space for Exchange has resulted in issues where a SQL Server cannot be extended because of space limits.
At the end of the day, use the Microsoft Sizing Calculator and build your Exchange Server as recommended. Move your pagefile to a new drive, move the transport database and its logs to a separate drive so you don’t end up filling the C: drive especially where the transport database grows out of proportion.
You also need to move your Exchange database off the C: drive to its own drive on the SAN. The default databases that comes with Exchange will be in the install directory of Exchange on your server.
The final piece of this Exchange Server log files growth puzzle that I would like to touch on is backups. Backups are an essential part of Exchange. Yes, it requires space to back up the Exchange database or databases to. Again, the planning needs to be done to cater for this.
I have seen many customers throw backups out the window as they don’t have the space to back up a 2TB Exchange database or have the attitude, “Nothing bad will happen to us.” Going back to the point where it is essential is that it truncates the log files. If the log files don’t truncate, you end up filling up the drive, and if you didn’t create a new database and are using the default one, the C: drive will grow until it can’t grow anymore.
This will result in back pressure alerts and events that will stop mail flow and dismount the exchange database due to inadequate storage.
Good luck with your planning.
Featured image: Shutterstock
In this second article in our series, we will work on the Ansible Automation Engine…
Microsoft Build 2020 included several announcements aimed at developers and the IT community. Here are…
Using Azure Active Directory Identity Protection will boost your security. This step-by-step guide shows you…
COVID-19 is not going away anytime soon, and as Microsoft researchers have discovered, neither are…