Hi, Scenario: Server: Exchange 2003 Ent Clients: Outlook 2003 We are having problems with the Exchange and we think they are related with the size of attachments that the users are sending. Unfortunately we can't limit the size of the attachments that are being sent (political reasons) but I may be able to change this if I can get a way to prove that the size of the attachments that are being sent on the daily basis are way bigger than normal. So basically is there any way to create a report that shows the emails and their size (including attachments). Or any way to enable a log that will keep track of this and show what we want to get?

The message tracking logs are the source data. Trouble is that you need to purchase an application (there are many still around for legacy Exchange versions) to get the information. Promodag is one such solution. Rather than focus on doing something about large attachments when such attachments could be legitimate, can you share any information about what is happening with Exchange? "post" wrote in message news:9e99b390-8257-4bb4-8500-50741492f019... Hi, Scenario: Server: Exchange 2003 Ent Clients: Outlook 2003 We are having problems with the Exchange and we think they are related with the size of attachments that the users are sending. Unfortunately we can't limit the size of the attachments that are being sent (political reasons) but I may be able to change this if I can get a way to prove that the size of the attachments that are being sent on the daily basis are way bigger than normal. So basically is there any way to create a report that shows the emails and their size (including attachments). Or any way to enable a log that will keep track of this and show what we want to get? Mark Arnold, Exchange MVP.

I though I may be able to enable message tracking on the ServerName > Properties. Also, enable subject tracking. Then copy the log files created to another location, and open with Excel.. (Tab delimited..) Sort by size. Note that it has multiple entries for an email - look at he event ID column to determine real number. I have then to be able to see the largest attachments. What is going on is that we have no limit and the huge files are killing the server. In the past someone sent about 400 MB...we are now back to the point where we are having the same type of issues and I think they are related to the size of the attachments.

So you deliberately took off the 10MB limit. Maybe some education is in order about sending 400MB attachments. Its not that your technology is the problem; the users are. Those log files are not meant for reading in the raw. The ISVs invest a lot of money in packages that interpret and report on those logs. If all you had to do was to open them in Excel and get a plain-English answer to what you needed theyd never have got a product to market.... "post" wrote in message news:c058d448-55b5-495d-8bc5-e45dbac703fb... I though I may be able to enable message tracking on the ServerName > Properties. Also, enable subject tracking. Then copy the log files created to another location, and open with Excel.. (Tab delimited..) Sort by size. Note that it has multiple entries for an email - look at he event ID column to determine real number. I have then to be able to see the largest attachments. What is going on is that we have no limit and the huge files are killing the server. In the past someone sent about 400 MB...we are now back to the point where we are having the same type of issues and I think they are related to the size of the attachments. Mark Arnold, Exchange MVP.

Evidently in my case the problem are the users also unfortunately I inherited an Exchange env. for which for political reasons a limit can not be set. The bottom line is that I need to find a way to prove that the messages that are being sent through Exchange contain really large attachments that are causing the server to perform poorly. I need to find a way to be able to report about this. Unfortunately I haven't been able to set limits and I need to show evidence that some of our current issues with the server performance are related to the size of the mail that is being processed. Would we be able to read the logs that I mentioned before with Promodag? If not, how should I be using Promodag in order to get to the information that I want. Also we are planning to move to Exchange 2010. Would Promodag be useful in Exchange 2010 or does MS have covered the use of Promodag with native tools? Finally does Exchange 2010 offer any tools that could help us out to get to this type of information? Thank you very much in advance for your time and help.

On Wed, 3 Nov 2010 02:32:25 +0000, post wrote: > > >Evidently in my case the problem are the users also unfortunately I inherited an Exchange env. for which for political reasons a limit can not be set. > >The bottom line is that I need to find a way to prove that the messages that are being sent through Exchange contain really large attachments that are causing the server to perform poorly. I need to find a way to be able to report about this. The size of the message body that contains the txt will be insignificant in this reporting. The overall size of the messae is what's important to you. You can discount, say, the 1st 10K of the message size as being text. A message that has a 400MB attachment and a message that contains 400MB of text (unlikely) are the same size message. So, report on all message sizes in ranges of MB. 0.0-0.1, 0.1-0.2, 0.2-0.5, 0.5-1, 1-5, 5-10, 10-20,20-50, 50-100, etc. Anything above 0.1MB is pretty much guaranteed to have an attachment. >Unfortunately I haven't been able to set limits and I need to show evidence that some of our current issues with the server performance are related to the size of the mail that is being processed. That's not the place to start. Start with gathering information about what's causing the problem. Do you know it's just a bandwidth problem, or is it a problem with too much I/O, foe example. Go get a copy of PAL (http://pal.codeplex.com/) and PerfWiz (http://blogs.technet.com/b/mikelag/archive/2009/02/02/updated-exchange-2003-perfwiz.aspx). Gather permon trace logs during the busy part of the day and run them through PAL. Does anything jump out at you? Can you fix it without reducing message volume -- more disks, maybe? More CPU? If you must deal with huge message sizes, scale your infrastructure to deal with that, don't try to fight a battle you can't win. If it takes a 20-spindle RAID10 array to handle the I/O load, then you'll have the data to back you up. If it takes a network with bigger pipes, you'll have the data to back you up. If there's no money to be spent to improve the infrastructure then the consequences will be pretty clear -- poor performance. >Would we be able to read the logs that I mentioned before with Promodag? If not, how should I be using Promodag in order to get to the information that I want. Right now I think you're trying to turn a hypothesis into a theory and then try to prove the theory. Why not start by getting the facts first? Right now you don't even know what the problem is you're trying to solve. If you win you fight to enforce stricter message size limits and it doesn't improve performance, what then? You've lost credibility and you're not going get to guess again. :-) --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP

