452 4.3.1 Insufficient system resources: Exchange back pressure explained and fixed

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#

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 452 response. If the pressure reaches High, mail between Exchange servers and from mailboxes stops as well, and users see messages waiting in their Outbox.

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.

Why it happens#

Back pressure is built into the Microsoft Exchange Transport service on Mailbox and Edge Transport servers. Every couple of seconds it measures a set of resources and places each one at Low (normal), Medium or High:

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. When version buckets reach High, remote delivery pauses too.

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. And the levels have hysteresis: that resource only returns to normal once usage falls to 80%, so freeing "just enough" space leaves the server stuck at Medium.

How to fix it#

1. Confirm which resource is under pressure#

Run this in the Exchange Management Shell (leave out -Server to query the local server):

[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

The first command lists every monitored resource with its current pressure level; anything above Low is your culprit. The event timestamps show when it started, which often lines up with a migration batch or a failed backup.

2. Disk pressure: free space on the right volume#

Get-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 in C:\inetpub\logs\LogFiles, older closed log files under %ExchangeInstallPath%Logging and leftover setup media. If mailbox database transaction logs share the drive, the fix is a successful full backup. Never delete transaction logs or queue files by hand.

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.

1. Create the target folder, for example D:\TransportQueue, and give NETWORK SERVICE, SYSTEM and Administrators Full Control.
2. Back up EdgeTransport.exe.config, then in the <appSettings> section change QueueDatabasePath and QueueDatabaseLoggingPath (and TemporaryStoragePath if content conversion is the resource under pressure).
3. Restart the service: Restart-Service MSExchangeTransport.
4. Confirm that mail.que and new transaction logs appear in the new folder before you remove the old files.

4. Memory pressure (PrivateBytes, SystemMemory, event 15007)#

Restarting MSExchangeTransport releases a bloated EdgeTransport.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#

Get-Queue -Server EX01 | Sort-Object MessageCount -Descending |
    Select-Object -First 10 Identity, DeliveryType, Status, MessageCount, LastError

A large EX01\Submission queue usually means a mail storm, a loop or a slow agent. Version bucket pressure points at the queue database disk: check write latency with Get-Counter "\LogicalDisk(*)\Avg. Disk sec/Write" and confirm your antivirus excludes the transport queue folders.

Verify the fix#

• Re-run the Get-ExchangeDiagnosticInfo command: 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 OK after MAIL FROM instead 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-Object

Prevent 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.

References#

• Understanding back pressure (Microsoft Learn)