I have come across an interesting problem in Microsoft Exchange Server 2010 (it is also typical for Exchange Server 2007 / 2013). From time to time, some users started to complain on the inability to get scans from Multi-Function Devices (MFD) or senders configured to send emails through Client Access Exchange server (CAS). Meanwhile, Outlook users could send and get emails through the server without any troubles.
To diagnose the issue, I tried to send an e-mail using telnet from the command prompt. Since the configuration included two CAS servers joined into CAS Array using NLB, I had to check each server. An e-mail was successfully sent from the first server, but after running the command mail from on the second server returned this error: 452 4.3.1 Insufficient system resources
In the server applications log, the EventID: 15006 from Source: MSExchangeTransport is registered
Queue database logging path (“C:\Program Files\Microsoft\Exchange Server\V14\TransportRoles\data\Queue\”) = 96% [High] [Normal=92% Medium=94% High=96%]
Physical memory load = 90% [limit is 94% to start dehydrating messages.]
The following components are disabled due to back pressure:
Inbound mail submission from Hub Transport servers
Inbound mail submission from the Internet
Mail submission from Pickup directory
Mail submission from Replay directory
Mail submission from Mailbox server
Content aggregation
The following resources are in normal state:
Queue database path (“C:\Program Files\Microsoft\Exchange Server\V14\TransportRoles\data\Queue\mail.que”) = 95% [Normal] [Normal=95% Medium=97% High=99%]
Version buckets = 0 [Normal] [Normal=80 Medium=120 High=200]
Private bytes = 14% [Normal] [Normal=71% Medium=73% High=75%]
Batch Point = 0 [Normal] [Normal=2000 Medium=4000 High=8000]
Submission Queue = 0 [Normal] [Normal=1000 Medium=2000 High=4000]
The cause of the error is the end of free disk space on which the Exchange Hub Transport queues are located. The fact is that Exchange has a special component to monitor available resources — Back Pressure, which is also tracking free space on a disk, where the Exchange Transport Service queues are stored.
When exceeding the threshold limits, Exchange can:
- Medium (90%) threshold — stop receiving mail over SMTP from external senders (MAPI client e-mails are yet processed)
- High (99%) threshold — the mailflow stops to be processed completely
In case of the error, you can:
- Clear your disk from trash
- Disable Back Pressure monitoring (not recommended)
- Migrate transport queues to another disk with the sufficient size
By default, the transport queue is stored on a system disk. After analyzing drive C:\, I have found that the folder containing IIS logs (C:\inetpub\logs\LogFiles\W3SVC1) occupy almost 15 GB of space. As a rule, these logs can just be deleted and enable the scenario of automatic removal of old IIS logs.
If you are not able to free any space, move the folder of Exchange transport queue to another disk.
The path to the folder containing this queue is specified in the configuration file $env:exchangeinstallpath\bin\EdgeTransport.exe.config with the following arguments:
<add key=”QueueDatabasePath” value=”C:\Program Files\Microsoft\Exchange Server\V14\TransportRoles\data\Queue” />
<add key=”QueueDatabaseLoggingPath” value=”C:\Program Files\Microsoft\Exchange Server\V14\TransportRoles\data\Queue” />
It’s enough to specify the new path to the folder of the queue and restart Microsoft Exchange Transport Service (Restart-Service MSExchangeTransport) and Exchange will automatically create them.
1 comment
Thank you for this great tutorial ! Microsoft itself wasn’t able (once again) to display this option during the installation, so one day our ExchangeSrv didn’t work anymore. Moving the Transport-Queue Folder did the job !