In this article, Microsoft Exchange MVP and author Pat Richard discusses moving the queue database in Exchange 2007 to help avoid back pressure. As Pat explains, back pressure can cause mail flow to stop. Moving the database can increase server stability and keep that help desk phone from ringing. Check it out!
Get unlimited access to TrainSignal's entire IT library, certification practice exams & more!
With TrainSignal, you’ll be able to take practice exams for some of the most popular IT certifications, including CompTIA A+, CompTIA Network+, Cisco CCNA, Microsoft MCSE and the VMware VCP exam.
What is back pressure?
One problem that many administrators run into after successfully transitioning to Exchange 2007 is back pressure. Back pressure is a feature built into the transport roles (hub and edge) in Exchange 2007 that helps deal with available resources for the transport queue database. As part of the monitoring, Exchange keeps a watchful eye over some resources including free space on the drives holding both the message queue database and its related tracking logs; the number of uncommitted message queue transactions in memory, and the memory used by both the EdgeTransport.exe as well as all other processes.
The queue database has three thresholds; normal, medium, and high. Normal means just what it implies – all monitored resources are within normal tolerances. Medium means that the resources are a little above normal. As part of the Medium level, internal messages continue to flow fine, but messages and connections from external sources can be rejected. When the High level is reached, the full force of back pressure kicks in, and all message flow stops. Connections and messages are rejected by the server. You’ll also start to see event 15002 and 1009 messages in your application event log, such as those shown below:
Event Type: Warning Event Source: MSExchangeTransport Event Category: ResourceManager Event ID: 15002 Date: 8/10/2008 Time: 11:38:19 PM User: N/A Computer: SH-EMAIL2 Description: The resource pressure is constant at High. Statistics: Queue database and disk space ("C:\Program Files\Microsoft\Exchange Server\TransportRoles\data\Queue\mail.que") = 75% [High] [Normal=70% MediumHigh=72% High=74%] Queue database logging disk space ("C:\Program Files\Microsoft\Exchange Server\TransportRoles\data\Queue'") = 76% [Normal] [Normal=92% MediumHigh=94% High=96%] Version buckets = 1 [Normal] [Normal=40 MediumHigh=60 High=100] Private bytes = 14% [Normal] [Normal=71% MediumHigh=73% High=75%] Physical memory load = 52% [limit is 94% to start dehydrating messages.] Inbound mail submission from other Hub Transport servers, the Internet, the Pickup directory, the Replay directory, and the Mailbox server, if it is on a Hub Transport server, has stopped. Loading of e-mail from the queuing database, if available, continues. <hr /> Event Type: Warning Event Source: MSExchangeMailSubmission Event Category: MSExchangeMailSubmission Event ID: 1009 Date: 08/10/2008 Time: 11:38:19 PM User: N/A Computer: SH-EMAIL2
Description: The Microsoft Exchange Mail Submission service is currently unable to contact any Hub Transport servers in the local Active Directory site. The servers may be too busy to accept new connections at this time.
Generally, once the thresholds drop down, message flow is restored. The availability of various services based on resource level is shown in Table 1.
Table 1: Resource level and service availabilities
The exact formulas used to determine back pressure are based on drive sizes and other parameters depending on whether the server is running the RTM or Service Pack 1 version of Exchange 2007. For more info on the formulas, as well as an in depth look at back pressure, see this article in the Microsoft TechNet Library.
Moving the queue database
So let’s take a look at how best to resolve the problem. The default location for the queue database and its related files is C:\Program Files\Microsoft\Exchange Server\TransportRoles\data\Queue. As you can guess, keeping these files on the system drive probably isn’t a good long term plan. As message activity increases, the back pressure problem could become more severe. So let’s look into moving them.
- Free space is checked on the destination drive for the Queue Database and Queue Database Logs
- Create the destination path for the Queue Database and Queue Database Logs
- Assign Full Control permissions for Network Service, Local System, and Administrators for both paths
- Stop the Exchange Transport Service
- Backup the original EdgeTransport.exe.config file
- Move the Queue Database files, mail.que and trn.chk, to the destination folder
- Update the Queue Database path
- Move the file trn.log and any trn*.log files to the destination folder
- Update the path for Queue Database Logs
- Restart the Transport Service
Note that the PowerShell script does stop the Transport service during the move, so you’ll want to schedule this for a relatively quiet time to minimize disruptions of your messaging system. And obviously, this is a per server setting, so if you’re using more than one transport server, you’ll want to address this on each.
As with any change to your messaging environment, ensure you have a full backup before proceeding. Once you’ve determined where you’re going to move the files to, open the Exchange Management Shell (EMS), and invoke the Move-TransportDatabase.ps1 script, specifying the new QueueDatabasePath and QueueDatabaseLoggingPath variables, such as this:
Move-TransportDatabase.ps1 -QueueDatabasePath: D:\Exchsrvr\TransportRoles\data\Queue -QueueDatabaseLoggingPath: D:\Exchsrvr\TransportRoles\data\Queue
In the above example, I’m moving both the database and log files to the D:\Exchsrvr\TransportRoles\data\Queue folder.
As we can see in the Figure 1, the script goes through each step of the process, and tells us at the end that the script executed successfully.
When we look in the destination location, we can see the database and its files are now there, as seen in Figure 2.
The Move-TransportDatabase.ps1 script does a MOVE of the files, so they no longer exist in their original location. The script runs very quickly, and in this example running on an old server, took about 15 seconds to run.
By moving the message queue database and the database logs to a larger volume, we can provide better stability for our Exchange environment. By using the PowerShell script in SP1, this optimization tweak is both quick and painless. For a more in depth look at the queue database, see this section of the Microsoft TechNet Library or see our recent Exchange forum threads below.
Got a question? Post it on our Exchange Server Forums!