If a backup is completing successfully, Exchange will flush all logs that have been committed to the database. So normally, all committed transaction logs will be flushed if:
1. All databases in the Storage Group are backed up
2. All databases in the Storage Group are mounted during the backup
The store determines what logs will be deleted by looking at the first log that has not yet been committed and deleting all log files previous to that. You can view the first uncommitted transaction log by running eseutil /mk on the checkpoint file.
After the backup completes, ESE Event ID 224 will be logged telling you what series of transaction logs will be deleted: If eseutil /mk E01.chk outputs E010000G then E0100005 - E010000F will be deleted. The purging process is sequential and will purge all log files in the series with one caveat - the purge process will stop if it goes to delete a log file that is missing. So in the above example, if log E010000A is missing, then only logs E0100005 - E0100009 will be deleted. In this scenario, after the next backup, Exchange will again try and purge all log files that have been committed. This time eseutil /mk E01.chk outputs E01000016 as the uncommitted log file and therefore E010000B - E0100015 will be purged.
If transaction logs are not purging, sooner or later you'll run out of disk space. If you have to create space in a hurry do not move the log files, compress them (in my lab I've seen 3 GB worth of log files compress to 1.5 GB). For recovery scenarios and for the purge process to complete successfully, do not move the transaction logs.
Transaction logging in Exchange server 2003:
http://www.microsoft.com/technet/prodtechnol/exchange/guides/UseE2k3RecStorGrps/d42ef860-170b-44fe-94c3-ec68e3b0e0ff.mspx
Using ESEUTIL to determine which transaction logs have been committed:
http://support.microsoft.com/kb/182961
How to remove Exchange server transaction logs:
http://support.microsoft.com/kb/240145
