Exchange Queue & ATransaction Logs, Cmdlets, Remote Management, and More

KC Lemson and Nino Bilic

Q Why did you guys lower the transaction log size to 1MB in Microsoft® Exchange Server 2007?

A Well, in Exchange 2007 we have this cool thing called log shipping, which is the technology behind a couple of new features called local continuous replication (LCR) and cluster continuous replication (CCR). When this is enabled on a Storage Group (SG) level, the SG transaction logs get copied from the running production SG to the copy SG. The logs on the copy SG are replayed into the database to keep it up to date. This is obviously a simplified explanation of what is going on, but you get the picture.

The catch is that transaction logs can't be sent to the copy SG unless the log is closed on the production SG. In other words, the e00 log (the current log in the first storage group) can't be sent until it is full, closed, and renamed. Additionally, there are settings to control how many logs behind you can be in this process, as there is a trade-off between availability and performance. (These settings are available by running the Set-MailboxServer cmdlet in the Exchange Management Shell. The help file provides details about the exact parameters needed.)

To make a long story short, we decreased the transaction log size to minimize the amount of data that can be out of sync between two copies of the Storage Group. This comes into play when, let's say, the production database hard drive crashes and you then need to take action to start the SG from the copy. Smaller transaction logs will give you a better chance of less data loss.

This is not to say that we can guarantee you will lose only 1MB of data. Seeing as though these are transaction logs, it is possible that the lost 1MB log file could contain, for instance, a COMMIT transaction for 5MB of data. In that case, you would be missing those 5MBs of data on the copy-even though you might have received five of the logs with data itself, the last log with a little bit of data and that needed COMMIT transaction is essential.

Ultimately, it is up to you to gauge whether this is an acceptable risk given your business needs. A small amount of data loss with a recovery time in only minutes might be perfectly acceptable when compared to the alternative of hours of restore work. We'll be sure to cover more on this subject in the future!

Q Now that the transaction logs are shorter, will we "run out" of transaction logs faster?

A When talking about Exchange, "running out" refers to transaction log names. In Exchange Server 2003, transaction logs are named like this:

E nn fffff.log

The nn is the prefix that changes from SG to SG. Since nn will remain the same during the life of the SG, the number of uniquely named transaction logs that can be created for the storage group is essentially the "fffff" value, which is roughly one million logs (note to self: put pinky to corner of mouth and laugh maniacally). Some of our customers have run into this limit on busy mail servers.

Starting with Exchange Server 2000, we provided a hotfix to display an event in the application log when this limit is approached. (See support.microsoft.com/kb/896001 for more information on this.)

OK, with that out of the way, what happens in Exchange 2007? We just said that the transaction logs went from 5MB (the size in previous versions of Exchange) to 1MB (the size in Exchange 2007). Does that mean it takes just one-fifth of the data to run out of unique transaction log names?

The answer is: no. In Exchange 2007, the name of the transaction log is in this format:

E nn ffffffff.log

