Huge Logs
Sometimes the Exchange server runs out of space. As it happens often, the transaction log files use up all the free space, causing the transport service to stop as there is no more room to write messages to.
What are Exchange transaction logs?
First, we need to talk about transaction log files. What are they, do we need them, how come they grow so large? As we know, Exchange stores all contents, like contacts, incoming and outgoing messages in one or two databases. See a proper example: we examine the only Exchange server of Always Hot Café. The server has a single database. Databases are always stored in a single file with an .edb extension. In our case it is located at c:\ExchangeDatabases\DB01\db\DB01.edb.
Now there is an important thing that the creators of Exchange took seriously, which is called resiliency. We now that there are no servers in the world that are absolutely reliable, they fail from time to time, because of hardware issues, untested updates or simply power outages. What happens if a server loses power while heavily reading-writing to a database? Corruption will happen, which sometimes can be so bad, that the engineer decides to restore the database from an earlier backup. But if he restores a database from a backup that might be a week old, the company would lose a week worth of email messages, appointment entries, etc. This is where log files com into play. Log files are created of all "transactions", any changes that happens to the database. That means all incoming or outgoing messages are written in the database of course, but the same time chunks of log files are created to store all of these changes. These files are kept in the "log" folder. The point is simple: if there is a failure so bad the engineer needs to restore an old version of the database, by having these change logs available, the server will be able to "play back" those changes to the live database, this way no data is lost! Every time a full backup of the server is made, the Exchange server happily truncates, removes these logs as they are not needed anymore. Form that point it starts to create the logs again.
The huge list of files from the logs folder has cleared up
Getting rid of the log files
1. Enable Circular logging
Exchange has a function called Circular logging. If you decide that logs are not important because you have a bulletproof server or backups available, you can enable circular logging on the database, that will turn off the transaction logs, older logs will be deleted straight and new logs won't use up huge spaces. We use PowerShell to enable circular logging. Remember, the database needs to be re-mounted after changing the circular log settings (either disabling or enabling them).
PS C:\> get-mailboxdatabase DB01 | fl *path*
EdbFilePath : C:\ExchangeDatabases\DB01\db\DB01.edb
LogFolderPath : C:\ExchangeDatabases\DB01\logs
TemporaryDataFolderPath :
MetaCacheDatabaseVolumesRootFolderPath : C:\ExchangeMCDBVolumes
MetaCacheDatabaseRootFolderPath : C:\ExchangeMetaCacheDbs
MetaCacheDatabaseMountpointFolderPath : C:\ExchangeMetaCacheDbs\DB01
MetaCacheDatabaseFolderPath : C:\ExchangeMetaCacheDbs\DB01\DB01.mcdb
MetaCacheDatabaseFilePath : C:\ExchangeMetaCacheDbs\DB01\DB01.mcdb\DB01-mcdb.edb
PS C:\> Get-MailboxDatabase DB01 | select circ*
CircularLoggingEnabled
----------------------
False
PS C:\> Set-MailboxDatabase DB01 -CircularLoggingEnabled:$true
WARNING: Circular logging parameter change will not be applied on this database before it is remounted. Dismount and
remount database "DB01" in order to apply this parameter change.
PS C:\> Dismount-Database DB01 -Confirm:$false
PS C:\> Mount-Database DB01
2. VSS Backup trick
If we don't want to enable circular logging, but want to free up space there is another way to make the server to get rid of the log files. As mentioned earlier, if the server thinks that a full backup of the machine is taken, the logs are automatically truncated. Shadow copies is a built-in function in Windows, probably you have used it a thousand times when restoring and earlier version of a file or directory (right-click on file, select properties and "Previous versions"). We use this functionality to create a snapshot of the drive where Exchange is installed. That will trigger log truncation. From an elevated command prompt we issue the following commands:
PS C:\> diskshadow
Microsoft DiskShadow version 1.0
Copyright (C) 2013 Microsoft Corporation
On computer: MAIL, 22/04/2020 16:30:08
DISKSHADOW> add volume c:
DISKSHADOW> begin backup
DISKSHADOW> create
Alias VSS_SHADOW_1 for shadow ID {7a1ed4b2-518b-4ddf-9b5b-774cd15de41f} set as environment variable.
Alias VSS_SHADOW_SET for shadow set ID {122a1b8b-0830-4ebe-98f5-c29725341cd7} set as environment variable.
Querying all shadow copies with the shadow copy set ID {122a1b8b-0830-4ebe-98f5-c29725341cd7}
* Shadow copy ID = {7a1ed4b2-518b-4ddf-9b5b-774cd15de41f} %VSS_SHADOW_1%
- Shadow copy set: {122a1b8b-0830-4ebe-98f5-c29725341cd7} %VSS_SHADOW_SET%
- Original count of shadow copies = 1
- Original volume name: \\?\Volume{0020b24b-0000-0000-0000-602200000000}\ [C:\]
- Creation time: 22/04/2020 16:30:33
- Shadow copy device name: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1
- Originating machine: MAIL.AlwaysHotCafe.com
- Service machine: MAIL.AlwaysHotCafe.com
- Not exposed
- Provider ID: {b5946137-7b9f-4925-af80-51abd60b20d5}
- Attributes: Auto_Release Differential
Number of shadow copies listed: 1
DISKSHADOW> end backup
DISKSHADOW> exit
PS C:\>
3. Manually delete log files
The worst case, when there is absolutely no chance of truncating the log files the other two ways, we can manually delete them, possibly leaving the newest 10-15 on the server. Proceed with caution!
Comments