oeltayeb.com · Exchange Server Troubleshooting Toolkit

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 452 response.
  • 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.

ResourceWhat it measuresTypical 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 logsSame drive, same cause
UsedDiskSpace[...\data]Used space on the drive used for content conversionSame drive, same cause
PrivateBytesMemory used by EdgeTransport.exeVery large queues, a misbehaving agent
SystemMemoryMemory used by all processesUndersized RAM, other software
QueueLength[SubmissionQueue]Messages waiting in the Submission queueMail storm or loop, slow categorization
UsedVersionBuckets[...\mail.que]Uncommitted queue database transactions in memorySlow 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. 1

    Confirm which resource is under pressure

    Run this in the Exchange Management Shell (leave out -Server to 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. 2

    Disk pressure: free space on the right volume

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

    Watch out: Raising the thresholds in EdgeTransport.exe.config only 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. 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 give NETWORK SERVICE, SYSTEM and Administrators Full Control.
    • Back up EdgeTransport.exe.config, then in the <appSettings> section change QueueDatabasePath and QueueDatabaseLoggingPath (and TemporaryStoragePath if content conversion is the resource under pressure).
    • Restart the service: Restart-Service MSExchangeTransport.
    • Confirm that mail.que and 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.

  4. 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. 5

    Submission queue and version buckets

    powershell
    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

  • 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:
powershell
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.

Microsoft Learn references