Exchange Q & A: Adding confusing attachments, copying public folders, and more

Q: our organizational message transmission infrastructure is based on Exchange Server 2007. We set a strict message size limit (12 MB) throughout the organization ).

We found an abnormal behavior, which seems to be related to the size of the email attachment. When I sent an email with an attachment assumed 11 MB) to an external user, the recipient received the email as scheduled. However, if the email includes attachments) is forwarded back to the sender in the internal network, the sender receives a failed message (NDR ), indicates that the email size exceeds the current system limit or the recipient's mailbox is full.

After studying the problem, we found that the attachment size increased by about 30% when the email leaves the organization. I want to know why the attachment size increases when I send and receive emails over the Internet? What's more, is this normal?

A: in short, yes. This phenomenon is often expected, not only for Exchange Server 2007, but also for earlier versions of Exchange Server and any other support for MIME multi-purpose Internet Mail Extension) this is the same as the message passing system that uses Base64 to encode the attachment. Internal Exchange users do not need to perform any content conversion for emails sent to recipients in the Exchange organization. This means that you cannot see the increase in the size of emails or attachments during transmission. Emails sent to external recipients may need to undergo content conversion.

Standard SMTP mail, also known as plain text mail, contains the mail envelope and content-the mail title and body. These elements are based on 7-bit US-ASCII plain text. The element must be encoded when the message contains elements that are not US-ASCII plain text. When processing such non-text content including attachments), use MIME for encoding. Exchange 2007 and earlier versions of Exchange Server use Base64 algorithms to encode attachments. The disadvantage of Base64 is that it increases the size of the attachment by 33%.

In Exchange 2007, except Outlook Web Access, most of the other transfer-related content conversions are performed on the hub transport server. For more information, see the topic "learn about content conversion" on technet.microsoft.com/library/bb232174 ".

Q: We are transitioning from Exchange 2003 to Exchange 2007. We have migrated all user mailboxes to the Exchange 2007 mailbox server, and all servers have been configured using cluster continuous replication (CR. At present, we are copying all public folders from the original Exchange 2003 public folder server to the CR-based mailbox server. However, we found in the test that when there is a data loss failover in the CR cluster, the public folder databases on other nodes will not be online. After the Failover, we cannot manually mount it.

We have a lab environment that can mirror the Exchange 2007 infrastructure in the production environment. The test shows that the same problem occurs here. This issue does not exist in any mailbox database in any of the CR clusters with failover, so it seems to have a lot to do with the public folder database on the CR cluster. We want to implement real redundancy for all databases, including public folder databases. Can you help us analyze the root cause of this behavior?

A: The replication method used by Cr is different from that used by public folder replication in Exchange 2007. Therefore, if one of the public folder databases is hosted on the CR-based mailbox server, we recommend that you do not Merge multiple public folder databases in the Exchange organization with the CR-based mailbox server. You can perform this operation during the transition period. The Exchange product group allows you to host a public folder database on a cr-based mailbox server, for example, the original Exchange 2003 Server ). However, it is strongly recommended that you delete a public folder database that is not based on the CCR mailbox server after copying all public folder data.

It is normal that you encounter problems in the Exchange messaging environment. If you have multiple public file set databases, and one of them is hosted on the CR-based mailbox server, the Failover is not scheduled to be interrupted, the public file set database on the CR-based mailbox server will be offline.

In fact, the public folder database cannot be brought online until the previous active node appears again. In addition, all transaction log files must be available for storage groups hosting public folder databases.

If this condition is not met, you should consider restoring the public folder storage from the last intact backup, browsing available logs, and then resetting the seeds for other nodes from the restored database. Alternatively, you can create a public folder from the beginning. In this case, you must restore the original active node, create a public folder database, and copy public folder data from other public folder servers in the Exchange organization.

It is quite strange that the execution is lossless and planned.) When the interruption, the public folder database is online. This is normal. For more information, see "cluster continuous replication and public folder Database" on planning cluster continuous replication ".

Q: In our Exchange 2007-based message passing infrastructure, all mailbox servers are configured using the CR. We are very satisfied with the way in which the service is working, but we hope you can answer a question.

During online maintenance every night, we need to sort fragments online. How can we ensure that the database on the passive node in the CR cluster can complete fragment during online maintenance.

A: In this process, the dissembling task deletes all items marked as removed, and changes the space occupied by these items to available space. A new transaction log file is generated. All the transaction log files generated on the active node of the CCR will be copied to the passive node, resulting in changes to the database on it.

