Exchange Queue & A: Mysterious Attachment Size Increases, Replicating Public Folders, and More

You’ve got questions. We’ve got answers.

QOur organization's messaging infrastructure is based on Exchange Server 2007. We have a relatively strict message-size limit of 12MB set throughout the organization. We have observed a strange behavior that seems to be related to the size of files attached to a message. When sending an e-mail message to an external user with, let's say, an 11MB attachment, the message is delivered to the recipient as expected. But if this message (including the attachment) is forwarded back to the sender on the internal network, the sender gets a non-delivery report (NDR), indicating that the message is larger than the current system limit or that the recipient's mailbox is full. After taking a close look at the issue, we can see that at some point after the message leaves the organization, the size of the attachment increases by approximately 30%. The question is, why do attachment sizes increase while sending and receiving e-mail messages through the Internet? And more important, is this expected behavior?

QWe are in the middle of a transition from Exchange 2003 to Exchange 2007. We have moved all user mailboxes to Exchange 2007 mailbox servers, all of which have been configured using Cluster Continuous Replication (CCR). We are currently replicating all public folders from our legacy Exchange 2003 public folder server to a CCR-based mailbox server. However, we have discovered during testing that when a lossy failover occurs on the CCR cluster, the public folder database isn't brought online on the other node. We also cannot mount it manually after the failover. We have a lab environment that mirrors our Exchange 2007 infrastructure in the production environment, and testing shows that the issue occurs here as well. We don't see this issue with any of the mailbox databases on any of the CCR clusters on which a lossy failover occurs, so it seems to relate strictly to public folder databases on CCR clusters. Since we want to achieve true redundancy for all databases, including the public folder database, do you have any insight into what would cause this behavior?

QAll the mailbox servers within our Exchange 2007-based messaging infrastructure are configured using CCR. We are very satisfied with the way CCR works, but have a question we hope you can answer. When online maintenance is run each night, one of the tasks is the online defragmentation. How do we ensure the databases on the passive node in a CCR cluster get defragmented during online maintenance?

QWe're planning to use Exchange 2007 CCR in order to achieve true redundancy for our mailbox servers. Currently, we're looking into how the transport dumpster is used in combination with CCR in order to ensure that no messages are lost during a lossy failover from the active CCR node to the passive node. Do you know of any transport dumpster gotchas we should be aware of?

QWe are currently planning a cross-forest migration from an Exchange 2003 organization to an Exchange 2007 organization in a new Active Directory forest. We have extensively studied the cross-forest migration documentation, "How to Transition from Single Forest to Cross-Forest", which indicates that you should create a forest trust and not an external trust between the forests. Why is it that an external trust can't be used?

QOur organization just transitioned to Exchange 2007, and so far we are very pleased with the new version, with one possible exception. Back when we were using Exchange 2003 SP2, we were able to configure our environment so that the simple display name of a user mailbox was shown as the sender of an outgoing message. To our dismay, we have not been able to find a similar feature in Exchange 2007. Please don't tell us that this feature is missing in Exchange 2007!

QWhat is the best practice for defragmenting the database copies on the passive node on an Exchange 2007-CCR-based mailbox server? Will Exchange become confused if the databases on one of the nodes in the CCR are defragmented, but those on the other nodes aren't?