0

My corporate email has a quota of 500Mb, which I am constantly hitting. I recently requested to have this increased but it was refused citing the following two reasons:

We have 400 users. If we increased everybody's quota to 1gb - it would: 1) Impact the exchange servers performance - does storage allocation really affect performance? I would have imagined it would only really be affected by number of concurrent users.

2) Would increase restore time to 24+ hours in the event of a server outage.

Are any of these concerns real, and if so, are there alternatives that can be suggested which would allow 400+ users to have mailboxes in excess of 500Mb? This restriction is impacting real work.

John
  • 3
  • 1
  • 1
    Shouldn't these be questions you should be asking your IT dept? Given adequate storage (both GB and IOPS), RAM, and CPU, Exchange should be able to handle this *very* easily. The exchange system I manage has ~8k active users and around 3 TB of mailboxes. As far as exchange goes, that's considered a small install. – EEAA Apr 19 '11 at 01:08
  • 1
    Sounds like your IT Dept. could use an increase in budget ;) – HostBits Apr 19 '11 at 01:12
  • I did ask, but the response they gave is that it's impossible, and would impact performance and restore time in the event of an outage. I was surprised by the response, so came here for a 'second opinion' - and yours is certainly interesting. How many servers do you have to support the setup you described? – John Apr 19 '11 at 01:13
  • 3 servers, well really two. 1 is a front-end client access server, and the other two are mailbox servers, one of which is passive unless a failover is needed. Storage is on our FC-connected SAN, striped across many 15k and 10k disks. – EEAA Apr 19 '11 at 01:32
  • It's likely that your IT dept is being truthful about their current situation. They may be hamstrung with no budget to expand. On old or under-scaled equipment, all of their claims could easily be the case. – EEAA Apr 19 '11 at 01:33
  • 1
    Please read the FAQ. This site is for IT people, not those who simply wish to question what their IT people are telling them. If your IT people are having issues and need help then by all means send them here. – John Gardeniers Apr 19 '11 at 02:07
  • Why vote to close? Seems like a reasonable question to me, and appropriate to the forum. Not sure I like the idea of a user looking for ammo to nail a fellow admin, but that is a different issue. – tomjedrz Apr 19 '11 at 02:07
  • @tomjedrz - it's off topic due to the fact that this is not an IT professional asking the question - he's a *user* of the service. – EEAA Apr 19 '11 at 02:08
  • @JG, @ErikA - Sorry guys, but USER <> SUBJECT. Off topic is about the subject of the question, not the user asking the question. The subject of this question is perfectly in bounds. Heck, it is a better question than many of the questions from IT admins. – tomjedrz Apr 19 '11 at 02:59

3 Answers3

2

The larger the mail-stores, the longer the backups and online-defrags take. Both of these are significantly dependent on storage I/O performance, rather than software performance. From experience, my Exchange 2007 backups were some of my fastest backups, regularly clocking in at very-significant percentages of Gigabit Ethernet speeds.

Also, for a while there I had two Mailbox database servers (also Exchange 2007) that between them supported around ten times the number of users you have. Yes, they did get a bit loaded during peak hours, but only the really observant noticed at all. When we bumped everyone up to 1GB mailboxes we went to 4 DB servers (roughly 1100 users per server) and they kept up just fine. Exchange can scale, and scale well.

Chances are the limitation here are other things:

  • Backup window It takes time to back all that up, and if the backups are taking longer then allowed, then growth isn't going to happen.
  • Space restrictions There simply isn't enough disk space, or the ability to add it, to accommodate such growth.
  • Loading If the hardware is underpowered, it may already be running as fast as it can.

All three of the above are significantly impacted by underlying storage infrastructure. We were able to turn in the above numbers because were running the databases on a SAN-attach disk array with 72, 10K RPM drives running in it. That gave us enough I/O overhead to make CPU loading more of a limiting factor than storage considerations.

Fixing the above bullet points will take money.

sysadmin1138
  • 133,124
  • 18
  • 176
  • 300
  • Apologies to all for coming at this via the wrong channels - but I didn't know of another way a non-admin person could get the benefit of sys admins knowledge. The information I received is excellent, and will certainly help as I am able to offer suggestions as to what can be done. Sincerest thanks to all. – John Apr 19 '11 at 13:56
1

This depends on the version of Exchange you're running, among other things. In 2007 and especially 2010, Exchange has become much less I/O-bound with larger mail databases. Without knowing how your Exchange system is set up (version, number of databases, server count, disk subsystem, etc), it would be impossible to give you a precise answer.

Moreso, this sounds like a political issue between users and an IT department. There's not much we can do to help you there.

Hyppy
  • 15,608
  • 1
  • 38
  • 59
  • Thanks for the answer. I too suspect it may be political, and would like to resolve it for the benefit of the users, armed with some reasonable information (hence the question). From the sounds of it, the claim is not that far off. As for the specific setup, My guess is it is pre-2007, but I have no idea as to the number of servers. Microsoft's own online docs seems to suggest 1 server can handle 5K 'power users' though. – John Apr 19 '11 at 01:08
  • With 2003, the last version before 2007, there is a bit more of a bottleneck in disk I/O for large mailboxes. The number of disks running the database is a key factor in determining the upper limits, but real-world data is necessary to determine if you're even close to capacity on CPU, Memory, I/O, et cetera. Also, there are some limits on database size due to licensing. – Hyppy Apr 19 '11 at 01:18
  • @John .. Microsoft has essentially fixed the scaling issues in the latest Exchange, and server resources (CPU and disk) are way cheaper than they were 5 years ago. – tomjedrz Apr 19 '11 at 02:48
1

The problem is this ... Exchange versions prior to Exchange 2010 have serious issues when the size of a mail store (= group of mailboxes on the server) on a server gets too big. The bigger the data store, the higher the risk of the store getting corrupted, and a corrupt data store = lost email, a day without email service, and an all-nighter for the admin. 150GB to 200GB is a general threshold where this risk gets high.

This is a known problem with known ways to fix. To get bigger (more users and/or bigger mailboxes), either more mail stores need to be setup or more servers setup. Both of those involve administrative pain, substantial expense, and not trivial risk of data corruption. There may also be issues of not enough actual disk space on the server.

Be aware .. the admins do not like not being able to help. They desperately want to add disk to the server, add another server, or upgrade to Exchange 2010. Most likely they aren't being allowed to spend the money. Have you asked the admins why they haven't upgraded to solve this issue? Perhaps they could use some help getting the funding ...

Short term, archive your mailbox to a .PST file (stored on the network), and connect to that PST in Outlook. Then you will have all your mail and won't be fighting with IT.

tomjedrz
  • 5,974
  • 1
  • 16
  • 26
  • [I wouldn't put the live PST on the network.](http://support.microsoft.com/kb/297019) A copy of it, sure - the live one definitely not. – Ben Pilbrow Apr 19 '11 at 10:01
  • Agreed, sort of. I was talking about the .PST containing the archive. Putting it on the network is fine. For Exchange connections, Outlook 2003 (?) and above use an .OST file, and that should be stored locally. – tomjedrz Apr 19 '11 at 13:23