After clarifying this, make sure that the online maintenance time is scheduled to avoid conflicts with your backup time because this forces online fragment interruption ). In this case, fragment is not required every day, every week, or even every other week. Previously, the Exchange product group guidelines stipulated that online fragmentation should be performed at least once every week. However, the environment of each organization changes with the release of Exchange Server 2007 SP1. For more information about this new Guide, see the post on the Microsoft Exchange team blog.

Q: We plan to use Exchange 2007 Cr to implement real redundancy of mailbox servers. Currently, we are working on how to use the transfer dump program in conjunction with the CCR to ensure that no emails will be lost when data loss is transferred from the CCR active node to the passive node. Do you know the transfer dump problems that need our attention?

A: The transfer dump ensures that data loss is minimized when you fail over from one node on the Exchange 2007 mailbox that uses CCR to another node. This can be done by resending the email recently submitted to the mailbox server. During data loss failover, you may lose some transaction log files and actual data. As described above, the transfer dump resends the recently submitted email to the mailbox server to ensure that lost data is restored during failover. However, since the hub transport server where the transfer dump program resides only delivers mail, some data that will be created during the upcoming failover of lost data will be lost, such as tasks and calendar items.

Q: We are currently planning a cross-Forest migration from the Exchange 2003 Organization to the Exchange 2007 organization in the New Active Directory forest. We have extensively studied the cross-Forest migration document "How to transition from a single forest to a cross-Forest", which states that forest trust should be built rather than external trust should be built between forests. Why cannot I use external trust?

A: Although the Exchange 2007 document in TechNet states that you should use forest trust instead of external trust, it does not mean that you cannot use external trust. In fact, although external trust is very suitable for cross-Forest Exchange migration, it has a disadvantage. Because you cannot use the creden of logged-on users, no matter which permissions are assigned to them), you must specify an account with proper permissions when creating a linked mailbox, for access to the domain controller in the trusted forest, see Figure 1 ).

Figure 1 specifying an Account on the Master Account page when creating a linked mailbox

Q: our organization has just transitioned to Exchange 2007. So far we are very satisfied with the new version, with only one exception. When using Exchange 2003 SP2, we were able to configure our environment to display the simple display name of the user's mailbox as the sender of the outbound mail. Unfortunately, similar features cannot be found in Exchange 2007. Do not disable this function in Exchange 2007!

A: This feature was indeed missing in Exchange 2007 RTM, and was corrected only in Exchange October 2008 SP1 Rollup Update 4 (RU4) released in 2007. With SP1 RU4, you can configure Exchange again to display a simple display name in the outbound mail, the same effect as using Exchange 2003 SP2. This task can be completed by using the Windows PowerShell Set-RemoteDomain cmdlet and the parameter-UseSimpleDisplayName. For example, to enable a simple display name on an outbound email sent to the contoso.com domain, use the command shown in figure 2.

Figure 2 use a simple display name for outbound mail

Q: What are the best practices for fragment of database copies on passive nodes on the mailbox server based on Exchange 2007-cr? Will Exchange be confused if the database on one node in the group is defragmented but the database on another node is not executed?

A: If you need to deploy fragments offline, you should always execute the fragments on the active nodes in the CR cluster. Do not use the passive nodes. Note that if you perform offline fragmentation for one or more databases on the active node, you must completely reset the seed for the special databases on the passive node.

For example, if you have a 200 GB database, if you use the CR, the recommended database size is 200 GB for network replication over 1 GB ), it will take several hours to fragment it. The good rule is 2-4 GB per hour ). However, after completing the fragmentation, You need to copy 200 GB of data to the passive node. If a log file is transmitted over a public network, the overall network performance of your end user experience will be affected.

In most cases, the purpose of offline fragmentation is to delete all blank areas in the database to reduce the size of the database. However, since the blank area will be reused before the database increases further, it is usually not necessary to do so. It doesn't matter whether the database or disk itself has available space. Do you understand?

If you want to delete a database that contains many blank areas of gigabytes, it is better to remove all mailboxes from the database and move them into a new database.
 

Henrik Walther is a Microsoft certified Architect: Exchange 2007 and Exchange MVP with more than 14 years of IT experience. He is a technical architect at Interprise Consulting, a Danish Microsoft Gold partner, and a technical contributor to Biblioso Corporation, an American company specializing in document hosting and localization services.
 

Original article address

Source: TechNet