Blog Entry

(View Disclaimer)

Stubbing. The issue continues to be discussed with a lot of claims being made. Stubbing is a function of email archiving. You can't stub unless you have an archiving solution. All, 100%, every single one of the GroupWise vendors offering archiving solutions support stubbing in GroupWise. But, just because they support it doesn't mean that it is a good idea.

Jay Parker, a very skilled and distinguished engineer for the GroupWise team asked me today why I keep beating up on stubbing.

Here is my answer:

Why do you stub? Mainly you stub in the hopes of reducing your GroupWise message store. You want to reduce your GroupWise message store so you have better performance, faster backups, and more stability.

That is all good. But what do you have to do in order to achieve this level of success with stubbing. Ah, here is the question and the core of the confusion. Recently a vendor claimed that stubbing can possibly reduce your GroupWise mailbox by 80-90%. The claim in based on attachments taking up the majority of your mailbox size and if you stub out the attachments, then presto, your GroupWise message store is reduced. NOT!

Look, GroupWise is an extremely scalable, robust, stable product for a reason. It has something called Single Instance Storage. This means if you have 100 users on a Post Office and send them all a file that is 10 MB in size, you don't end up with 1 GB of disk usage (100 users x 10 Mb = 1 GB), instead you simply have a single copy of the file at 10MB with everyone pointing to the file.
This is the simple part. It is clean and easy.
Now, let's stub that 10 MB file attachment and see if we achieve a 80-90% decrease in our message store for GroupWise.

First, who is going to be stubbed? Who makes this decision? Does everyone have the same policy, or is the their a hierarchy of needs where some people in the organization don't want to or can't use stubbing?
For example. Mobile users on mobile devices can't see their messages if they are stubbed. Web Access users can't see their files. Mac and Linux client users can't see their files, only Windows clients.
Is their an age policy of files with exceptions for Executives?

With all of this now decided, let's look at what happens to the file that is being stubbed.

100 people received the 10 MB file. There is only one copy of the file in the message store. The decision is made to stub everything older than 60 days, or bigger than 5 MB, or whatever reason.

Okay, off goes the stubbing and pulls it out of the GroupWise message store and places it in an archive that also has single instance storage. This means even though multiple users are moving in their data, only 1 copy exists in the archive. Ideally, the 10 MB file should be out of GroupWise and in the Archive, thus reducing GroupWise by 100% for this file, or 10MB.

BUT WAIT....did 100% of the 100 users meet the stubbing requirements? Are 100% on Windows, do 100% not need access via WebAccess, and are 100% in the same archiving policy group, meaning no one is an exception.

Because if even 1 person is an exception, for whatever reason, then that 10MB file stays in GroupWise, with ZERO reduction in the message store. You now have a 10MB file in GroupWise AND a 10MB file in your Archive. You didn't reduce your disk requirements, you actually increased them. And at the same time you introduced a level of complexity to your message system without any of the benefits of a smaller GroupWise system.

The claim that 80-90% of your message store can be reduced with stubbing is flat out wrong and irresponsible to suggest. The requirements to meet this number are so strict and confining that it is nearly impossible to achieve.

You can't stub a single mailbox and reduce the message store significantly unless certain situations are met.

First, the majority of the files with attachments are sent to a group inside the GroupWise system that ALL are stubbed together.

Second, a large number of files with attachments are sent outside of the GroupWise message store.
These two circumstances will allow you to drastically reduce your GW system, but again, one person, one user, one exception, and it all is for nothing.

I'm not bashing Stubbing, I'm bashing the misinformation that is being pushed as a reason to adopt stubbing. If you are implementing this feature, be very sure that you realize how you must configure your stubbing to limit the exceptions. Otherwise you are simply creating a bigger problem than you are solving.

I have created a short video that explains what I'm talking about. You can find it at:
http://richardbliss.typepad.com/richardblissblog/2...

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.