mailbox size 10Gb?

Could you help me to find answer for following question please?

I have customer which policy doesn’t allow deleting any e-mails from mailboxes so they are really huge (top one has 25GB). Currently he has Exchange 2003 and many PST files.

I’m thinking about offering him Exchange 2010 with personal archiving feature and migrate all .pst to database. However I tried to find any document which will tell me what reasonable size of mailbox is. Let say I don’t worry about storage capacity and any security issues.

I found (http://www.mailmeter.com/WhitePapers/E2010-Archiving-Waterford.pdf) that reasonable size of main mailbox is 10GB as well as archive one and it shouldn’t be too much bigger. If it is the case I’m not able to use Exchange 2010 for this company.

Could you advice?

Find more posts tagged with

Free for TechExams community: Cybersecurity salary guide

Compare cert salaries and plan your next career move

Button

Comments

vCole

Why can they not delete emails? Sounds more like they need an email archiving solution...

tiersten

FadeToBright wrote: »

Why can they not delete emails? Sounds more like they need an email archiving solution...

What she said.

Even the draconian rules I have to follow by working in the financial sector doesn't force you to actually store everything in their main PST. You're allowed to archive it off somewhere else.

PiotrIr

Many thanks for your replies.

Regulations and company policy - to keep everything but I never said it has to be in one .pst file.
Yes they need archiving solution and to simplify I want to use Exchange Personal Archiving however I’m not quite sure I should due size limitations.

Claymoore

I don't know how much experience you have designing storage for Exchange, but you can just forget everything you knew when it comes to Exchange 2010.

No more RAID 1/5/10 considerations for logs and DBs - throw it all on one JBOD (RAID 0) array. Use DAGs instead of disks for redundancy.
2 TB mailboxes databases a theoretical limit? - now it's more of a practical limit.
Database backups - who needs them? Just use a lagged DAG copy and have it truncate the logs.
Outlook in online mode vs offline mode - doesn't matter anymore.
Mailbox limits? Not anymore.

I have already led a few 2010 design engagements and I'm getting ready to start my first migration. I have had a hard time accepting the new storage designs because I thought I understood it well from previous versions. Now I show clients that what used to take 78 disk spindles now only takes 28 and there is no reason to put it on the SAN. In fact one of the benefits I have been showing them is they get to reuse their expensive SAN disks for other storage needs.

The last client I worked with used 10 GB as a limit for managers with 2 GB for everyone else. The next client I meet with has 50 GB mailboxes already and they want to move to 2010 for archiving and even higher limits. When MS completes the conversion of their hosted Exchange service to 2010 this summer, the default mailbox size will be 25 GB. Don't worry so much about mailbox sizes on the Exchange server, you should make sure they have enough local disk space to host the offline mailbox. If they don't, the good news is you can run them in online mode and, because of the MAPI-in-the-Middle-Tier design of 2010, there is no performance hit on the Exchange server - great news for those of you with large Citrix implementations.

Spend some time over on the Exchange Team blog and definitely work through the new Exchange requirements calculator to see the storage requirement differences in Exchange 2010.

You Had Me At EHLO...
You Had Me At EHLO... : Exchange 2010 Mailbox Server Role Requirements Calculator Updated to Version 3.5

tiersten

Claymoore wrote: »

No more RAID 1/5/10 considerations for logs and DBs - throw it all on one JBOD (RAID 0) array.

JBOD isn't RAID 0. The two are different in operation. RAID 0 would be striping your data across all the drives. JBOD would be concatenating the data across your drives so once drive 1 fills up, it'd start using drive 2 and then drive 3 etc... or literally a bunch of independant drives.

PiotrIr

It is great news for me. Thanks for the reply.

Why Microsoft recommends 10GB limit is you can use 100GB? Doesn’t make any sense…
About this RAID 0 I understand that you are joking

If you have RAID build using 10xHDD and one of them fails (probably is very high) – whole server will be down. I know that DAG will take care about this – but any way – system has to fail and you need to rebuild it.

I still also not sure about SATA HDDs as customer needs to do messages search over whole database…. Have you seen it in action with huge database? Is it working fine? I saw nice diagrams form Microsoft but…

No backup – fine. My problem is I’m quite conservative. When I was studding to Exchange 2007 exam in training kit was story about company which used only replication for backup. This company doesn’t exist anymore! The problem is that if you don’t have backup like tape, somebody who will get access to your system or even administrator, can destroy database. If you have backup, kept offline you always have something for restoring.

I realize that it is extremely default to take backup of 1TB file but….

Claymoore

tiersten wrote: »

JBOD isn't RAID 0. The two are different in operation. RAID 0 would be striping your data across all the drives. JBOD would be concatenating the data across your drives so once drive 1 fills up, it'd start using drive 2 and then drive 3 etc... or literally a bunch of independant drives.

Very true. It's never really clear whether the Exchange team means a true concantenated JBOD or a stripe array, but I am going with the assumption that it is a RAID 0 for performance. I worked with a client once whose outsourced SAN management folks accidentally created a concantenated disk array and we spent a few days trying to figure out why some disk intensive operations were so slow. When you have a large group of virtual servers all sharing one disk spindle, things tend to slow down.

Claymoore

PiotrIr wrote: »

It is great news for me. Thanks for the reply.

Why Microsoft recommends 10GB limit is you can use 100GB? Doesn’t make any sense…
About this RAID 0 I understand that you are joking If you have RAID build using 10xHDD and one of them fails (probably is very high) – whole server will be down. I know that DAG will take care about this – but any way – system has to fail and you need to rebuild it.

I'm not joking. Yes, if you lose one disk you lose the array but that is why you have multiple database copies in the DAG. You really need to understand the concept of Mean Time Between Failures (MTBF) to build enough redundancy into your DAG. Essentially disks do 3 things - read, write, and break. If the MTBF is 10 years and you have 10 disks, you can count on one of them failing per year.

Rebuilding an Exchange server isn't that bad. Reseeding the database can take some time, but 2010 includes the ability to do an incremental resync from an offline copy of the database. Not only can you reseed from a passive copy, you can copy the database to a USB drive, ship it to the other datacenter, copy the DB to the rebuilt server, and let it sync up the last couple of dayse worth of log files instead of the entire database over the WAN

Understanding High Availability and Site Resilience: Exchange 2010 Help

I still also not sure about SATA HDDs as customer needs to do messages search over whole database…. Have you seen it in action with huge database? Is it working fine? I saw nice diagrams form Microsoft but…

2010 indexes the database for faster searches, a feature that didn't work well (if at all) in 2003.

No backup – fine. My problem is I’m quite conservative. When I was studding to Exchange 2007 exam in training kit was story about company which used only replication for backup. This company doesn’t exist anymore! The problem is that if you don’t have backup like tape, somebody who will get access to your system or even administrator, can destroy database. If you have backup, kept offline you always have something for restoring.

I realize that it is extremely default to take backup of 1TB file but….

I like having tapes as well. A list of reasons why you would still want to use a backup product for Exchange 2010 DAGs is available over on the DPM blog. If you are worried about squeezing 1 TB of data into your backup window, keep in mind that you can back up a passive copy of the database (for performance or scheduling reasons) or you can do a disk-to-disk and then a disk-to-tape backup at a later time.

PiotrIr

Sounds really good.

What about synchronization lag? When you lose your database I presume you will lose some data or I’m wrong?

Once again, thanks for your reply.

Claymoore

PiotrIr wrote: »

Sounds really good.

What about synchronization lag? When you lose your database I presume you will lose some data or I’m wrong?

Once again, thanks for your reply.

One of the reasons the transaction logs were changed from 5 MB in 2003 to 1 MB in 2007/2010 was to reduce the possible amount of data loss in the currently open log during a database failover. On top of that there are other technologies used to protect the data in a highly available environment.

New in 2010, Shadow Redundancy protects messages that are in transit and may not have been delivered to the mailbox or next transport server.

The Transport Dumpster keeps a copy of recently deleivered messages in case they need to be resubmitted to a newly activated database copy.

The AutoDatabaseMountDial setting of the Set-MailboxServer cmdlet is used to set your tolerance for lost log data in the event a database failure (a manual switchover should be lossless).

Another concern would be the queued logs waiting to be copied to the remote datacenter over a slow WAN link. The 2010 requirements calculator allows you to estimate the peak replication needs which, along with a lost log tolerance setting, will estimate the bandwidth needed for replication.

PiotrIr

Once again,

Many thanks for your reply it realy gave me a lot of information. It looks Exchange 2010 is amazing.