Having many of these below:

Event ID 16028 A forced configuration update for Microsoft.Transport.TransportServerConfiguration has successfully completed.

Followed by this every few hours.

Event ID 15004 Resource Pressure Increased from Medium to High

Version buckets =219

Did not have this issue before CU5 update.  Updated from CU5

Am not using any third party transport scripts.

• Edited by Dynamic Computer Friday, August 08, 2014 7:40 PM

For now, I created a schedule task to reboot the transport service when the back pressure event is logged.

• Edited by Dynamic Computer Wednesday, August 13, 2014 2:00 AM

Hi,

A list of changes that are made to the message queue database is kept in memory until those changes can be committed to a transaction log. Then the list is committed to the message queue database itself. These outstanding message queue database transactions that are kept in memory are known as version buckets. The number of version buckets may increase to unacceptably high levels because of an unexpectedly high volume of incoming messages, spam attacks, problems with the message queue database integrity, or hard drive performance.

For a workaround, I suggest we change three parameters as below:

 

1). Launch to the location on the Exchange 2013 Mailbox server: C:\Program Files\Microsoft\Exchange Server\V15\Bin\EdgeTransport.exe.

2). Open the EdgeTransport.exe.config file with Notepad, find the following parameters and increase the value as:

 

<add key="VersionBucketsHighThreshold" value="400" />

<add key="VersionBucketsMediumThreshold" value="240" />

<add key="VersionBucketsNormalThreshold" value="160" />

 

And these need to be tweaked sometimes pending on how the server is performing, above setting is as your reference.

 

Note: before editing, please copy EdgeTransport.exe.config file to other location as a backup one firstly.

 

Then, please restart Microsoft Exchange Transport Service in services.msc to take the change effective.

 

Meanwhile, to help prevent the Exchange Server resource, I also recommend we configure the message size limits to avoid any large attachments.

For more information about Back Pressure in Exchange 2013, we can refer to this article:

Back Pressure

http://technet.microsoft.com/en-us/library/bb201658(v=exchg.150).aspx

Best Regards,

Tracy Liang

• Marked as answer by Richard KuaiModerator Thursday, August 28, 2014 9:53 AM

We have been struggling with this issue since I believe 2013 SP1. We could barely send a 60MB attachment without "version buckets" back pressure monitoring causing 30 min+ transport delays. After exhausting many other potential causes including extensive performance testing, we tried to replicate the issue on a clean 2013 CU7 in our lab environment (same hardware config as production), but couldn't.  After copying the edgetransport.exe.config from our production server to the lab CU7 lab server, the same backpressure issue appeared.  After copying the out of the box CU7 edgetransport.exe.config to our production server, we are no longer experiencing back pressure issues.

Hope this helps others as this was a fairly difficult one to track down.

Example of an Event log message we had been receiving...

The resource pressure increased from Normal to High.

The following resources are under pressure:
Version buckets = 288 [High] [Normal=80 Medium=120 High=200]

• Proposed as answer by Robi Siers Wednesday, March 18, 2015 6:36 PM

Could you possibly compare the two files so we could see what the differences are? WinMerge could be used for this, and it would be extremely helpful.

Thanks!
James

I second this request - @ErikHawley - would this be possible?

Thanks for the update...this is interesting. It would seem that you're disabling the MONITORING of backpressure; are you certain that's resolving the problem or is it just hiding it?

Thanks,
James

I agree with Endaar.  EricHawley just removed all of the back pressure monitoring settings in the config file so that back pressure is never enabled.  This is unsafe, especially regarding disk space monitoring.