Removing Symantec Mail Security for Microsoft Exchange 6.5 (SMSMSE) for Microsoft Exchange 2010/2007 after Add or Remove Programs does not work
Manual removal script for Symantec Mail Security for Exchange (SMSMSE) for all versions
When scanning documents through a copier to email, the created emails with the PDF attachments are going to built-in Junk Folder. On the Exchange server I ran the following command in the Exchange powershell Get-OrganizationConfig and look for SCLJunkThreshold this should be set to higher the SCL value the scanned email is coming in as.
The email’s in the Junk Folder had an SCL value of 5, so I ran the following command to change the SCLJunkThreshold.
Set-OrganizationConfig -SCLJunkThreshold 6
Run another Get-OrganizationConfig and confirm the changes took effect.
I needed to gather IOPS information for a Exchange 2010 deployment.
Open Exchange Server Performance Monitor on database server through Exchange Management Console, Toolbox.
Click the + to add counters for the following:
C: D: E:
It should look something like this:
I have been monitoring our Exchange servers on a daily basis for a few weeks, just making it part of my daily monitoring. I have been using the Exchange Server Performance Monitor. On the Mailbox server I have noticed that the Pages/sec has been spiking quite a lot, up to 300 at times. It is averaging about 50. Normally when counters start spiking, something isnt right so i started to look into the counter a little bit to see if i could pin point where the issue was. Since i know paging deals with RAM, this narrows it down quite a bit.
- Pages/sec—The values of this counter should range from 5 to 20. Values consistently higher than 10 are indicative of potential performance problems, whereas values consistently higher than 20 might cause noticeable and significant performance hits. The trend of these values is impacted by the amount of physical memory installed in the server.
- Page Faults/sec—This counter, together with the Memory—Cache Faults/sec and Memory—Transition Faults/sec counters, can provide valuable information about page faults that are not committed to disk. They were not committed to disk because the memory manager allocated those pages to a standby list. Most systems today can handle a large number of page faults, but it is important to correlate these numbers with the Pages/sec counter as well to determine whether Exchange Server is configured with enough memory.
I did some Google searching to try and get some guidelines to go off of as to where these counters should be, and the definitions above seem to be what i was looking for. Based on those numbers there is clearly an issue. Next I opened up Resource Monitor on the Mailbox Server and started watching the Memory. I was actually get some page faults also. Here are some screenshots.
I noticed that physical memory usage was 83% this seemed a little high, but was it causing the issue i was seeing with a lot of page spikes and page faults? I have done some reading on excessive paging in Exchange 2010 and believe the best spot to start off is by increasing the amount of RAM in our mailbox server from 10GB to 16GB. I will update next week with the outcome.
UPDATE: Since adding an additional 6GB of RAM to the mailbox server, pages/sec have dropped from about 50 pages/sec on average to about 10 pages/sec average. According to documentation the acceptable range is 5-20 so I will leave it at 16GB for now, and continue to monitor into the future.
MSExchangeTransport Queues(_total)Retry Remote Delivery Queue Length
-Shows the number of messages in a retry state in the remote delivery queues.
-Shouldn’t exceed 100. We recommend that you check the next hop to determine the causes for queuing.
In my daily monitoring of our Exchange 2010 servers, I glance at the Exchange Server Performance Monitor on both our CAS/HUB server, and the MBX server. This allows me to see any abnormal activity pretty easily with lines on a graph. If there are high spikes, or sustained heightened activity, I will usually investigate. Since ive been working with Exchange I have noticed there are always a substantial amount of messages stuck in the Retry Remote Delivery Queue Length. When I go into Queue Viewer and click the messages tab, I can view all of the messages that are causing the large queue size. Normally this is between 30 and 100 messages. These messages are addressed to recipients that do not exist in our organization with the error 400 4.4.7 Message Delayed, and keep retrying.
So what is causing these queued messages?