Increasing STM file advice

This article describes what is stored in the .stm file:

http://support.microsoft.com/?id=232323

Basically, all internet email message body's are stored in this file initially, and if you have a lot of non-MAPI protocol clients (pop, imap) your .stm will contain a lot of data.

Also, you should make sure your Online Maintenance is completeting.  Monitor you application logs to determine if it is completeting.  The logs will also tell you how much space is available to reclaim from the .edb and .stm files with an offline defrag.

---

Also any kind of error messages being seen in the EventLog file on the server?

We do not have any non-MAPI clients.  Online Maintenance is completing and I can tell from event 1221 in app. event viewer that we have about 7 GB free.  Which log will tell me how much I can reclaim via offline defrag.?

Check out this article/thread...
http://forums.msexchange.org/m_1800399078/mpage_1/key_/tm.htm

How can I defragment Exchange 2000/2003 Server databases?
http://www.petri.co.il/defragment_exchange_2000_2003_server_databases.htm

Next question:  Does event 1221 tell you how much total space is available or just in the .edb file?

Determining database free space with Exchange 5.5 Service Pack 1 and later versions of Exchange
http://support.microsoft.com/kb/195914/en-us

Good article, but does the event 1221 cover free space of both priv1.edb and priv1.stm combined?  It doesn't really say for sure from what I could see.  To me it seems it just shows free space in the .edb file.

According to this article (http://www.msexchange.org/articles/Exchange-Databases-Disk-Consumption.html) it seems that it only covers the .edb file.  

"Currently there is some controversy around the question of event 1221 including both the EDB and the STM file for Exchange 2000/2003. It seems that this event only includes the EDB file."

Offline defragmentation

Event ID 1221 will tell you how much white space there is in the database and the amount of space that is likely to be reclaimed if an offline defrag is run. A server outage will of course be required in order to run this task, and sufficient time (with plenty of lee-way) should be agreed before going ahead. Dont forget to include obtaining a tried and tested backup in your plans before carrying out the defrag. There is a significant amount of disk I/O during the defrag, and disks have been known to give up at these times. You may want to make sure that you've got a spare disk 'just in case.' The length of time that the defragmentation will take will depend on the amount of white space in the database, as well as the size of the transactions recorded in the database, not forgetting the hardware spec too. The process will essentially be copying all readable data from one database into a new structure in the second new database, and then copying the entire 'new' database back to the original location. Microsoft recommends a conservative 5 - 7 GB per hour for a defrag operation, which will be faster on top of the line hardware and slower on underpowered machines. You should make every effort to run the defrag on the server and not across the network, as it will be much much faster. "Offline defragmentation also requires free hard disk space of at least 110 percent of the database size.

For example, Eseutil requires up to 1.10 gigabytes (GB) of free space to defragment a 1-GB Priv.edb database. Eseutil uses this hard disk space to create a temporary database that the defragmentation process uses. By default, Eseutil creates this database in the current working folder of the command prompt session from which Eseutil runs."

Article:
http://hellomate.typepad.com/exchange/2004/03/exchange_standa.html

Eseutil /d Defragments the Database and the Streaming File
http://support.microsoft.com/kb/254132


Another EE Article/Thread:
https://www.experts-exchange.com/questions/21123589/Difference-between-priv1-edb-and-priv1-stm-need-to-determine-accurate-size.html

I know about offline defraging and that it covers both the .edb and .stm files.  My original question was if the audio attachments (.wav) from voicemails forwarded by the PBX system could be causing the stm file to grow.  We don't use any other non-MAPI clients so that is not the issue.  So, could those .wav files be the cause of the growing .stm file?  I know how to try and recover space if need be.  I'm more concerned about the cause of the growth.

Yes, the audio attachments are causing the stm to grow.

Here's why:

The Exchange stores are held in two database files:

    * EDB  A rich text database file (also known as the rich text store) containing message headers, message text, and standard attachments.Important: the EDB file contains the store tables which are used by clients when accessing data.
    * STM  Also known as the streaming Internet content file, containing  audio, video, and other media that are <!--StartFragment --> formatted as streams of Multipurpose Internet Mail Extension (MIME) Data

Reference: http://www.messagingtalk.org/content/227.html

Definitions of key transport components in Exchange Server 2003
http://support.microsoft.com/kb/821879

If I have archiving set up, will that prevent the stm file from continuing to grow?  Meaning the attachments get archived with t he messages.  Right now I have all messages older than 2 months being archived.

Under Exchange 2003, the only way to reduce the STM is to delete mail and do another offline defrag. An offline defrag is the only way to reduce the size of the STM.

"Archive all messages..." saves a copy of every messages that passes through that store. You don't want to enable that, it will make your problem worse.

Your best bet is to set a size limit on mailboxes so that the limit x number of users is less than 16GB (or 75GB if using Exchange 2003 SP2).

I'm not archiving to the server, I'm archiving messages off of the server.  My EDB file was growing the same way and when I implemented archiving it solved it.

Sorry, to clarify I'm not using the "Archive all messages sent or received by mailboxes on this store" option.  I'm using the auto archive feature in Outlook.

And in response to your question:

"If I have archiving set up, will that prevent the stm file from continuing to grow?"

No, it will not reduce the STM. The archive might solve the EDB issue, but not the STM. The STM will continue to grow UNLESS you delete mail and do another offline defrag.

---

Exchange 2007 has gotten rid of the STM file entirely.

Exchange 2007 Store Related Changes and Improvements
http://www.msexchange.org/tutorials/Exchange-2007-Store-Related-Changes-Improvements.html

What's the difference between deleting mail and archiving mail as far as the server is concerned?  Archiving mail is still moving mail off of the server.

Exchange 5.5/2000/2003 keeps its mail structured in a database-like format (i.e. the EDB + STM) along with an embedded index. When you do an off-line defrag, you are in a way re-indexing the database. Archiving doesn't do this, thus the 'holes' in the database are still found in the original index and are seen to the Exchange environment as still being unavailable.

Exchange 2007 does away with the STM file, thus allows archiving to actually do its job correctly and reduce the EDB as well as re-index the Exchange database.

There is really no quick/fix for the issue under Exchange 2003, so its just part of the system administration details for using SBS 2003 and Exchange 2003.

Ok, understood.  So the only way to recover that white space is to run offline defrag.  And, this works for both messages that were archived and deleted.  There's nothing special I'm missing where it only works for deleted messages, correct?

From what I've read, offline defragging isn't seen as regular maintenance, but it seems that this situation would be fairly common.  In your opinion, is offline defragging common (a couple times a year)?

Since you are using SBS 2003 with is integrated with the Exchange standard environment, you might have to migrate from the SBS platform so you can upgrade to the Exchange 2003 Enterprise or Exchange 2007 enterprise platform as both of these platforms are more aligned for handling voice mail in E-mails, etc.

You could do the off-line defrag a couple of times a year, but I highly recommend having a full backup before you attempt to do so. I also recommend not having anyone or anything accessing the SBS server prior to running the off-line defrag as the off-line defrag puts a lot of I/O stress on the overall SBS system.