PDF Print E-mail




Will an email archive system depending on "stubbing" be useful as your Email Archive solution?

Stubbing: A stub is just a small file that points to a copy of the original message in the archive (residing in a different location) and presents numerous challenges

Make no mistake, stubbing solutions offered concrete benefits. Many customers saw initial mailbox sizes shrink and quickly reduced backup windows. But the same customers discovered over time that stubbing also created new, bigger challenges. Let’s explore some of the challenges stubbing customers faced over time.

The Promise: Stubbing improves Microsoft Exchange and Microsoft Outlook performance.
The Reality: Stubbing customers learned item count is what drives performance, not mailbox size.

Stubbing products initially seemed to work like magic, shrinking email stores and related backup windows. But, unfortunately, customers discovered that even though stubbing solutions reduced mailbox size, they left the item count the same. So mailboxes eventually filled up with hundreds of thousands of tiny files. Exchange administrators quickly learned that their server maintenance (e.g., backup, defrag) and client performance (e.g., opening Outlook) was just as slow over time as it was before deploying the archiving solution. After seeing many Exchange customers struggling with stubbing, Microsoft released this TechNet article in 2008 (http://technet.microsoft.com/en-us/library/cc671168), recommending against stubbing. Microsoft explicitly stated: “When deployed, these [archiving] solutions should be configured to move the email content out of the mailbox without retaining stub files in the mailbox.”

The Promise: Stubbing is easy for IT to deploy.
The Reality: Stubbing customers learned Microsoft Outlook plug-ins are hard to deploy and support.

In the same TechNet article, Microsoft notes that archiving solutions that rely on stubbing also require the deployment and use of Outlook plug-ins. While vendors often talk about how “lightweight” and “easy-todeploy” their plug-ins are, many customers struggled with deployment, troubleshooting, performance challenges and end-user complaints. Specifically, DLL (dynamic-link library) compatibility issues (“DLL hell”) and Outlook Forms deployment challenges tripped up many stubbing deployments. And every time Microsoft introduced a new Service Pack for Microsoft Outlook, stubbing vendors and their customers would have to rush to release and deploy upgrades.

The Promise: Stubbing is easier for end users.
The Reality: Stubbing customers learned that their end users had to search two email repositories.

Many IT departments liked the idea of stubbing because the message appeared to stay in the user’s mailbox. However, since messages were either fully in the mailbox (e.g., less than 30 days old) or partially in the mailbox (e.g., as stubs after 30 days), users ended up having to search the mailbox (via Outlook search) and the archive (via the archive’s native search) for any given item. In addition, Mailbox Management 1.0 solutions often offered limited, poorly designed and slow end-user search, meaning end users rarely searched their archives.

The Promise: Stubbing allows access from anywhere.
The Reality: Stubbing customers learned that stubs don’t work on mobile devices.

Forrester Research (October 2008) reports that mobile workers will make up 73 percent of the workforce by 2012. This is why mobile access is quickly becoming a business necessity for archiving solutions. And while some on-premise solutions may equip end users with archive access via Microsoft Outlook Web Access, stubs viewed from other devices (e.g., Windows Mobile or BlackBerry) won’t work, since the mobile client doesn’t have a plug-in and thus can’t interpret the stub.

The Promise: Stubbing solutions should be maintenance-free once deployed.
The Reality: Stubbing customers learned that stubs don’t work well in migrations.

Over time, email servers fill up with stubs as messages are archived. Without the archive, the stubs are rendered useless. So if a company migrates its archived data, the stubs have no place to point. Users are then unable to use the vast majority of items in their inboxes. So how do they recover? The standard method is to restore all of the stubs back into the email server prior to migration. But imagine a three-year archive and three years’ worth of stubs. If your organization used the stubs to shrink the average mailbox to 500 MB of stubs, for example, then those same stubs might represent (using a 10:1 ratio) about 5 GB of space. Do you have temporary space in your email environment for a 10:1 increase in storage during the migration? Can your email server even handle it? More importantly, if your company is planning to migrate to a cloud-based email platform (e.g., Microsoft Exchange Online), stubbing is not an option, since it requires an on-premise footprint, which enterprise-class, cloud email providers do not allow in their data centers.

To find a better solution, This e-mail address is being protected from spambots. You need JavaScript enabled to view it at 770-603-0300.