Problems are to be expected with mailbox over 2.4 GB? For real?

I submitted an SR for a user whose caching mailbox status bar (lower
part of the windows client main screen) consistently, across three
different machines, shows "Mailbox Size: 30%" or some other comfortably
low statistic.

This user's online mailbox is at 90% (I gave him a little more space so
it's 80% now).

I do have size limits applied to cache as well as online, and in the
caching mode client, you can go to tools/check mailbox size and see an
accurate depiction of a mailbox at 90% - it's just that this little
automatic piece right on the main client screen is always wrong.

The Novell tech brushed me off thusly:

"Unfortunately, with a 7.65GB mailbox, I would fully believe that the
user is going to see more problems than just an incorrect size report in
the caching client.

The larger the mailbox gets, the more problematic it becomes. This is
true of any mail application, Notes, Exchange, etc. All of your 2.4GB
mailboxes are working just fine, which is really about the max that you
would want them.

So if the user feels that they cannot reduce the mailbox below the
current size, then there will just be things that come up along the way
that will cause problems for this mailbox.

You can also try using the standalone GWCheck on that users workstation
and run a Contents check against the Caching mailbox with 'Update user
disk space totals' enabled. You may have to run it one or more times per
day to keep the stats the way you want them."


So tell me, please: is that a reasonable or factual reply??????

Tags:

  • Am 19.05.2016 um 23:02 schrieb Mary Wood:

    >
    >
    > So tell me, please: is that a reasonable or factual reply??????
    >


    Absolutely not. Ask for an escalation.

    CU,
    --
    Massimo Rosen
    Novell Knowledge Partner
    No emails please!
    http://www.cfc-it.de
  • I wouldn't say there is any hard set limit to a mailbox. However the likely hood of things "going wrong" could increase.
    I'm sure things are better now with GroupWise 2014, and this was probably seen more with Groupwise 8 or 2012
  • Thank you, Massimo!



    On 5/19/2016 4:19 PM, Massimo Rosen wrote:
    > Am 19.05.2016 um 23:02 schrieb Mary Wood:
    >
    >>
    >>
    >> So tell me, please: is that a reasonable or factual reply??????
    >>

    >
    > Absolutely not. Ask for an escalation.
    >
    > CU,


  • Am 19.05.2016 um 23:46 schrieb snielson:
    >
    > I wouldn't say there is any hard set limit to a mailbox. However the
    > likely hood of things "going wrong" could increase.
    > I'm sure things are better now with GroupWise 2014, and this was
    > probably seen more with Groupwise 8 or 2012
    >
    >

    No. The size of a Mailbox is completely irrelevant. Why should a mailbox
    with 10 Mails each with a 500MB attachment have any problems? I
    routinely have customers who encounter mailboxes in the dozens,
    sometimes hundreds of gigabytes. My own 17 year old mailbox at this
    point in time is well over 20GB, and shows no sign of any problem
    whatsoever, and never has since GW7 (before that the amount of items,
    but *NOT* the size could cause visibility issues in folders).

    CU,
    --
    Massimo Rosen
    Novell Knowledge Partner
    No emails please!
    http://www.cfc-it.de
  • Here's the response I got to an escalation request:

    "Your SR was already escalated. I am Advantage level support, not Frontline.

    I am assuming that you did not like my answer since you wanted to
    escalate the SR.

    You only have two options for tying to fix the caching mailbox.

    #1) Use the standalone GWCheck and run a Contents check against the
    cached mailbox.

    #2) Delete and recreate the caching mailbox.

    One may help for a while, but no guarantees.

    Otherwise, your best bet is still a reduction in mailbox size."


    I've already run gwcheck many times, and recreated the caching mailbox
    on three different machines. Same issue. The guy is right - I do *NOT*
    like his answer. And I wonder whether it's valid, since other large
    mailboxes don't exhibit this problem.


    On 5/20/2016 3:39 AM, Massimo Rosen wrote:
    > Am 19.05.2016 um 23:46 schrieb snielson:
    >>
    >> I wouldn't say there is any hard set limit to a mailbox. However the
    >> likely hood of things "going wrong" could increase.
    >> I'm sure things are better now with GroupWise 2014, and this was
    >> probably seen more with Groupwise 8 or 2012
    >>
    >>

    > No. The size of a Mailbox is completely irrelevant. Why should a mailbox
    > with 10 Mails each with a 500MB attachment have any problems? I
    > routinely have customers who encounter mailboxes in the dozens,
    > sometimes hundreds of gigabytes. My own 17 year old mailbox at this
    > point in time is well over 20GB, and shows no sign of any problem
    > whatsoever, and never has since GW7 (before that the amount of items,
    > but *NOT* the size could cause visibility issues in folders).
    >
    > CU,


  • Mary,

    Am 23.05.2016 um 12:12 schrieb Mary Wood:
    > Here's the response I got to an escalation request:


    Can you send me the SR number? I see what I can do.

    CU,
    --
    Massimo Rosen
    Novell Knowledge Partner
    No emails please!
    http://www.cfc-it.de
  • Mary,

    Am 23.05.2016 um 12:12 schrieb Mary Wood:
    > Here's the response I got to an escalation request:


    And BTW... I guess this is simply a bug. The caching client historically
    always simply showed a local percentage in the status bar derived from
    the free local diskspace on the machine. It has done that long before
    you even *could* apply a size limit to the caching mode.

    Now here comes the feature that adds the "real" size limit to the
    caching mode too. Obviously they simply forgot to also change the
    display in the status bar and how it's calculated at the same time.

    The answer of the tech however is.....

    CU,
    --
    Massimo Rosen
    Novell Knowledge Partner
    No emails please!
    http://www.cfc-it.de
  • That is 101007065621

    Thank you so much, Massimo!

    On 5/23/2016 5:24 AM, Massimo Rosen wrote:
    > Mary,
    >
    > Am 23.05.2016 um 12:12 schrieb Mary Wood:
    >> Here's the response I got to an escalation request:

    >
    > Can you send me the SR number? I see what I can do.
    >
    > CU,


  • Am 23.05.2016 um 14:42 schrieb Mary Wood:
    > That is 101007065621


    Ok, forwarded.

    BTW, I tested it myself, I can easily duplicate the issue here, so it
    *is* simply a little cosmetic bug.

    CU,
    --
    Massimo Rosen
    Novell Knowledge Partner
    No emails please!
    http://www.cfc-it.de
  • The tech who took this ticket obviously does not care about my being a
    satisfied customer. In fact, I would say that his responses are just
    about as condescending as one could possibly get away with in
    professional correspondence.


    Anyway, for anyone who wants it, this is SR 101007065621
    and now defect # 983038



    On 5/23/2016 5:31 AM, Massimo Rosen wrote:
    > Mary,
    >
    > Am 23.05.2016 um 12:12 schrieb Mary Wood:
    >> Here's the response I got to an escalation request:

    >
    > And BTW... I guess this is simply a bug. The caching client historically
    > always simply showed a local percentage in the status bar derived from
    > the free local diskspace on the machine. It has done that long before
    > you even *could* apply a size limit to the caching mode.
    >
    > Now here comes the feature that adds the "real" size limit to the
    > caching mode too. Obviously they simply forgot to also change the
    > display in the status bar and how it's calculated at the same time.
    >
    > The answer of the tech however is.....
    >
    > CU,