Exchange mail.que growing fast until transport stops.

Backpressure requires event ID's 15002 /15006 to be logged

start > run > eventvwr
check under windows logs\application

You can turn off backpressure monitoring
http://exchangepedia.com/2007/03/exchange-server-2007-how-to-turn-off-the-back-pressure-feature-on-transport-servers.html

Open the EdgeTransport.exe.config file
c:\Exchange Server\bin directory using notepad

Add the following key+value pair:
<add key=”EnableResourceMonitoring” value=”false” />
Save file

Restart the Microsoft Exchange Transport Service (MSExchangeTransport):


Explanation of back pressure here
http://www.msexchange.org/articles_tutorials/exchange-server-2007/management-administration/understanding-back-pressure-feature-exchange-server-2007.html

Moving queue database (not required if you are disabling from the step above)
for your ref.
http://www.petri.co.il/back-pressure-moving-queue-database-in-exchange-2007.htm

I have done all that my problem is the mail.que grows so fast regardless of backpressure transport stops. I need to find out why the que is growing at such an alarming rate yet reporting as no messages through the console. Once the que gets over a gig it gets unstable then once it reaches 2 gigs things get very slow.

Question is Why is the que growing and how can i stop it. I have message limits set also.
Why does queue viewer say nothing?

looping email
virus

-identify the user causing it

Download and run Exmon
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=9A49C22E-E0C7-4B7C-ACEF-729D48AF7BC9&displaylang=en

After you find the user causing high cpu spikes
Disable mapi for that user

Set-Casmailbox –Identity <Username> –MapiEnabled $False

Check the guide here on how to troubleshoot this.
http://blogs.technet.com/b/mikelag/archive/2009/07/12/troubleshooting-store-log-database-growth-issues.aspx

I am out for the day.
have a good weekend.

post back here and i will check later tonight / tomorrow morning.

Thanks,
i ran utility. the only ones I see with 100% cpu is "?" which the article says is a problem with the transport but doesnt really give my anything else to go on.

The fact that this runs fine for 20 minutes after a reset tells me that this is indeed a malicious use situation. The reason attempts to display the queue fail is because it is growing faster than the tools used to view the queue can keep up.
Two possibilities:
1) You have an infected machine on your LAN spewing spam through your server. netstat and wireshark can be used to view open and active SMTP connections to your server. Find the offender and kill it.
2) The term "open relay" means that anybody can relay. So while you may not be an *OPEN* relay, your server can still be abused to relay spam if an account password has been discovered, cracked, or otherwise compromised. The server will pass any open-relay tests, because technically it isn't open. Authenticated relay is still allowed by default. Fixing this typf of situation requires resetting user passwords. While other steps could theoretically be taken, you really don't want a user's password out in the wild, even if you could disable authenticated relay. That account/password combo can still be used to abuse your server in other non-spam ways. It is best to solve the problme at the source(the compromised use account() and not try to work around the issue.
-Cliff
 

Well correct me if I am wrong but the queue does display, just says zero messages. I can view queue through console says status ready message count 0. Through the toolbox same thing. Running trend Micro worry free on server and all pc's and nothing is showing there. I will try wireshark and see if anything there,

I can also use message tracker and see messsages flowing through and nothing large, nothing to coincide withe the size of the mail.que or trn.logs...

Check if you have an poisoned messsages... please delete them... stop tranposrt rename the q file and create new transport DB.

No poison messages, Already renamed the que file, couple of times starts runs fine sumtimes for 5 minuttes sometimes for 20 then the mail.que file keeps climbing. I have not doen anything with the temp.db yet, wonder if I should also rename that as well.

you can try to rename the entire folder and create fresh db.
then run Exmon and see the hight rpc request from any perticular IP .. see if thats the internal.... shutdown that machine and see if thats the cause.

I have already tried all that, see previous posts!

New info. Trend services were off while troubleshooting. Turned them back on and immediately went through 20 gigs of space on my c drive. Stopped Transport service and magically it reappeared. Tried again and treeview wont even see where its going to.. WTH is going on here..

Exclude exchange files from in trend.

They are. Even with trend NOT running at all my Mail.que fil grows to a gig in anywhere between 10 and 30 minutes. Queue viewer only says this " Submission (green check) Delivery type Undefined and status ready.

If I stop transport service the only way it will start again is if i delete the queue (I delete the whole folder)

Exmon shows nothing except ? being at 100% cpu time...

Seems like this thread here is very similar.
https://www.experts-exchange.com/questions/24709067/mail-que-file-goes-from-0-to-4-9gig-in-about-40-minutes.html

I have opened up the limites again. Server is the only machne on the network, FYI I can also disconnect the server from the network and the QUEUE BUILDS!

Anyone else have any ideas?
Here is a recap.
Mail.que grows till transport service stops (4gb right now)
Queue viewer shows queue as ready and no messages but What is taking up the 4GB of space?
I delete the queue restart transport mail flows slowly until it gets so large transport stops.
This will happen even when disconnected from the network so Spam virus is not the reason
All exchange built in tools say everything is fine and there isnt any qued mail.
I have moved the que to a different drive.

This question has been classified as abandoned and is being closed as part of the Cleanup Program. See my comment at the end of the question for more details.