Checklist
452 4.3.1 back pressure checklist
Based on the article: 452 4.3.1 Insufficient system resources: Exchange back pressure explained and fixed · 5 min read
When an Exchange server answers 452 4.3.1 Insufficient system resources, transport isn't broken: it is protecting itself with back pressure. In this post I'll show how to find the resource that tripped it, fix the real cause (usually disk space on the queue drive), move the queue database if needed, and prove the server is back to normal. Exchange Server SE, 2019 and 2016 behave the same here.
Symptoms to confirm
- Inbound internet mail stops or slows to a crawl. Your mail gateway, Exchange Online or the remote sender keeps the messages in its queue with a temporary rejection like this:
452 4.3.1 Insufficient system resources (UsedDiskSpace[C:\Program Files\Microsoft\Exchange Server\V15\TransportRoles\data])- The bracketed text names the resource under pressure, so note it. Applications and devices that submit over SMTP get the same
452response. - On the server itself, the Application log (source
MSExchangeTransport, category Resource Manager) records each transition:
Event ID 15004 Resource pressure increased from <previous level> to <current level>.
Event ID 15005 Resource pressure decreased from <previous level> to <current level>.
Event ID 15006 The Microsoft Exchange Transport service is rejecting messages because available
disk space is below the configured threshold.
Event ID 15007 The Microsoft Exchange Transport service is rejecting message submissions because
the service continues to consume more memory than the configured threshold.Likely causes
Back pressure is built into the Microsoft Exchange Transport service on Mailbox and Edge Transport servers.
| Resource | What it measures | Typical trigger |
|---|---|---|
DatabaseUsedSpace[...\data\Queue] | Used space on the drive holding the queue database (mail.que) | System drive filling up |
UsedDiskSpace[...\data\Queue] | Used space on the drive holding the queue transaction logs | Same drive, same cause |
UsedDiskSpace[...\data] | Used space on the drive used for content conversion | Same drive, same cause |
PrivateBytes | Memory used by EdgeTransport.exe | Very large queues, a misbehaving agent |
SystemMemory | Memory used by all processes | Undersized RAM, other software |
QueueLength[SubmissionQueue] | Messages waiting in the Submission queue | Mail storm or loop, slow categorization |
UsedVersionBuckets[...\mail.que] | Uncommitted queue database transactions in memory | Slow disk, message bursts |
- At Medium, Exchange delays (tarpits) or rejects new mail from non-Exchange sources: the internet, applications, and the Pickup and Replay directories. At High, it also refuses mail from other Exchange servers and stops picking up messages from mailbox databases.
- Two details catch people out. The disk thresholds are percentages of the whole volume: on the drive holding the queue logs, Medium starts at 89% used, however many gigabytes are still free.
Checklist
- 1
Confirm which resource is under pressure
Run this in the Exchange Management Shell (leave out
-Serverto query the local server):powershell[xml]$bp = Get-ExchangeDiagnosticInfo -Server EX01 -Process EdgeTransport -Component ResourceThrottling $bp.Diagnostics.Components.ResourceThrottling.ResourceTracker.ResourceMeter Get-WinEvent -FilterHashtable @{LogName='Application'; ProviderName='MSExchangeTransport'; Id=15004,15005,15006,15007} -MaxEvents 10 | Format-List TimeCreated, Id, Message - 2
Disk pressure: free space on the right volume
powershellGet-Volume -DriveLetter C | Format-List DriveLetter, Size, SizeRemaining $config = Join-Path $env:ExchangeInstallPath "Bin\EdgeTransport.exe.config" Select-String -Path $config -Pattern "QueueDatabasePath|QueueDatabaseLoggingPath|TemporaryStoragePath"On most servers everything sits on
C:under%ExchangeInstallPath%TransportRoles\data. Quick, safe wins are old IIS logs inC:\inetpub\logs\LogFiles, older closed log files under%ExchangeInstallPath%Loggingand leftover setup media.Watch out: Raising the thresholds in
EdgeTransport.exe.configonly hides the problem. Microsoft strongly discourages changing the back pressure settings because it can cause poor performance or data loss. Fix the resource instead. - 3
Move the queue database if the drive is too small
If
C:keeps filling up, give transport its own volume. Let the queues empty first (in a multi-server site, drain the server as described in Exchange Server maintenance mode), because Exchange creates a new, empty queue database at the new path and doesn't process messages left in the old one.- Create the target folder, for example
D:\TransportQueue, and giveNETWORK SERVICE,SYSTEMand Administrators Full Control. - Back up
EdgeTransport.exe.config, then in the<appSettings>section changeQueueDatabasePathandQueueDatabaseLoggingPath(andTemporaryStoragePathif content conversion is the resource under pressure). - Restart the service:
Restart-Service MSExchangeTransport. - Confirm that
mail.queand new transaction logs appear in the new folder before you remove the old files.
Tip: Cumulative update setup can replace
EdgeTransport.exe.config. Keep a copy of your changes and re-check the path keys after every CU. - Create the target folder, for example
- 4
Memory pressure (PrivateBytes, SystemMemory, event 15007)
Restarting
MSExchangeTransportreleases a bloatedEdgeTransport.exe(event 15007 itself says a restart may be needed), but find out why it grew: very large queues (Get-Queue), third-party transport agents (Get-TransportAgent) or other memory-hungry software on the server. Run the Exchange Server Health Checker to confirm memory and page file sizing. - 5
Submission queue and version buckets
powershellGet-Queue -Server EX01 | Sort-Object MessageCount -Descending | Select-Object -First 10 Identity, DeliveryType, Status, MessageCount, LastErrorA large
EX01\Submissionqueue usually means a mail storm, a loop or a slow agent. Version bucket pressure points at the queue database disk: check write latency withGet-Counter "\LogicalDisk(*)\Avg. Disk sec/Write"and confirm your antivirus excludes the transport queue folders.
Verify
- Re-run the
Get-ExchangeDiagnosticInfocommand: every resource should be back at Low. - The Application log shows event 15005,
Resource pressure decreased, down to normal. - An SMTP test (Telnet to port 25) gets
250 2.1.0 Sender OKafterMAIL FROMinstead of 452. - Inbound mail is being received again, and the queues on your gateway or in Exchange Online drain:
Get-MessageTrackingLog -Server EX01 -EventId RECEIVE -Start (Get-Date).AddMinutes(-15) | Measure-ObjectPrevent it next time
- Give the transport queue a dedicated volume with headroom, and alert on free space well before 80% used.
- Forward events 15004–15007 from every transport server to your monitoring so you know which server is pushing back.
- Schedule clean-up of IIS and diagnostic logs, and check that mailbox database backups complete.
- Outbound queues stuck for a different reason? See 441 4.4.1 and 421 4.4.2: stuck outbound queues.