The following comments are from a stubbing discussion on the NGWList, a Novell GroupWise user email listserv. Charles goes into details about the issues of stubbing.

++++++++++++++++++

Simon,

It's true that the current conventional wisdom around stubbing in the
Exchange world is shifting towards only stubbing attachments (even
Microsoft is recommending it). This is not only critical from a
performance point of view, it also makes a lot sense since it's really
the attachment that consumes the space.

BTW... The initial stubbing API Novell is delivering in GroupWise 8
does not support stubbing of only attachments. It's the whole message or
nothing. This could change with SP1, but the community will have to
speak up since as far as I know, Novell has no plans to support stubbing
of only attachments.

Assuming it were possible with GroupWise, as it is with Exchange, this
change of technique also necessitates a change in the purpose of
stubbing. Stubbing becomes more of a niche solution for managing e-mail
storage, and not an archiving compliance solution.

One of the theoretically nice benefits of full stubbing is that you can
archive the entire message (for compliance), but allow end users to
access those archived messages via a stub in their e-mail client. This
is great, because end users don't have to be trained to access archived
messages through a different interface like a Web UI or a separate
Windows client. So with no client-side software or plugins and a
seamless integration with the e-mail client, you can comply with
retention laws without having to deploy software to the client or train
your end users. In theory, this is the ideal way of doing archiving.

Of course, if you are only stubbing (archiving) the attachment and not
the message, then you really aren't talking about compliance/retention
anymore and are now talking about a solution to move the storage burden
off of the e-mail server. Of course, archiving software like GWAVA's
Retain for GroupWise will be able to archive all e-mail (leaving the
original untouched in GroupWise) and then also, stub attachments older
then X days (if Novell expands the stubbing API), so you can comply AND
remove attachments from GroupWise, but as you can see, stubbing becomes
and extra function sitting on top a full archiving solution rather then
a solution in and of itself.

Charles Taite
ct@gwava.com

Don't forget to register for GWAVACon Las Vegas, January 25th to 27th.
Use discount code "NGWLIST" at http://www.gwavacon.com

>>> "Simon Shilton" 11/12/2008 7:53 AM
>>>
Gert

thanks for the links

I like the comments on the Ferris site, particularly Tom Politowski,
see below, who's description of their preferred approach reminds me of
the native GW architecture.

How to improve Outlook/Exchange performance with large datasets, make
the message storage more like GroupWise, by adding a third party
product
:-)

Simon

"I think Bob Spurzem is “on the mark” and also has a “CLEAR
MISS”.
Older “stubbing” technology present in some first generation email
archiving solutions are dangerously fragile with respect to loss of
data, loss of links, and spoiling the Outlook experience.
However, new, second generation solutions like MailMeter avoid the
problems mentioned by Bob because they remove only attachments from
candidate messages (leaving the message body intact) and replace the
attachment with a link to the archived attachment. The attachment is
launched dynamically from the archive when the user clicks on the
link.
The advantages to this approach are: 1) the user’s Outlook
experience
is not spoiled by having only partial messages; 2) there is no need to
retrieve the message from the archive to view it; 3) the attachments
removed are the largest part of storage used in a message - giving big
storage savings; 4) the attachments are retrieved directly from the
archive for the user without going back through the Exchange server;
6)
in case of a lost message, the user can get a copy from the archive.
So we agree on leaving the Outlook user experience intact - don’t
stub
messages (just stub attachments). And do it like we do without an
Outlook Add-in!"

>>> On 11 November 2008 at 22:59, in message
, Gert
wrote:

See also http://www.ferris.com/?p=320762
http://webcasts.techrepublic.com.com/abstract.aspx?docid=386943

Gert

GWCheck.com - is your GroupWise ready ? - "the best GW site" (Tay
Kratzer)
skype:GWCheck
stay up 2 date - http://gwcheck.com/wpml/?feed=rss2
visit www.gwcheck.com

join the GW community
http://groupwiser.net/info - http://gwavanation.com -
http://www.ngwlist.com

On Tue, Nov 11, 2008 at 11:25 PM, Gregg A. Hinchman
wrote:

To Bring back the Topic of Stubbing:

From: http://technet.microsoft.com/en-us/library/cc671168.aspx

Quote:
Eliminates stub files when using third-party archiving solutions
Third-party archiving solutions have become popular as corporate
compliance requirements and mailbox quota management have gained
importance. Many of these archiving solutions offer the ability to
leave
a small stub file in place of the archived message that can be used by
end users to retrieve archived messages from the archival system. Some
organizations use the stub file solution as a workaround to offering
large mailboxes. One of the goals of stub archiving solutions is to
reduce the aggregate mailbox and database size, thereby reducing
recovery time objectives (RTOs). On the surface, this appears to be a
good idea. However, stub-based archiving solutions have the following
technical problems:

* Server performance Removing the message bodies and attachments
from Exchange reduces the mailbox size, but it does not significantly
change the server performance for users accessing Exchange via Outlook
in online mode and Outlook Web Access. Item counts are the primary
performance driver for the Exchange store, and not aggregate size. For
example, server performance with a folder containing 100 KB of full
e-mail message items is similar to a folder containing 100 KB of stub
files.
* Client complexity Because the use of stub files with a
third-party archiving solution requires the deployment and use of
Outlook add-ins, a significant amount of time must be spent by
administrators to deploy and manage these add-ins. Administrator time
is
also required to assist end users with technical difficulties using
the
add-ins. Not deploying stub files
removes all of this additional
administrative work that must be performed, thereby allowing more time
to administrators and end users.
END

So as you can see -we have some 'fun' ahead of us with GW and
stubbing.
It will be interesting to see how GW 8 does.
--

Take Care.

Gregg A. Hinchman
Consultant
Gregg@HinchmanConsulting.com ( mailto:Gregg@HinchmanConsulting.com )
www.HinchmanConsulting.com
A Novell Consulting Partner
317.329.0288 Office
413.254.2819 eFax

"Courage is doing what is right."

"Do not be bound to any doctrine, theory or ideology, even Buddhist
ones. All systems of thought are guiding means, not absolute truth."
Thich Nhat Hanh, Vietnamese monk.