• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 328
  • Last Modified:

Question about increasing the Exchange e-mail limit size

We have Exchange 2003 Enterprise server and we send a lot of attachments out that are close to 10 MB and the Managers are asking if we can change the sending and receiving limit to 20 MB.  I have never changed the limit and wanted to ask what the risk is in doing this and if there are any adverse affects?  Any assistance offered would be greatly appreciated.  
0
regsamp
Asked:
regsamp
  • 4
  • 3
  • 2
  • +2
4 Solutions
 
Andres PeralesCommented:
Risk is the delivery and receiving of email in a timely manner, amount of time it would take to do recoveries if you have a failure, and of course the amount of storage space it takes for all that data / information.
0
 
kfarnham67Commented:
There is nothing dangerous in the change itself. How is the load on the server, how large is your WAN pipe, and how much disk space do you have?

Large attachments take longer to send over the WAN and will queue. Mailbox sizes will increase because you are allowing larger flies into people mailboxes. Of course if the message is larger, the server has to work harder to send it.

 If you have plenty of disk space, I say make the change as requested and monitor the server for a while, if you see issues, revert.
0
 
regsampAuthor Commented:
Storage space should be okay but our send and receive time speed always test well so I would hate to worsen that.  If we doubled the limitation, does that generally affect the delivery and receiving time for all e-mail?  
0
Simplify Active Directory Administration

Administration of Active Directory does not have to be hard.  Too often what should be a simple task is made more difficult than it needs to be.The solution?  Hyena from SystemTools Software.  With ease-of-use as well as powerful importing and bulk updating capabilities.

 
Andres PeralesCommented:
yes, you can schedule the larger emails to be delivered later in the day, on the smtp connector, delivery options you can check the box to deliver oversized messages...
0
 
kfarnham67Commented:
All you are doing is allowing your users to send larger emails. That doesn't mean they will constantly be doing it. You are just creating a potential for bandwidth spikes.

To test your theory, set the limit for you and only you to unlimited. Shoot a large attachment out to a personal web account (one that will actually accept such attachments). when you hit send, a queue will be created on the exchange server which you can see in ESM. It will be named after the DOMAIN that you and sending TO. See how long it takes for that message to go.

How many employees do you have? What is your connection to the internet?

Local delivery should not be a problem.
0
 
aissimCommented:
My two cents is don't change it....if you allow 20MB attachments they will certainly send them; as mentioned it will hog bandwidth and bloat the information store. And who knows - pretty soon they might want 40MB attachments....you might be better off sticking to your guns now - versus 6 months from now fighting to get everyone on board to shrink the size limit.

My biggest concern with these types of situations is that when the information store grows out of control and corrupts/crashes; or that sales manager sends out a 20MB powerpoint presentation to 150 people and locks up your network; all these same managers will certainly not shoulder any of the blame and you'll be left cleaning it up.

0
 
regsampAuthor Commented:
We have a T1 and we have about 100 GB of free space now on the Exchange server.  We have about 150 employees and I am just worried that if the e-mail limit size is doubled, we will have our CAD workers sending huge drawings out all of the time and this will hurt performance.  
0
 
bdibeneCommented:
10MB is the standard limit for email attachments for good reason.
 Large attachments bloat Inboxes
Make mailbox corruption more likely,
takes longer to backup and restore,
performs poorer on slower WAN links and via VPN,
takes longer to process through delivery queues,
and is *very likely to be denied by an outside mail server who has a lower attachment size limit*.

This means it costs the company more money in disk capacity on the Exchange server, backup time, backup disk/tape capacity, downtime to restore the large InfoStore in a server loss, and bandwidth costs to transfer that email.  
Users should be using file servers (or at least workstation file shares) to transfer 10MB+ files to other employees and use an FTP site or similar service for external users.

My company just rolled out LeapFile (http://www.leapfile.com/), which has an Outlook plug-in that automatically reads the size of your attachment and if its over a certain size will dynamically copy the large file to a central file server.  It then embeds a URL and user/pass into your email for the recipient retrieve that file from the FTP server.  
0
 
regsampAuthor Commented:
That is what I was thinking too aissim.  
0
 
aissimCommented:
Yep - it's hard to untrain bad habits....and constantly increasing the limit just makes end-users lazy. Teach them other means to share data now and your life will be much easier down the road.
0
 
regsampAuthor Commented:
Leapfrog sounds great.  Thanks for the advice Experts.  
0
 
kfarnham67Commented:
Ok leave the limit alone for everyone. Increase it only for E-Staff. Assuming that's who wants the send the attachments. If it's the entire company, create a file share somewhere and educate people in using links to the file share.

Please don't make that share on your exchange server.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Making Bulk Changes to Active Directory

Watch this video to see how easy it is to make mass changes to Active Directory from an external text file without using complicated scripts.

  • 4
  • 3
  • 2
  • +2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now