A Practical Look at Migrating From Exchange 2003 to Exchange 2007 (Part 6)

If you would like to read the other parts in this article series please go to:


If you have been following this article series you will know that we ended part five having started the configuration of the Exchange 2007 environment prior to any users being migrated to it. I will save article space by refraining from any in-depth introduction text – let us get straight back into the configuration performed on the system.

Delivery Status Notification Message Sizes

Historically, Exchange has had a useful user feature whereby if a user received a Delivery Status Notification (DSN), the entire original message was sent back to the user. For example, if a user sent a 20MB PowerPoint presentation file to someone external to their organization but misspelled the external email address, Exchange would include the 20MB PowerPoint attachment with the DSN. The idea behind this feature is that the user could then simply use the Send Again button on the DSN, correct the address and send the message on its way. Figure 21 shows this feature.

Figure 21: Send Again Feature in Outlook

This is a nice feature for a user but at the same time it can quickly become an irritation both for the user and the system administrator. If you think about it, the user has a 20MB message in their Sent Items folder already and they now have a 20MB message sat in their Inbox which is affecting their mailbox quota. Additionally, if an archiving system is in use then this 20MB DSN may also be archived. Earlier versions of Exchange sent back the entire message contents along with the DSN but changes were made with Exchange 2003 to limit this to attachments less than 10MB, which is a configuration setting that has been maintained in Exchange 2007. In other words, if the original message that the user sends exceeds 10MB then only the message headers are sent back to the user in the DSN. Additionally, Exchange 2007 allows you to control this size restriction on both internal and external DSNs. This can be effective in controlling overall mailbox sizes and system resources and is something that I regularly configured on Exchange 2003 systems. In fact, it was not uncommon for organizations to set this limit to something small such as 100KB or even to disable the feature entirely.

As I have said Exchange 2007 has this limit set to 10MB by default for both internal and external DSNs. For the project that I was working on, the requirement was to disable the feature altogether. To do this, I had to use the Set-TransportServer cmdlet with the two key parameters being ExternalDsnMaxMessageAttachSize and InternalDsnMaxMessageAttachSize. These parameters can be a numerical value but in my case they were set to 0 which means that only the original message headers were sent back with the DSN. I configured the settings on both Hub Transport servers as well as the Edge Transport server. The cmdlets that I used were:

Set-TransportServer –Identity {server name} –InternalDsnMaxMessageAttachSize 0
Set-TransportServer –Identity {server name} –ExternalDsnMaxMessageAttachSize 0

Running this cmdlet successfully simply returned me back to the command prompt, so I decided to check the configuration by running the Get-TransportServer cmdlet:

Get-TransportServer –Identity {server name} | fl *attach*

This retrieved all parameters from the Get-TransportServer cmdlet that have the string ‘attach’ in their names. For example, consider Figure 22 below which shows the results of this cmdlet run against the local Hub Transport server.

Figure 22: Results of Get-TransportServer cmdlet

SMTP Pickup Folder

Also found on the Hub Transport and Edge Transport server roles is the SMTP Pickup folder. This is often used in Exchange environments to test mail flow by copying formatted text files into this folder which are then processed by Exchange as a normal email message. I have already covered the SMTP Pickup folder in detail here on msexchange.org so I will not be repeating that level of information in this article. What I do want to mention here is mainly a reminder that, in some cases, this functionality can be disabled which was the chosen configuration option for this project. To achieve this, the Set-TransportServer cmdlet was run to set the PickupDirectoryPath attribute to $null.  The cmdlet that was run was therefore:

Set-TransportServer –Identity {server name} –PickupDirectoryPath $null

However, one word of caution before you go ahead and disable this feature. Do check whether any applications in use within your environment are using the SMTP Pickup folder since disabling it could have an adverse affect on those applications.

Transport Dumpster Configuration