Thanks both for you help. I have ran MS Exchange Best Practices Analyzer and I have found the following critical problems: 1.) SystemPages set too high 2.) HeapDeCommitFreeBlock Threshold not set 3.) Physical memory configuration We have been getting getting yellow pop-up messages with the following messages Outlook is trying to retrieve data from the Microsoft Exchange server "thanameofthecluster.domain.local" The users can't do anything because Outlook freeze ups then eventually they go away... Initially I though it may have something to do with size of attachments because when we had the problem before we got the same type of message. Doing further research in the event viewer I have found Source: MSEXchangeIS Event ID: 9665 Description: The memory settings for this server are not optimal for Exchange I have checked network bandwidth and I/O on the SAN and they are fine. We have over 1 to 1.5 GB of SMTP traffic outbound traffic. Do you guys have any suggestions?

Until you implement some message size limits you are guaranteed to get that popup message. The message generally occurs (given what you have told us about your environment) because there are insufficient spindles allocated for logs to allow the Exchange server to dump what it has in memory out to a log disk. Ignore for a moment the log file commit to the database, youre not at that point. So, fix the message limits one way or another. A 4x2 plank of wood applied swiftly to the back of a users head is a very underrated tool. As for the notifications thrown up by the EXBPA; they all come with suggestions and recommended actions. Take them at the same time as getting the attachment size in order. "post" wrote in message news:82c9b923-e787-4819-bc15-0ca8771b7133... Thanks both for you help. I have ran MS Exchange Best Practices Analyzer and I have found the following critical problems: 1.) SystemPages set too high 2.) HeapDeCommitFreeBlock Threshold not set 3.) Physical memory configuration We have been getting getting yellow pop-up messages with the following messages Outlook is trying to retrieve data from the Microsoft Exchange server "thanameofthecluster.domain.local" The users can't do anything because Outlook freeze ups then eventually they go away... Initially I though it may have something to do with size of attachments because when we had the problem before we got the same type of message. Doing further research in the event viewer I have found Source: MSEXchangeIS Event ID: 9665 Description: The memory settings for this server are not optimal for Exchange I have checked network bandwidth and I/O on the SAN and they are fine. We have over 1 to 1.5 GB of SMTP traffic outbound traffic. Do you guys have any suggestions? Mark Arnold, Exchange MVP.

On Wed, 3 Nov 2010 16:00:36 +0000, post wrote: > > >Thanks both for you help. > >I have ran MS Exchange Best Practices Analyzer and I have found the following critical problems: > >1.) SystemPages set too high > >2.) HeapDeCommitFreeBlock Threshold not set > >3.) Physical memory configuration Make the necessary adjustments. The 1st two are just registry changes. The 3rd one probably means you're running on a machine with more than 1GB of memory and don't have the /3GB and /USERVA stugg in the boot.ini file -- or you have more than 4GB of memory on the machine. >We have been getting getting yellow pop-up messages with the following messages Outlook is trying to retrieve data from the Microsoft Exchange server "thanameofthecluster.domain.local" >The users can't do anything because Outlook freeze ups then eventually they go away... Are they working in Exchange cached-mode? It'll take a while to read a 400MB e-mail, but cached-mode should put some of that into the background. Using Outlook 2007 or 2010 would also help since they've made improvements to the 2003 synchronization methods. >Initially I though it may have something to do with size of attachments because when we had the problem before we got the same type of message. If they're not using cached-mode, or if they are and they're using Outlook 2003, those big messages will tie up Outlook for a while, even if they're using cached-mode. >Doing further research in the event viewer I have found > >Source: MSEXchangeIS > >Event ID: 9665 > >Description: The memory settings for this server are not optimal for Exchange That's what ExBPA told you, too. >I have checked network bandwidth and I/O on the SAN and they are fine. > >We have over 1 to 1.5 GB of SMTP traffic outbound traffic. > >Do you guys have any suggestions? Follow up with PerfWiz and PAL to see what else is going on (after you correct those three things ExBPA pointed out). Just becasue ExBPA says the configuration checks out doesn't mean there aren't other perfromance problems. --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP