Large Shared Mailbox

Hello, what do you all recommend to do to deal with a large shared mailbox? When I say large I mean over 100 users connect to and use this mailbox. This mailbox is on Exchange 2003 but we are thinking about moving it over to one of our 2007 boxes. Would moving this mailbox to 2007 help to increase its performance? We are using archive software but this software leaves the "stub" of the email in the mailbox resulting in several thousand total items. We read that with 2003 you can only have up to 15 views cached so anyone who connects to this mailbox after the 15th user, their views will be refreshed thus resulting in a performance hit. Also, does MS have a limit on how mant items a mailbox can have? This mailbox has several thousand total items. What is recommended for this type of scenario?

Thx in advance for your suggestions!

Comments

  • Chivalry1Chivalry1 Member Posts: 569
    Public Folders or SharePoint.
    "The recipe for perpetual ignorance is: be satisfied with your opinions and
    content with your knowledge. " Elbert Hubbard (1856 - 1915)
  • HeroPsychoHeroPsycho Inactive Imported Users Posts: 1,940
    Number of items matter in critical path folders, ie the default Outlook folders (inbox, sent items, deleted items, calendar, etc.) If you use an archiving product, remove the stubs as well for items you know users won't be accessing.
    Good luck to all!
  • ClaymooreClaymoore Member Posts: 1,637
    Some useful information over on the MS Exchange Team blog:

    You Had Me At EHLO... : Finding High Item Count Folders Using the Exchange Management Shell

    You can improve performance by increasing the restricted views limit (instructions are in the technet article linked on the blog) or by archiving items in folders outside the Inbox. The best bet would be to look at public folders or sharepoint as mentioned before. Your archiving product should give you the option of stubbing attachments after a certain date and eventually archiving the entire message after a latter date. A move to 2007 or 2010 would also help as this increases the recommended limits for items in the critical paths folder.
  • joey74055joey74055 Member Posts: 216
    Ok, thanks all for your help!
  • joey74055joey74055 Member Posts: 216
    Ok, moving this mailbox has turned into a problem. The Move-Mailbox and Ex-Merge are not options as this mailbox is over 100GB. Since 2003 and 2007 have different database structures restoring to a rwecovery storage group on the 2007 box is not an option. What can I do to move this beast over to the 2007 box? What would happen if we did an in-place upgrade to the 2003 box to 2007, would it convert the mailbox over to the 2007 format? What other options do I have? Thanks in advance for your help.
  • blargoeblargoe Member Posts: 4,174 ■■■■■■■■■□
    This mailbox is full of stubs and it's still 100GB?!?!?!?!?!?!?!?!?!?!?!? Is there anything you can do to reduce the size of the stubs themselves? In our Enterprise Vault system we limit ours to 512 bytes I think.

    Well, in-place upgrade is not in the picture, since it is not possible to upgrade from 2003 to 2007 because of the difference in processor architecture.

    Does move-mailbox time out on you or something?
    IT guy since 12/00

    Recent: 11/2019 - RHCSA (RHEL 7); 2/2019 - Updated VCP to 6.5 (just a few days before VMware discontinued the re-cert policy...)
    Working on: RHCE/Ansible
    Future: Probably continued Red Hat Immersion, Possibly VCAP Design, or maybe a completely different path. Depends on job demands...
  • joey74055joey74055 Member Posts: 216
    blargoe wrote: »
    This mailbox is full of stubs and it's still 100GB?!?!?!?!?!?!?!?!?!?!?!? Is there anything you can do to reduce the size of the stubs themselves? In our Enterprise Vault system we limit ours to 512 bytes I think.

    Well, in-place upgrade is not in the picture, since it is not possible to upgrade from 2003 to 2007 because of the difference in processor architecture.

    Does move-mailbox time out on you or something?

    YES! It is still that HUGE even after whats archived. The stubs are only 2 kb in size but this thing is so big it is just ridiculous. This thing is nasty and a big pain in the you know what. We haven't even tried move-mailbox because this thing is so big. We figured that the amount of time it would take to move this thing, if it would even work with move-mailbox, would be to long and we can't have this mailbox unaccessible for that amount of time.

    I know that an in-place upgrade is not supported but we are willing to try any thing at this point. We are thinking about using a 64 bit test server, loading exchange 2003 on it, restoring this monster mailbox on it from tape then trying the in-place upgrade just to see what would happen.

    The problem with this scenerio is that the hardware this mailbox is on is very old and we are afraid that it could die at any given time so that is why we want to get this mailbox off of there. We will still have to deal with its size issue but we just need to get it moved over to 2007.
  • blargoeblargoe Member Posts: 4,174 ■■■■■■■■■□
    What is the size of the deleted items if you look at the mailbox in 2003 ESM? What is your deleted item retention? It might be some of the 100GB is dumpster, which wouldn't be migrated in a mailbox move if I remember correctly.
    IT guy since 12/00

    Recent: 11/2019 - RHCSA (RHEL 7); 2/2019 - Updated VCP to 6.5 (just a few days before VMware discontinued the re-cert policy...)
    Working on: RHCE/Ansible
    Future: Probably continued Red Hat Immersion, Possibly VCAP Design, or maybe a completely different path. Depends on job demands...
  • joey74055joey74055 Member Posts: 216
    blargoe wrote: »
    What is the size of the deleted items if you look at the mailbox in 2003 ESM? What is your deleted item retention? It might be some of the 100GB is dumpster, which wouldn't be migrated in a mailbox move if I remember correctly.

    Deleted Items are at 1,012 kb. There is probably many, many duplicate emails in this mailbox that can be cleaned out. Do you know of any software that can scan the mb to find duplicates that I can then remove?
  • HeroPsychoHeroPsycho Inactive Imported Users Posts: 1,940
    joey74055 wrote: »
    I know that an in-place upgrade is not supported but we are willing to try any thing at this point. We are thinking about using a 64 bit test server, loading exchange 2003 on it, restoring this monster mailbox on it from tape then trying the in-place upgrade just to see what would happen.

    Dude, it's not just unsupported. You cannot do it, period. E2K3 will not install in a 64-bit OS. And mechanisms aren't in place to even do an in place upgrade with a test 32-bit version of E2K7 to do an in place upgrade.

    That's simply not a solution.

    Some other thoughts on how to tackle this, and I realize all of these aren't good solutions:

    1. Suck it all into EV, remove the shortcuts, move the mailbox, and unarchive it, and then of course archive it again to put the shortcuts.

    2. Backup the db with a backup utility that supports granular restore like BackupExec, delete everything, move the mailbox, and restore it.

    3. Dismount your dbs, P2V your Exchange server to the new server running a hypervisor such as ESXi or Hyper-V.

    4. Use an imaging product that supports restores to disimilar hardware such as BackupExec System Recovery Server Edition, backup the machine, and restore it on the new hardware.

    Also got to ask the obvious: Why can't you remove the shortcuts and let people access items from the vault instead?
    Good luck to all!
  • HeroPsychoHeroPsycho Inactive Imported Users Posts: 1,940
    joey74055 wrote: »
    Deleted Items are at 1,012 kb. There is probably many, many duplicate emails in this mailbox that can be cleaned out. Do you know of any software that can scan the mb to find duplicates that I can then remove?

    Archive the dang thing with EV!
    Good luck to all!
  • joey74055joey74055 Member Posts: 216
    HeroPsycho wrote: »
    Archive the dang thing with EV!

    We aren't using EV. We are using Archive Manager from Quest and that is half the problem. THis problem runs so slow that the users won't use it because of its performance issues. We are also getting ready to upgrade the Archive Manager Software to the most recent version and connect the server to a SAN. It would be nice to archive this whole thing and it may be all that we can do.
Sign In or Register to comment.