Exchange 2000 slowness with attachments

[gtstangman35]

Hello,

I have Exchange 2000 and it runs great, except sometimes when opening even small attachments it appears to hang Outlook XP for about 30 seconds before actually opening the doc or attachment. I could understand big attachments, but these are sometimes less than 30 k?? Any ideas?

Thanks,
Wes H

 

[clyd3c0]

I am having this same exact issue. Ever since I migrated my company over to exchange 2K from Groupwise, we now have issues with attachments taking forever to open. Especially, excel worksheets. Did you ever find a solution to this? I am at a standstill right now and can't figure this out. Any help would be much appreciated. Thanks.

 

[Niksen]

check out this thread, it could sound as the same problem.

thread858-464716 Nicolai

 

[xmsre]

There can be many reasons; one of the most common is AV scanning. This can be server side, or client side. I belive it's norton that has a com add-in that's notorious for causing this type of hang. You'll want to take a close look at how and where you're scanning.


If the message got there through OWA, POP, or IMAP, you may be seeing the effects of promotion to the edb. Likewise, messages in the edb are promoted to the stm file when accessed via pop, imap, or owa. The default location of the directory used for content conversion, the working directory, is on the C: drive. You can change it to another drive if this is an issue.

If you notice periodic hangs, where all clients hang simultaniously, you are probably seeing log stalls. You can verify this by looking at Database | log record stalls /sec with perfmon. The number should be very close to zero with no peaks. If you see peaks, you are having log stalls. Exchange has 84 512 byte log buffers in RAM by default. When the buffers fill to the highwater mark [95%], they are flushed to disk. If they cannot be flushed to disk fast enough, you get a log stall. When a log stall occurs, all client IO is halted until the logs can be flushed. Many times, log stalls correlate with peaks in disk queue. When this happens, it's time to look at reconfiguring your disk. Other times, log stalls occur simply because someone is sending large attachments. In this case, you can increase the number og log buffers to 500 using adsiedit.

Another problem happens when there are an excessive number of cached backlinks, searches and/or restrictions. This situation will cause specific mailboxes or folders to respond slowly. Older versions of Blackberry can cause the problem, as well as certain other CDO based applications. Search the MS kb on backlinks, and you'll find the article that deatails how to test for and resolve the problem.

Yet another problem can be an issue with permissions on a public folder or mailbox problem. By this time, I'm sure everyone is familiar with the dead DN or zombie user problem that affects public folders after a migration. Similar issues can occur when the dead DN is on the permissions of a mailbox. Likewise, using utilities like ADClean can result in an inapproprite setting in the MSExchMasterAccountSID [Associated External Account checked for an enabled user] attribute a la Q309222.

If you ever flipped a one-way CA to a two-way CA during the migration process, you may have a malformed SID for the well known entitiy SELF in the MSExchangeMailboxSecurityDescriptor attribute. This can cause all sorts of bizzare permissions problems, as well as percieved slowness to clients.

Bottom line: Try the easy ones first. If you don't get resolution, it's time to open a case with PSS. If you still don't get resolution, well....


John
MOSMWNMTK