|
|
|
UER Store
|
|
order your copy of Access All Areas today!
|
|
|
|
Activity
|
|
839 online
Server Time:
2024-05-03 17:24:52
|
|
|
trent I'm Trent! Get Bent!
Location: Drainwhale hunting Gender: Male Total Likes: 9 likes
Not on UER anymore.
| | | | Re: mail bloat < Reply # 1 on 9/21/2009 12:28 PM > | Reply with Quote
| | | In my experience, it's a delicate balance, but I don't think it's too bad. That's really only 600 MB per user on average...really no *too* bad, especially if the business is very email oriented. I bet you could break that 600 MB down to: 150 MB attachments in inbox/outbox/deleted 150 Inbox 150 Sent 150 Deleted
Of course people should not keep every message, but often (again depending on the business) old emails are very important. Especially in the financial sector. When I worked in a claims department for our company, historic emails were very valuable. Yes, the emails from 2003 are necessary at times. After 5 years in a outlook environment, having a 600MB or less mailbox is almost impossible, and that's after deleting unneeded attachments, personal email, "office-wide spam", etc. It's tough to give your employees a wonderful tool, but then not let them full use it. As being one tasked with monitoring the email box sizes at my old place, a 800 MB quota worked with occasional nasty-grams (coincidentally adding to the problem) at 600MB. The other thing to think about is, say that you go crazy hardcore with a quota, you'll see an increase in other network storage locations (if you use them) with people now saving their attachments and occasional full mailbox back-ups on they personal network path or even on a shared network path. And if you limit that, then they'll print everything costing even more money at the bottom line. You can try to put out the fire, but it will ignite somewhere else. With that said, I'd personally prefer the data in outlook, rather than say having people saving shit on their profile, especially if it's a roaming profile. Then your profile sizes bloat, and logons/logoffs to the network pound the domain controller/file servers around start-up and shutdown time. I've seen profiles so large (like 12+ gigs for a single user) than the harddrive couldn't fit the profile from the network while they're logging in.... So my vote is try not to get in the way of the users until the blurry line in the sand is crossed. Just like the internet is designed to route around censorship and infrastructure damage, your users when hassled will re-reroute their data to other mediums on you.
sorry tl;dr
| He who rules the underground, rules the city above. |
| Sk00maKing
Location: Région de Montréal Gender: Male Total Likes: 0 likes
| | | Re: mail bloat < Reply # 2 on 9/21/2009 5:18 PM > | Reply with Quote
| | | Well i think there's a lot of factors that can play in quota management. First, the storage costs can influence a lot we it's time to implement quotas. If your storage is on some kind of high-perf SAN's well the cost per GB can be pretty impressive ie: HP 450gb fc 15k for eva = 1399$ USD. But if your using some kind of internal / ext JBOD sata hds, well the cost per GB is a lot reduced. Problem with emails, is that ppl don't erase them and don't classify neither... So when you start talking about restricting space panic starts. At my work, since we have lots of users and costly HW, we restrict the exchange mailboxes to 150mb, but all pc's come configured with a pst in outlook. 150 mb is not a lot, but we offer corporate file transfers, inter-offices file transfer systems so we don't have large attachments (size restricted too). When a mailbox quota must be raised, the employee manager must approve the request. So when the managers are aware of the cost per GB, sometimes they think twice and verify the needs. When email is the primary work tool, well that affects the quotas indeed, but starting by showing to ppl how to archive their emails can be a good practice too. Another good practice can be to have shared mailboxes for users in the same department and/or public folders. You could start by configuring exchange to send an automatic mail when the size of a mailbox reaches 90%. That way ppl will call support witch can have them do a little cleanup, and then after if quota still needs to be raised, well at least it would be for a good reason. IMO there's no reason for someone to have their 1999 emails on a server...
| |
| z0th
Location: /dev/urandom Gender: Male Total Likes: 86 likes
On the bleeding edge of cocking things up.
| | | | Re: mail bloat < Reply # 10 on 10/8/2009 2:35 PM > | Reply with Quote
| | | Posted by nostra-YOUPPI! i have 4 TB on the server, but i mean in an office of 12 people im shocked at what people are keeping, these are the people who yelled at me on our old server then PST files bloated up to a gig and complained it was my fault when they got corrupted! | i hear this from admins quite a bit. people have some pretty serious misconceptions about the limitations of residential/business email systems. * Does not have infinite storage capacity! -- email systems are a shared resource. learn to manage your messages! * Is not designed for file transfer. -- never ever transfer large files by email, its unreliable at best. if you have a large file, use FTP/HTTP/SCP. * Has a potential latency of up to five days. -- if you have something that is time sensitive, send it _well_ in advance or use another medium. not all mail systems process things in real time, and there are about a thousand reasons for delays and non-deliveries. and on that note... * Is not the same as instant messaging! -- its just not. dont fill up someones inbox with one word messages. thats just stupid. use msn/icq/jabber/google-chat for short messages. also, Gmail + IMAPs is great AND it integrates with my blackberry storm with the gmail plugin.
| gallery | deviantart | flickr |
| |
This thread is in a public category, and can't be made private. |
|
All content and images copyright © 2002-2024 UER.CA and respective creators. Graphical Design by Crossfire.
To contact webmaster, or click to email with problems or other questions about this site:
UER CONTACT
View Terms of Service |
View Privacy Policy |
Server colocation provided by Beanfield
This page was generated for you in 281 milliseconds. Since June 23, 2002, a total of 740355088 pages have been generated.
|
|