Transaction Logs and Checkpoint Files

When creating a new storage group, if you’re not careful, you could end up putting your transaction logs in a different location than the checkpoint file. The installation wizard is a little vague on this topic, calling the locations, “log file path” and “system file path”. Transaction logs are written to the log file path, but the checkpoint file is written to the system file path.

Although using different locations for these paths performs just fine, the Exchange Best Practices Analyzer (ExBPA) flags it, since it could affect your ability to recover messages in the event of a drive failure.

Rectifying this situation is fairly simple - dismount the databases in the storage group, then use the Move-StorageGroupPath command to specify the same “system files” path as the “log files” path. Exchange will automatically move the checkpoint file to the new location for you, so all you have to do is re-mount the database and you’re done. Unless your mailbox server is a CCR cluster.

Since CCR clusters use separate storage for each node, Exchange won’t move the transaction logs or checkpoint files automatically. In a CCR environment, the Move-StorageGroupPath command only updates Active Directory with the new configuration, but YOU are responsible for moving the files to the new locations manually, on both nodes. So the process goes like this:

1. run Suspend-StorageGroupCopy to suspend the copying of transaction logs to the other node
2. run Dismount-Database to dismount the mailbox database in this storage group
3. run Move-StorageGroupPath to specify the new location for the system and/or log files
4. manually move the files to the locations specified in the previous command, on both nodes
5. run Mount-Database to mount the mailbox database
6. run Resume-StorageGroupCopy to resume the copying of transaction logs to the other node again

Repeat the above steps for each storage group, then run Get-StorageGroupCopyStatus to verify the status of the transaction log copy process. Depending on how long the copy process was suspended, you may have to run this several times until everything catches up and the SummaryCopyStatus is healthy for all storage groups.