If you have browsed the folder structure that is created after the installation of Exchange 2007, you may have noticed a folder called Pickup that is tucked away several folders below the root Exchange folder. This folder has also been present in legacy versions of Exchange and so it’s something that you may well have used in the past. One common use of this folder is to test mail flow without the need to use a messaging client. This is achieved by copying properly formatted text files into the pickup folder; Exchange will then process and deliver them as normal. In this article, we’ll take a look at the pickup folder and how it can be used to test mail flow within your Exchange infrastructure.
Pickup Folder Configuration
The pickup folder doesn’t necessarily exist on every single Exchange 2007 server that is installed. It actually only exists on an Exchange 2007 server that runs either the Hub Transport role or the Edge Transport role. By default, the pickup folder is found in the \Program Files\Microsoft\Exchange Server\TransportRoles folder on the drive that you installed Exchange onto, as shown in Figure 1.
Figure 1: Default Pickup Folder Location
Since the configuration of the pickup folder isn’t something that you are likely to do on a day-to-day basis, you can probably guess that the pickup folder is configured via the Exchange Management Shell only. The cmdlet that you can use to examine the settings of the pickup folder is the Get-TransportServer cmdlet. However, if you pipe the results of the Get-TransportServer cmdlet into the format-list cmdlet, you’ll see that there are many transport server attributes returned and thus finding the specific pickup folder attributes isn’t easy. The best thing to do here is to filter the results to look for attributes that start with the string pickup and so the cmdlet to use to do this is:
Get-TransportServer | fl pickup*
You can see the results of this cmdlet in Figure 2.
Figure 2: Pickup Folder Attributes
One thing to note with this cmdlet is that the server I’m running it against has the Hub Transport role installed, so I did not need to reference the server name in this example. It’s important to remember that if you need to run this cmdlet against a remote server, specify that server name using the –Identity parameter. Also, you’ll need to use the –Identity parameter when using the Set-TransportServer cmdlet to modify the configuration of the pickup folder as we’ll see next.
Let’s look at each of the attributes in Figure 2 in turn and discuss what they do, although the names of the attributes should make things fairly self-explanatory. First, the PickupDirectoryMaxHeaderSize attribute is used to configure the maximum size of a message header that the Exchange 2007 Hub Transport or Edge Transport server will accept. By default, this is set to 64KB and should therefore suffice for most needs. If you do need to change this value however, you can use the following cmdlet:
Set-TransportServer –Identity {server name} –PickupDirectoryMaxHeaderSize {value}
The parameter {value} can be expressed in anything from bytes up to gigabytes using string values such as 128KB or 1MB.
Next, the PickupDirectoryMaxMessagesPerMinute attribute specifies how fast the server can process messages from the pickup folder and has a default setting of 100. This default configuration will suffice for all message flow testing needs, but if you were to write an application that placed more than 100 messages per minute into the pickup folder, you’d need to modify this value. Of course, it would then be important to test such a configuration to make sure that the rate of message flow didn’t adversely affect overall system performance.
You can also limit the number of recipients per message applied to the pickup folder via the PickupDirectoryMaxRecipientsPerMessage attribute. The default value is 100. If you have configured your Exchange 2007 organization such that users can only send a message to a specific maximum number of recipients in order to ensure satisfactory system performance, it may be worth considering setting the pickup folder to match this value. For example, if you wish to set the maximum number of recipients of a message submitted to the pickup folder to 500, you’d use the following cmdlet:
Set-TransportServer –Identity {server name} –PickupDirectoryMaxRecipientsPerMessage 500
Finally, you can change the location of the pickup folder by modifying the PickupDirectoryPath attribute. For example, perhaps you’ve implemented a dedicated disk array on your Hub Transport server to handle your database queues and you wish this dedicated array to also handle your pickup folder amongst other things. I personally like to ensure that the default full path is maintained when moving folder locations onto different disk arrays. For example, if I was moving the pickup folder to drive E: I’d ensure that the pickup folder location was set into the E:\Program Files\Microsoft\Exchange Server\TransportRoles folder via the following cmdlet:
Set-TransportServer –Identity {server name} –PickupDirectoryPath “E:\Program Files\Microsoft\Exchange Server\TransportRoles\Pickup”
You might be wondering at this point as to whether the pickup folder can be used for nefarious purposes, such as sending unwanted messages for example. This would most likely be performed by someone inside your organization. The answer to that question is yes and so this folder should be protected accordingly. If you’re confident that you do not need the functionality of the pickup folder, you can disable it by specifying the pickup folder path as $null, as shown in the following cmdlet:
Set-TransportServer –Identity {server name} –PickupDirectoryPath $null
Remember, the pickup folder is enabled by default on all Exchange 2007 servers configured with the Hub Transport or Edge Transport roles.
Sending Messages
Now that we’ve configured the pickup folder with our required settings, let’s look at how you can go about using it. As I stated earlier in this article, the pickup folder is used to send email messages through the Exchange 2007 system simply by placing the email messages into the pickup folder. The email messages can be created in a simple text editor such as Notepad, saved as a file with a .eml extension and then placed into the pickup folder for processing. The actual message contents must be formatted correctly to be processed. An example of a simple text message is shown below in Figure 3. Note the fact that the filename is message.eml. For Exchange 2007 to process the message correctly, the file has to have a .eml extension.
Figure 3: Sample Mail Message
Let’s look at what happens when the file message.eml is copied to the pickup folder. First, you’ll see the message.eml file listed briefly in the folder before it is renamed to message.tmp as you can see in Figure 4. In my experience, this process occurred within 5 seconds of submission of the file to the folder. Assuming everything is configured correctly with regards to the formatting of the message, Exchange will then process it accordingly. The result will be, hopefully, that the message is delivered to the correct address as you can see from Figure 5. Interestingly, I noted that the .tmp file is locked open and cannot be opened via Notepad; efforts to do so resulted in an Access Denied error message.
Figure 4: Conversion To .TMP File
Figure 5: Delivered Message
These .tmp files are cleaned up automatically by the system on a periodic basis. It seemed logical to me that the Microsoft Exchange Transport service would be responsible for processing messages from the pickup folder so I was curious to know what happened if this service was stopped and restarted before the .tmp files were removed. Interestingly, with a previous .tmp file still existing in the pickup folder, I stopped and restarted the Microsoft Exchange Transport service and noted that any existing .tmp files were removed.
Incorrect Formatting
What happens if a .eml file is badly formatted? In a test, I took the original message.eml file and deleted the first line that specifies the message sender. The result was that instead of renaming the file so that it had a .tmp extension and then delivering the message, Exchange renamed the file with a .bad extension and left the .bad file in the pickup folder as you can see from Figure 6.
Figure 6: Bad Message
Additionally an event log entry was logged in the Application event log as you can see from Figure 7. This has a source of MSExchangeTransport and an event ID of 9010. The description is quite specific in the nature of the problem but it doesn’t specifically state the filename that caused the problem. Having said that, all you need to do is to look for .bad files in the pickup folder and examine them to see why they may be badly formatted.
Figure 7: Bad Message Event Log Entry
Another interesting thing that I noticed was that, unlike the .eml files, once a .bad file existed in the pickup folder, it was not removed after stopping and restarting the Microsoft Exchange Transport service. Clearly, these files must be removed manually so once you see the event ID listed in Figure 7, you know that you must manually intervene to prevent the build-up of unwanted files in this folder. Also, I noted that after the Microsoft Exchange Transport service had been restarted, a fresh copy of the 9010 event ID was not logged in the Application event log until a new occurrence of a bad message was encountered. This has the advantage of preventing false alerts every time the Microsoft Exchange Transport service is restarted.
Summary
The SMTP Pickup folder on an Exchange 2007 Hub Transport or Edge Transport server could be easily overlooked by an administrator that wants to test message flow or is perhaps looking for a simple method to send email messages without an email client. It’s well worth reminding yourself of the existence of this folder and furthermore, if you are security conscious and don’t wish to use it, remember to consider disabling the functionality altogether.
