Blog Entry

MessagingArchitects's picture
blog
Reads:

1734

Score:
0
0
 
Comments:

0

To Stub or Not to Stub … and What to Stub?!

Author Info

23 October 2009 - 2:19pm
Submitted by: MessagingArchitects

(View Disclaimer)

Last week, we discussed the much maligned and misrepresented concept of stubbing. If you read that post, you learned that when used properly, stubbing can reduce the size of your mailbox store, thus improving the performance of your live mail system and reducing backup time.

So, what does “used properly” really mean?

Let's dive into the details, starting with attachments. Although usually a relatively small percentage of messages in our mailboxes contain attachments, these messages typically occupy 80 to 90 percent of mailbox disk space. Being able to remove these items from the live mail system, yet still have them easily accessible through the native client could reduce the size of your mailbox store by 80-90 percent! This is a great example of using stubbing in an intelligent manner — a small number of items are stubbed, but you're saving a large amount of space.

Another smart way to use stubbing is to stub aging data. Automatically removing aging information from the live mail system is a good way to control/manage the size of the mailbox store. It's becoming more and more impractical to let users keep infinite amounts of mail in their mailboxes. Unfortunately, this can clash with the user’s need to access aging information in a seamless manner (through the client) without having to access the secondary storage (archives) using a third-party app or browser.

Imagine a policy where all items in a user’s mailbox fall into three categories, based on their age:

  • 0 to 6 months — Messages reside on the primary mailbox store.
  • 6 to 12 months — Messages reside on secondary storage and are stubbed.
  • 12 months+ — Messages reside on secondary storage (archives).

In this scenario, users would have access to a full year's worth of mail through the native client, even though half of that data resides outside the live mail system. You could even get more granular and apply different policies to different to users, or groups of users, depending on their needs or role in the organization.

How Stubbing Should NOT Be Used…

Let's stub 100, 000, 000 items back into the live mail system! Or not. Although you will not take a huge hit on disk space because stubs are tiny little files, most enterprise-class collaboration systems (GroupWise/Exchange/Notes) store mail items in proprietary databases and have limits on the number of items that can exist and be indexed in a mailbox or folder. Stubbing doesn't change these limitations and should NOT be used in an attempt to give access to more mail items than one would otherwise keep in the live mail system.

Read more articles about stubbing

For more insight into messaging security, performance, compliance, and eDiscovery, check out our Blog


Disclaimer: As with everything else at Cool Solutions, this content is definitely not supported by Novell (so don't even think of calling Support if you try something and it blows up).

It was contributed by a community member and is published "as is." It seems to have worked for at least one person, and might work for you. But please be sure to test, test, test before you do anything drastic with it.




User Comments

© 2012 Novell