When you're optimizing Exchange 2003/2000 servers for performance, one of the first places you look is at your disk configuration. As a rule of thumb, you want to get as many of the following components as possible reading and writing to separate sets of disk spindles (thus reducing contention):
- The operating system
- The Exchange binaries
- Logs (protocol logs, etc.)
- Mailbox/PF databases
- Mailbox/PF database transaction logs (by storage group)
- SMTP queue directories
Under Exchange 2003/2000, the SMTP queues are a set of directories that are by default located on the same disk you installed Exchange to.
Under Exchange 2007, things are a bit different. You still want to minimize contention for disk spindles by moving as many of the above components to separate disks. In most cases, moving these components is quite a bit easier under Exchange 2007. If you follow Microsoft's recommendations and only create one mailbox database per storage group, you end up with a 1:1 relationship between databases and transaction logs. I was able to move the database and transaction logs on a new Exchange 2007 mailbox server with the following two PowerShell commands:
Move-StorageGroupPath `
-Identity "SERVER\First Storage Group" `
-LogFolderPath:"E:\First Storage Group" `
-SystemFolderPath:"E:\First Storage Group" `
-Force
Move-DatabasePath
-Identity "SERVER\First Storage Group\Mailbox Database" `
-EdbFilePath:"F:\First Storage Group\Mailbox Database.edb" `
-Force
Note: PowerShell uses the backtick as its line continuation character. I'm not sure why they couldn't use the underscore and stay consistent with .NET, but now you know.
The -force parameter tells Exchange that yes, I really mean to do this and stop prompting me to verify that I want to move these files, that yes I know I'll be interrupting service to users of this storage group/mailbox, etc. Exchange will automatically dismount the affected databases, move them to their new location, then remount them. Very easy -- much easier than in previous versions of Exchange.
Queues, on the other hand, get a bit trickier. On the brilliant side, queues are now ESE (the database formerly known as Jet) databases instead of directory structures on the filesystem. I'd imagine that this makes the dynamic creation/removal of queues happen a lot more quickly, since you're now serializing all of your I/O, reusing file handles, and avoiding the hassle of having to deal with file/directory metadata. If I could move the queue database as quickly and easily as I can move mailbox databases, my blog post would come to a rapid, joyous conclusion.
Alas. It's a bit more complicated than that.
There is no PowerShell cmdlet to move the queue database; instead, you have to follow these steps:
- Create the target directory and give it the proper permissions. If the parent directory already has the proper permissions, then Exchange will create the actual directory for you.
- Open the >Exchange install directory<\Bin\EdgeTransport.exe.config file (Notepad will work).
- Modify the QueueDatabasePath and/or QueueDatabaseLoggingPath parameters to point to the new location.
- Save and close the file.
- Restart the Microsoft Exchange Transport service.
Don't believe me? You can verify for yourself; the process is outlined in the Exchange 2007 Beta 2 documentation topic How to Change the Location of the Queue Database.
Full kudos to the Exchange team for moving the queues into an ESE database -- but I'm confused why we aren't able to manage that database using the same, simple PowerShell methodolgy. Can anyone shed light on this seemingly incomprehensible design decision?