Notice that we have "ffffffff" logs to work with, as opposed to just "fffff" in previous versions of Exchange. Because of the internal Extensible Storage Engine (ESE) math, Exchange 2007 cannot create all "ffffffff" logs. Instead it creates "7fffffec" logs, which is still a pretty huge number (convert this from hex to decimal if you don't believe us!)

What does this mean in real life? In real life, it means that with Exchange 2007 you can create about 2048 times more logs than in previous versions of Exchange. Now let's factor in logs being one-fifth the size:

2048 / 5 = 409.6

As you can see, the new log-naming scheme can handle 409 times more data than the old one! And remember, that is per SG, not per server, because each storage group will have a different log file prefix (such as e00, e01, and so on). Did we mention that you can create 50 SGs per server on the Enterprise version of Exchange 2007? We don't think there is too much chance that someone will run out of transaction logs anytime soon!

Q How can I manage my Exchange 2007 servers remotely?

A There are a few options for managing Exchange 2007 servers remotely. First off, you can install the Exchange 2007 management tools onto a separate machine from your Exchange server, as long as that machine is running either the 32-bit or 64-bit version of Windows Server® 2003 Service Pack 1 (SP1) or later, Windows Server 2003 R2, or Windows XP SP2 or later. Note that installing any of the server roles (client access, mailbox, edge, and so on) on 32-bit hardware is not supported in production environments, but is supported for installing the management tools on a 32-bit machine. Also note that as of the initial release of Exchange Server 2007, the management tools are not supported on Windows Vista™.

In some organizations, the IT department creates a single server to be the management server, installing all the necessary management tools for various products on this server. Then the administrators who need to use those tools access the management server via Terminal Server so they can perform remote administration. In other settings, users install the management tools on their own desktops.

From the console or shell you can perform operations on the servers in your organization. In the console, the servers are visible so you can perform operations on any of them remotely. In the shell, many of the tasks support a filtering flag like -server if you want to scope an operation to a single server. There are a few exceptions, however, for commands that must be run locally, such as the Get-NetworkConnectionInfo command.

Q In your last column, you told us how much RAM is recommended for an Exchange 2007 server. What about the page file size?

A In order to prevent potential out-of-virtual-memory errors on Exchange 2007 servers, we recommend the following guidelines for determining the size of your system page file.

If the server has less than 8GB of RAM, then the minimum size of the page file should be the amount of RAM plus 10MB. So if the server has 4GB of RAM, the minimum size would be 4GB plus 10MB. The recommended size of the page file, however, is the amount of RAM multiplied by 1.5. So for the 4GB server, this would be 6GB.

Furthermore, the minimum size for the page file is calculated the same for a server with more than 8GB of RAM-that is, the amount of RAM plus 10MB. However, the recommended size is determined differently. Basically, on a server with more than 8GB of RAM, you should only go to 1.5 times the amount of RAM if you get out-of-virtual-memory errors with smaller page files.

Note that the errors mentioned in this case have nothing to do with virtual memory fragmentation (a problem with Exchange 2000 and Exchange 2003 servers). These are actual pop-up errors logged by the system that say the page file size is being increased or the page file is too small.

Q I would like to learn how to use the Exchange Management Shell, but I have never used a command line to administer my systems before. Where should I start?

A First, let's start with some basics. Each cmdlet in the Exchange Management Shell is comprised of a single verb and a single noun. There are only a handful of verbs that the Exchange Management Shell uses: "Get" is used to retrieve properties of objects, "Set" to change properties on an object, "New" to create new objects, and so on. The nouns of the Exchange Management Shell include many concepts that all Exchange administrators are already familiar with (for example, Mailbox, Contact, Queue, and OWAVirtualDirectory). There are also concepts new to Exchange Server 2007 (such as TransportRule, StorageGroupCopy, and UMAutoAttendant). So in practice, a basic cmdlet will look something like New-Mailbox (which will create a mailbox) or Get-Mailbox (which will retrieve a list of mailboxes in the organization).

Most cmdlets, however, will need more specifics about what exactly you're trying to accomplish. If you want to change a property on a mailbox, for example, you'll need to specify which mailbox and which property. This is done via parameters. If New-Sandwich were a cmdlet, then the parameters might be -NumberOfTomatoSlices 4, -Bread Wheat, and a variety of other similar options that specify in more detail what form you want the sandwich to take (-FlufferNutter $true-ahhhh yum).

Once you understand the verb-noun split, you can use the command-line exposure in the Exchange Management Console (EMC) wizard to familiarize yourself with which cmdlets perform which operations. In the EMC, run through the wizard to create a new user. At the end of the wizard, after the operation completes, you'll see a copy of the command that the wizard ran under the hood (see Figure 1). Pressing Ctrl+C will copy the contents of that dialog so you can paste the cmdlet into Notepad and put together your own simple batch files.

Figure 1** Command-line exposure for creating a new user **(Click the image for a larger view)

If you want to practice using cmdlets (but don't want to cause any damage), a nice trick is to put -WhatIf at the end of the command. When you do this, the system will tell you what it would do by running the command without actually making any changes to the system.

Once you're familiar with the basic cmdlets like *-Mailbox, you will probably want to try out some others. To find more cmdlets, use the Get-ExCommand cmdlet. This will display a list of all the Exchange management cmdlets. (You must do this while running the Exchange Management Shell. Just opening the Microsoft Command Shell or Windows PowerShell™ will not let you perform this or any other Exchange management tasks.) The list is huge, so use wildcard matching to find what you're looking for. For example, Get-ExCommand *database* will return a list of all Exchange cmdlets that have "database" in the name-such as Dismount-Database, Move-DatabasePath, and New-MailboxDatabase.

If you think you know part of the noun you're looking for, you can cycle through the options. For example, you can type Get-Mailbox and then press the Tab key to cycle through all cmdlets with mailbox in the noun of the task name. You can even combine wildcard matching and tab completion. For instance, you can type Get-*Mailbox* and tab through the possible options.

Another simple trick is to use prompting. Each cmdlet has a set of parameters that are required by default-the basic parameters necessary to perform the operation. "Get" cmdlets, such as Get-Mailbox, don't require any parameters. By default, Get-Mailbox will return a list of all mailboxes in the entire organization. (The list will max out at 1000 by default. To change this maximum, you can type Get-Mailbox -ResultSize 2000, for example.) Cmdlets that create or modify objects (like Set or New) will prompt you for the necessary information as to which object you want to create or modify. If you run New-Mailbox, for example, the shell will prompt you one by one for the password, database, name, and so on.

To find out more about the possible parameters on a given cmdlet, use the help system: Help Move-DatabasePath. (You can also just type Move-DatabasePath, Move-DatabasePath -?, and so on-we try to have the bases covered.) The help will give you a description of the cmdlet and a list of the parameters along with the purpose of each. Help can also be accessed with the Get-Help cmdlet. (Doesn't it feel good to just type Get-Help? Don't you wish some people you know could run that cmdlet in the real world?)

Another way to discover possible parameters on a cmdlet is to use tab completion on the parameter names. Type Get-Mailbox -S and press Tab, and you'll cycle through the possible parameters that start with S.

And then, of course, there's the extensive help system. If you don't find what you're looking for offline, don't forget to check the regularly updated help content at go.microsoft.com/fwlink/?linkid=79421 and the quick reference guide at go.microsoft.com/fwlink/?linkid=64647.

All of this will get you started with the Exchange Management Console, but this information barely scratches the surface of the command line's power and flexibility. We'll cover more in future columns.

Q In the Exchange Server 2003 ESM (Exchange System Manager), we could easily see the mailbox size of all users. That feature seems to be gone in Exchange 2007. Is there a way to do this in Exchange 2007?

A In the new Exchange 2007 console, you can get the size of a mailbox on the general property page of the mailbox itself. If you want to see this for multiple users, you have to use the Exchange Management Shell.

If you run Get-MailboxStatistics, you get the data across an entire server (not just a specific database). By default, the size is not shown-you have to run the cmdlet with Format-List to get the size:

get-mailboxstatistics | format-list

It might be even better to choose what you want to see and pipe it to a table. In this example, we get the display name of the mailbox, the total item size, the total deleted item size, and the database the mailbox is on:

Get-MailboxStatistics | Select-Object displayname,totalitemsize, totaldeleteditemsize,databasename | Format-Table

Depending on the information you are looking for, you can use different formatting for the output. In this example, Format-Table happens to work better than Format-List

KC Lemson is a Lead Program Manager on the Exchange Server team. Her ATM PIN number is 0000—don’t spend it all in one place.

Nino Bilic, a Technical Lead, spends his free time collecting $1,000 checks from Bill in thanks for forwarding on his e-mail.

© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; reproduction in part or in whole without permission is prohibited.