Since an Exchange 2007 CCR environment had been installed, additional configuration was required to support this. One important component of a CCR environment is the transport dumpster feature, which helps to combat data loss that can occur during a lossy failover event in the CCR environment. If a lossy failover occurs, the transport dumpster feature allows each Hub Transport server in the same Active Directory site as the CCR environment to re-deliver email messages. By default, the transport dumpster on each Hub Transport server is set to 18MB in size and the recommendation from Microsoft is to set this to 1.5 times the size of the maximum message size permitted within the organization.

Since I had set the maximum message size to 10MB, it followed that I needed to set the transport dumpster size on both Hub Transport servers to 15MB. To do this, I ran the Set-TransportConfig cmdlet, specifying the –MaxDumpsterSizePerStorageGroup parameter. Note that the cmdlet is focused on the overall transport configuration and not the configuration of any single specific Hub Transport server. In other words, making changes via the Set-TransportConfig cmdlet means that the changes apply to the entire Exchange 2007 organization. The cmdlet used was:

Set-TransportConfig –MaxDumpsterSizePerStorageGroup 15MB

It was also important at this time to ensure that the MaxDumpsterTime parameter was configured with the Microsoft recommended value of 7 days, which happens to be the default value. This parameter controls when messages are removed from the dumpster based on the assumption that the value specified by the MaxDumpsterSizePerStorageGroup has not been reached. The idea here is that 7 days should help protect you from a lengthy outage. As I said earlier, the default value is 7 days anyway but I do like to check that this setting is correct. To do this I ran the following cmdlet:

Get-TransportConfig | fl

The results of this cmdlet can be seen in Figure 23.

Figure 23: Checking the MaxDumpsterTime Parameter

CCR Availability Configuration

To finish off this part of the article series, I want to cover a configuration option that can sometimes be overlooked in a CCR environment. Each CCR environment is equipped with a parameter know as the AutoDatabaseMountDial which, as its name suggests, is responsible for determining whether the databases can be automatically mounted by the Exchange Information Store service after a lossy failover scenario. Whether to automatically mount the databases is determined by the administrator who acknowledges how many transaction logs can be lost. There are three settings for AutoDatabaseMountDial:

  • Lossless. This setting means that no logs at all should be lost. What this essentially means is that, after the failure of the active node, the newly active node will require that the failed node comes back online with all required transaction logs available for copying. Once this has happened, the databases will automatically mount, ensuring no data loss.
  • Good Availability. With this setting, up to three transaction logs can be lost in which case the databases will still mount automatically.
  • Best Availability. This is the default setting and allows for the loss of up to six transaction logs.

It is important when designing any CCR environment to think about the AutoDatabaseMountDialSettings and how this affects your overall service, in particular your Service Level Agreements (SLAs) for Exchange. In my case, the decision was to leave this configuration option at the default setting of Best Availability, since it was deemed that high availability was important to the business. I then checked the configuration via the Get-MailboxServer cmdlet. For example, look at Figure 24 where you can see that this cmdlet has been run against the local mailbox server and filtered to only show attributes containing the string auto. You can see that in this example the setting has been changed to Lossless.

Figure 24: Checking The AutoDatabaseMountDial Parameter – Exchange Management Shell

Of course, since Exchange 2007 Service Pack 1 came out, this configuration option is also available in the Exchange Management Console. To find it, navigate to the Server Configuration area and select the Mailbox object. Locate your CCR Clustered Mailbox Server (CMS) object, right-click it and choose Properties from the context menu. On the Clustered Mailbox Server tab, select the relevant option from the Auto database mount dial drop-down list. You can see this in Figure 25.

Figure 25: Checking The AutoDatabaseMountDial Parameter – Exchange Management Console


Here in part six of this article series we have continued our look at the configuration of the Exchange 2007 environment, covering some lesser-known configuration issues such as the way to handle attachments that are sent with delivery status notifications. Setting such options can help streamline an Exchange installation and so they’re worth examining to see how the features plan out in your environment. In the next part we will continue to look at the configuration, focusing on areas such as the Client Access Server certificates.

If you would like to read the other parts in this article series please go to:

Leave a Comment

Your email address will not be published.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top