• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1755
  • Last Modified:

Priv1.stm unexplained growth.

The priv1.stm file is growing after 1 solid year of remaining exactly the same size.   It has grown approx 150 meg in 3 days.

October 05 to Present:          priv1.edb     8,698,696 KB

October 05 to October 06:     priv1.stm     2,852,872 KB

November 13, 2006:             priv1.stm     2,865,160 KB

November 15, 2006:             priv1.stm     3,004,424 KB

Exchange Server 2003 Service pack 1.  The size of priv1.edb has been virtually the same for the entire past year with an average of 3.5 gigs of free white space within the information store database.  Mailbox manager has been managing the overall size of the information store wonderfully.  

Research tells me that a typical .stm is audio, video, and any streaming MIME data.   Is this correct?  If so why after more than a year would it start to grow now.  I find it hard to believe that one or more users have not attached such a file to email in the past.

I run nightly full evault backups and the transaction log files are getting truncated.

Can someone please advise a course of action.  I prefer not to run eseutil at this time as Mailbox Manager, with its current settings, is managing the overall size of the database very well.

I should add that the only recent change to our environment was the addition of paperless fax.  Castelle Faxpress Appliance.  The appliance does act as an smtp client to transport faxes.  There is no connector installed on the exchange server and attachments are either pdf or tif so at this point in time I cannot see how that new system could be affecting the growth of the stm file.

Thankyou

Richard
0
rjearley1966
Asked:
rjearley1966
  • 9
  • 3
  • 3
2 Solutions
 
SembeeCommented:
Your understanding of the databases isn't quite right.

The EDB file contains MAPI messages. These will be messages from other users on your server.
The STM file (the streaming file) contains SMTP messages, messages from external users.

Growth of the STM file means that something has come in from outside. It could be an email loop, perhaps a large message has been sent.
What does event ID 1221 report now? If you had 3.5gb of white space that would explain the lack of physical size growth as Exchange was using the white space first (which is what it is supposed to do). If there was a loop then you may have seen most of the white space go and the database has had to be increased to accommodate it.

Do you have message tracking turned on? That may show the email loop.

Simon.
0
 
rjearley1966Author Commented:
I print out images of the mdbdata directory and Application log 1221  3 times weekly: Monday Wednesday and Friday.

Todays was:

     priv1.edb    8,698,696 KB
     priv1.stm    3,178,504 KB

Application Log Event ID 1221:

     3474 megabytes of free space aft online defragmentation has completed.

I have averaged between 3 and 4 gigs free white space after I deployed mailbox manager last spring.
0
 
rjearley1966Author Commented:
pardon i did not answer your question completely.  Message tracking is not currently on.


Richard
0
Concerto's Cloud Advisory Services

Want to avoid the missteps to gaining all the benefits of the cloud? Learn more about the different assessment options from our Cloud Advisory team.

 
SembeeCommented:
As Message tracking is not on, it will be difficult to stop the loop if it is still going. Your only chance is to keep an eye on the queues and see if something shows there.
No harm in turning message tracking on, as it can help with checking what happened to the messages.

The white space is probably in your EDB file and the STM file didn't have much. There is no way of knowing as you should technically treat the two files as one - the "store".

Simon.
0
 
rjearley1966Author Commented:
I will turn on Message Tracking and monitor the queues.  What would I look for in message tracking to identify a loop?  To be honest I have never witnessed a mail loop before.  Also which sub-queue should I monitor.   I do plan to update to Service Pack 2 but I preferred to force myself to manage the size of the information store database limit of 16gb imposed under Standard Scv Pack 1.  Internet based backups where a secondary consideration for me in increasing the store size.
0
 
LeeDerbyshireCommented:
If your users have started to use OWA a lot, then the .stm file would grow.  Messages originating from MAPI clients (e.g. Outlook) live in the .EDB file, but messages originating from non-MAPI clients (e.g. OWA) are created in the .STM file.  When .STM items are then opened in Outlook, they will be promoted to rich-text format in the .EDB file, leaving a copy in the .STM file.  Items do not get promoted from the .EDB to the .STM file, though - they are converted on demand when opened in a non-MAPI client, but not stored in the new format.
0
 
rjearley1966Author Commented:
We have no traveling users so I disabled OWA awhile back.  I am starting to suspect the castelle because that is the only recent change to affect email in any way shape or form; but the castelle is communicating with the exchange server on the local lan.  It authenticates as a domain user (specifically created for the Castelle appliance).  However it is not using Outlook as a mail client to communicate with Exchange.  Do you think that the Exchange Server would consider this client as an external mail client thus the growth in the priv1.stm file?
0
 
rjearley1966Author Commented:
Going to increase to 500 pts and split later after I get a few different views.   As a stop gap measure I have tweaked a couple of settings with Postini.   I have blocked multimedia, music and sound attachments inbound for the time being.  I am considering reducing the max size of inbound email from 20 meg to 15 meg also until I can identify what is occurring.
0
 
LeeDerbyshireCommented:
I think the fax appliance could definitely be storing items in the .STM file, if they get saved in a special Exchange mailbox.  Do you know which port number it's talking to Exchange on?  If it's 25 (SMTP), then it's even more likely.
0
 
SembeeCommented:
Faxes are often images, so if you are doing a lot of work with faxes then that could quickly increase the size of the store.

Simon.
0
 
rjearley1966Author Commented:
Yes the castelle is running native smtp.  One reason I chose Castelle over competing products is not necesary to install exchange connector on the mail server.  It is running an email gateway over port 25.  
0
 
rjearley1966Author Commented:
Having anticipated an issue with store growth with the new faxing system.  I created outlook rules to route emailed faxes from the castelle to an   Incoming Fax   folder in Outlook.  I then added this new sub inbox folder with a rule in Exchange mailbox manager to delete anything older than one week.  
0
 
rjearley1966Author Commented:
I captured this in netstat-a on the faxpress applicance:  (took some refreshing)

TCP    Faxpress:1502          XXXXXX.XXXXXXXX.com:smtp  ESTABLISHED

XXXXXX.XXXXXXXX.com being the fqdn of my mailserver

so it appears the castelle is connecting as a pure smtp client......
0
 
LeeDerbyshireCommented:
Yes, I am quite sure that this is going to contribute to the size of the .STM file.  You could always monitor the size before and after a period in which a lot of faxes are sent.  Note that the size of the .STM file will not decrease in normal use - an offline defrag is needed to reclaim the white space.  The DB files only tend to get bigger, topping out at a certain size consistent with their routine usage, rather than fluctuate in size.
0
 
rjearley1966Author Commented:
Thank You Sembee and Lee if its ok I will split the points between the both of you.  

Rich
0

Featured Post

Concerto Cloud for Software Providers & ISVs

Can Concerto Cloud Services help you focus on evolving your application offerings, while delivering the best cloud experience to your customers? From DevOps to revenue models and customer support, the answer is yes!

Learn how Concerto can help you.

  • 9
  • 3
  • 3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now