The .STM file, or streaming file, holds non-MAPI information while the .edb file, or the Exchange database (essentially a large JET (Access-type of technology) database holds the messages and the MAPI information. If someone sends e-mail or accesses e-mail from a non-MAPI client (POP3, IMAP4, Web), that e-mail is stored in the .stm file. Mail from the internet is also non-MAPI and comes in a format called MIME. This information is also stored in the STM file. It may be converted to MAPI when a MAPI user (Outlook) accesses it and it is also converted to MAPI when the Move Mailbox wizard is used. There also may be pointers in the .edb to information in the STM.
Here are a few links that help to demystify the STM file:
http://www.winnetmag.com/Windows/Article/ArticleID/8955/8955.html(about 1/3 of the way down in the document the STM is discussed)
Native Content Storage in Microsoft Exchange
http://support.microsoft.com/kb/232323(Good article...communicates the idea behind the STM very well)
What causes a large .STM file?
Several things can cause a large STM file. One of those could be that your server is open as a relay. Sembee, an Experts-Exchange expert, and a Microsoft MVP, has produced some concise information.
http://www.amset.info/exchange/smtp-relaysecure.asphttp://www.amset.info/exchange/spam-cleanup.aspAnother thing that you could have in your system is a loop. Leaving Exchange up (and getting an outage approved), unplug the network cable temporarily. Take a look at your queues and see what gets queued up. Look @ both the SMTP messages and the messages in your MTA. Another thing to do is to enable message tracking and see who is sending a large amount of messages.
Look at your mailboxes and see what the largest mailbox is.
If you have a very large STM and a small EDB, something is wrong. Examples of exceptions are if you have an inordinate amount of OWA users, run a business that receives a lot of Internet e-mail, have a lot of POP3 users, who leave messages on the server, etc.
Some anti-virus scanners have even been known to cause problems with Exchange, both a the file level as well as Exchange-aware AV apps.
Please see this Experts Exchange question, and answer, regarding file-level AV scanners and Exchange:
http://www.experts-exchange.com/Q_21300420.htmlRegarding mailboxes:
One thing that you can do is look at the mailbox sizes, add them all up, and see if they are over xx GB. If they are, then you are fine. Even though Exchange has a single instance store, the user’s mailbox shows what they are using, but does not note the single instance storage info. So, in theory, if some users share documents, etc. then the store will be smaller than the total of the mailboxes in the store. So, if 2 mailboxes have a 1GB attachment (unrealistic, I know), they will total 2GB but the database will be 1GB (and change) (this is provided a new server with only 2 mailboxes).
Regarding the amount of free space in your Exchange database, and what you can expect to recover, check for 1221 events noting how much free space is in your database.
http://support.microsoft.com/kb/186291
Do you have enough room for an offline defrag, if needed? (Some good resources)
http://www.petri.co.il/defragment_exchange_2000_2003_server_databases.htm (links are wrapped)
http://www.microsoft.com/exchange/techinfo/tips/defragmentation.asp (links are wrapped)
http://support.microsoft.com/kb/254132This may help, if you are using NAV/SAV for Exchange:
http://bobchristian.blogspot.com/2005/02/symantec-mail-security-settings.htmlThere have been a few E-E topics where it was noted that AV applications bloated the STM file.
If you are not running Exchange-aware backups, but you shut down the Exchange services for your backup and do a brick-level backup, this will not clean off old mailboxes or clean up items that have been emptied from the deleted items. Another bad thing about this is that the Transaction Logs will not be flushed, which causes disk usage to increase, unless you have implemented circular logging for each of your storage groups (*shudder*). Usually you don’t notice this until the disk space is significantly small and you have several thousand 5MB files on your drive. If you have a third-party backup utility and did not purchase the Exchange bits for it, at least run an NTBackup on the Exchange server and back the Exchange databases to disk. You can back up that .bak file with your normal routine, and then remove the large .bak file.
While this is a lot of information, and it comes in a somewhat “throw it to the wall” manner, I hope it helps.
…and if you are limited to 16GB, running Exchange Standard Editions, and you are in your 1GB buffer, you will want to reset the key back to zero (0) from one (1) so that you don’t hit 17GB and end up with a server that won’t start the IS:
HKLM\SYSTEM\CurrentControlSet\Services
\MSExchangeIS\
Private\Temporary DB Size Limit Extension
More information regarding this key can be found in KB813051
http://support.microsoft.com/kb/813051