Just thought I'd add my 2 cents also and pass on my support in your
argument.

It's much more reassuring to know that the Connect Agent utilizes the
Exchange API rather than relying upon alternative / unsupported API's.
I for one like the ADSM Connect Agent and overall I am satisifed with the
product. We replaced the existing Backup Exec (ADSM option) with the Connect
Agent and have found it to offer superior performance and reliability when
tuned correctly.

That doesn't mean I think the product is perfect, I still have my own
personal wish list for this product e.g. meaningful error messages (see
previous post).

Brick Level Backup may sound appealing, but as some others have stated it is
both slow and also requires more storage. Some businesses may see it as a
critical need, but I do not. If someone needs a single mailbox restored then
that's just one user with an outage. Probably not a big deal unless he's
your CEO. However when the whole server goes down you need the restore asap
and that's where brick level backup will fail to deliver.

Personally I just don't think 100Gb stores are a good idea right now. While
100Gb stores will allow you to consolidate some hardware, the placing of all
of the eggs in one basket does not give me a warm and fuzzy feeling. Most of
the instances where we've had to restore Exchange Databases have been the
result of logical corruption , not hardware failure. Exchange 6.0 is
supposed to provide for multiple databases on one server. This should help
ease this dilemna slightly as you could then have two 50Gb stores on the
same hardware without all of the risks. It should also make backup/recovery
more workable.

Nathan




        -----Original Message-----
        From:   Jordan, Chris (ELS) [SMTP:c.jordan AT ELSEVIER.CO DOT UK]
        Sent:   Monday, October 25, 1999 9:51 AM
        To:     ADSM-L AT VM.MARIST DOT EDU
        Subject:        Re: ADSM and Exchange

        Chris,
        There are a large number of people who are reading these
explanations, and
        agreeing with you. Just because we do not respond does not mean that
we want
        ADSM to change.

        I, for one, want ADSM to use well documented and available
interfaces into
        Exchange. If you modified ADSM to use some other interface, then the
        Exchange System Managers would not allow ADSM to touch their
database - and
        that would be bad for everyone.

        The Deleted Items Recovery options in Exchange have proven to be
effective
        in most cases, and many Exchange sites have not needed to restore a
database
        since this option was introduced.
        Of course, a restore IS still required to a test server on a regular
basis
        in order to test your backup and restore procedures, so that when
you need
        to restore you can do smoothly.

        Cheers, Chris
        (Exchange Consultant since pre-BETA days).

        -----Original Message-----
        From: Chris Zaremba [mailto:zaremba AT US.IBM DOT COM]
        Sent: 25 October 1999 15:11
        To: ADSM-L AT VM.MARIST DOT EDU
        Subject: Re: ADSM and Exchange


        ADSML,

        >But it is a SEVERE limitation of
        >the implementation of ADSM.  Especially when you got John Q. Public
        >out there in the middle of the night having to restore 100+GBs
        >of data to recover a single message.

        The customer should not have to be restoring 100GBs to recover a
single msg.
        You make it sound like the customer has no other choice because we
have not
        provided individual message granularity.  The fact is, the item
recovery
        feature
        in exchange 5.5 offers a solution that allows for single msg
recovery
        without
        having to restore anything from backup media. This approach does not
have
        any of
        the issues of a MAPI backup/recovery implementation and is also
consistent
        with
        the exchange architecture and it is a solution that many customers
are using
        today.

        I do not consider it prudent to provide a function with lots of
limitations
        and
        issues to address a problem that has an alternate and superior
solution in
        the
        exchange product itself.  I agree that at a high level (i.e.
marketing
        hype),
        this can be made to sound like a severe limitation, but once
customers are
        informed of the issues associated with a MAPI implementation and the
        alternative
        way to address the problem, they tend to agree that it is not so
important
        to
        have that functionality in the backup product.

        >And more and more customers with Exchange and the e-message
        >boom is leaving a lot of customers with HUGE stores of information.
        >
        >If this is the case, where does that leave the customer in IBM's
>thinking?


        It is exactly because the information stores are growing so rapidly
that it
        is
        important to provide a backup solution that performs and scales
well.  You
        talk
        of theory vs. practicality.  Have you ever tried backing up and
restoring a
        100GB or larger IS with a MAPI solution that provides single message
        granularity?  I suspect not as you would quickly find that it is not
a
        practical
        solution.

        By choosing not to implement single item granularity via MAPI and
explaining
        the
        reasons why, I believe it leaves our customers better informed and
able to
        discern the marketing hype from the real technical issues.
Hopefully, they
        now
        understand that there is a better way to address the single item
recovery
        problem than a backup/recovery solution via MAPI.


        Chris Zaremba
        TDP Client (formerly ADSM Agent) Development
        internet  zaremba AT us.ibm DOT com