If my Message Retention Policy is set to delete out anything older than 365 days, I know it will remove old information from the EDB file thereby making room for new messages but will it also delete out unwanted data from the STM file? In the end, is there any way aside from offline compression to keep the STM file from growing out of control? I was hoping the Mailbox Management process could at least stop the STM file from growing larger than its current size by simply opening up white space within it. I'd really appreciate an experienced view on this. Thank you any feedback!

If you are removing content from the database then it will be removed the relevant database depending on the content. You cannot go down to the specific database. The white space in the database is across both databases, not specific to either one. With regards to growth of the database, that is almost impossible to predict because of the different ways that companies work with email. If a lot of internal email is sent, then the EDB file might be larger and grow, because it holds most of the internal messages> However if most of the email is internet based, then the STM file would be larger and would grow. When I was running Exchange 2003 at home, my edb file was tiny, because almost all email I sent and received was from the internet. If you are seeing high growth levels in your STM file then probably users are receiving more of that data. Not really a lot you can do about it. An offline defrag is unlikely to help, because all that does is recover the white space, which Exchange will reuse anyway once the deleted item retention period has expired. If you have concerns, then a move to Exchange 2007/2010 would help, as there is only one database, meaning the white space management is a lot more efficent. Simon.Simon Butler, Exchange MVP Blog | Exchange Resources

Thanks Simon. So based on your response, it would seem that performing routine mailbox maintenance will indeed delete old data out of both files, not just the EDB. We have a fair amount of non-MAPI email. Not only do we have a steady stream of Internet email, we also have numerous internal systems [SQL, third party apps, etc.] that utilize the Exchange SMTP connector to relay things like alerts and reports. Over time, these internal systems that utilize mail have increased significantly, which explains why the STM has grown so much.

If they are only relaying the email to external recipients, then they will have nothing to do with the growth of the database, because the messages simply "bounce" off the server, they aren't delivered to the database. However if they are being delivered to the store and are SMTP based messages rather than MAPI, then you will see growth in that data type. The Exchange database shouldn't be looked at as two separate files, the two files make up the single database. Therefore trying to treat them differently isn't going to work. Simon.Simon Butler, Exchange MVP Blog | Exchange Resources

It's actually more the latter: the relays are configured for internal servers that are sending messages to internal user mailboxes. They had to be relays because of third party designs. These relays have nothing to do with external email however. So, the destination for most of these messages are Exchange mailboxes. As for the separate files, I definitely understand that they comprise the same database just like MDF and LDF files do in SQL. Going back to my original question, my main focus was on gaining an understanding of the maintenance job. So long as it has the capability to clear out BOTH subcomponents of the single database, then I'm good to go. I just wanted to make sure the STM file simply doesn't grow without some way to delete out the old data inside it. So my understanding from our conversation is that a standard job that deletes out anything older than say 90 days will clear space in BOTH sub-files, depending upon whether the messages were MAPI related or SMTP [non-MAPI] related. Is that statement true?

The online maintenance tasks will clear white space from both databases. I am not sure where you got the idea that it wouldn't. However you cannot guarantee where that white space will be cleared from, therefore it is possible that one or other of the databases will continue to grow in size because all of the white space reported by event ID 1221 overnight is actually located in the other database file. When it comes to mailbox management tasks, it doesn't matter where the content is located, it will be removed from the mailbox if it matches the criteria. Once the deleted item retention period has expired for that item then its space will become available again. Simon.Simon Butler, Exchange MVP Blog | Exchange Resources

Thanks for the clarification. I really did not pay much attention to the STM file in the past. It wasn't until it grew significantly in size that I began to wonder about how a purge would affect it [if at all]. So long as purges have a chance to clear out old garbage from the STM as well as the EDB, I'm fine. Thanks again for your feedback. If anybody else would like to weigh in, I'd welcome the commentary.