A database availability group (DAG), together with mailbox database copies, can provide automatic recovery from a variety of server, storage, network, and other hardware failures. A DAG can also provide a site resilience solution so that you can perform a datacenter switchover in the event of a site-level disaster. But even a comprehensive, intelligent, and robust solution such as a DAG can’t protect you from all possible disasters, including disasters that affect an entire DAG. For example, consider a two-member DAG deployed in a single datacenter. If the datacenter experiences a flood, fire, or other cataclysmic event that destroys the DAG, the entire DAG will need to be rebuilt from scratch.  How do you do that?

A few days ago, we published a new Feature Article on TechNet, by Tim McMichael, called Rebuild an Entire Database Availability Group.  In this article, Tim describes how to rebuild a DAG that has been completely lost.  He walks you through the entire process, step-by-step, including examples along with way.  For details, check out this excellent article.

We also published some updated guidance around required network latency between Mailbox servers that are members of a DAG.  Our old guidance was as follows:

• Regardless of their geographic location relative to other DAG members, each member of the DAG must have round trip network latency no greater than 250 milliseconds (ms) between each other member.

Our new guidance is now:

• Regardless of their geographic location relative to other DAG members, each member of the DAG must have round trip network latency no greater than 500 milliseconds (ms) between each other member. As the round trip latency between two mailbox servers hosting copies of a database increases, the potential for replication being not up-to-date also increases. Regardless of the latency of the solution, customers should validate that the network(s) between all DAG members is capable of satisfying the data protection and availability goals of the deployment. Configurations with higher latency values may require special tuning of DAG, replication and network parameters, such as increasing the number of databases or decreasing the number of mailboxes per database, to achieve the desired goals.

And of course, as we stated previously and continue to state, round trip latency requirements may not be the most stringent network bandwidth and latency requirement for a multi-datacenter configuration. You must evaluate the total network load, which includes client access, Active Directory, transport, continuous replication, and other application traffic, to determine the necessary network requirements for your environment.

There is another support change that we made recently (although the documentation has not been updated because the support change occurred after this last document refresh) with respect to using Bitlocker on DAG members.  Our old guidance (which will remain on TechNet until our next document refresh, even though the new guidance now applies) was as follows:

• Windows failover clusters can’t have BitLocker enabled.

Our new guidance (and what the updated article will say when published), is as follows:

• Windows failover clusters require Windows 2008 R2 and the following hotfix: KB2446607 (or subsequent service pack).  BitLockered Exchange volumes are not supported on Windows failover clusters running earlier versions of Windows.

This means that if your DAG is running Windows Server 2008 R2 or later, once you download and install the QFE from 2446607, it is supported to use BitLocker for Exchange database and log file volumes in the DAG.

Source: Scott Schnoll

New Exchange Server 2010 Tested Solutions white papers have been released.

Just follow the links and enjoy the reading :

Exchange 2010 Tested Solutions: 16000 Mailboxes in a Single Site Deployed on IBM and Brocade Hardware

In the Exchange 2010 Tested Solutions white papers, Microsoft provides examples of well-designed, cost-effective Exchange 2010 solutions deployed on hardware offered by some of our server, storage, and network partners.

Exchange 2010 Tested Solutions: 9000 Mailboxes in 2 Sites with Hyper-V on Dell M610 Servers & Storage with F5 Load Balancing

In the Exchange 2010 Tested Solutions white papers, Microsoft provides examples of well-designed, cost-effective Exchange 2010 solutions deployed on hardware offered by some of our server, storage, and network partners.

Exchange 2010 Tested Solutions: 15000 Mailboxes in Two Sites Running Hyper-V on Unisys ES7000 Servers and Hitachi Storage

In the Exchange 2010 Tested Solutions white papers, Microsoft provides examples of well-designed, cost-effective Exchange 2010 solutions deployed on hardware offered by some of our server, storage, and network partners.

Exchange 2010 Tested Solutions: 500 Mailboxes in a Single Site Running Hyper-V on Dell Servers

In the Exchange 2010 Tested Solutions white papers, Microsoft provides examples of well-designed, cost-effective Exchange 2010 solutions deployed on hardware offered by some of our server, storage, and network partners.

Exchange 2010 Tested Solutions: 20000 Mailboxes in Two Sites Running Hyper-V on Dell R910 Servers, EMC CLARiiON, and Brocade

In the Exchange 2010 Tested Solutions white papers, Microsoft provides examples of well-designed, cost-effective Exchange 2010 solutions deployed on hardware offered by some of our server, storage, and network partners.

A question that comes up often enough to merit a post is: "How does one block read receipts from leaving or entering my org?"

Good question. I’m glad you asked!

And to answer that we need to go into the way back machine to Exchange 2003.

In Exchange 2003 we used the IIS SMTP engine. As you know all the relevant settings were kept in the IIS metabase (taken from AD during the DS2MB 1 way process or natively there) so when it was requested that the ability to block read receipts be put into the product we obliged with a hotfix that allowed the creation of a key in the metabase to block these (after it was discovered that checking off "Do not send delivery reports" on the remote domain object did not accomplish this. More on that later.)

You can read about this in all its glory here.

While you are reading that you may notice the first sentence which mentions how editing the Remote Domain "Do not send delivery reports" will NOT block read receipts from entering/leaving your org (told you we’d come back to that).

Without getting too much into RFCs, a read receipt is not a delivery report. A delivery report is defined in RFC 1891. The mime content type of a delivery report is a multipart/report; report-type=delivery-status.

Actual shot of a delivery report below:

A read receipt is defined in RFC 2298 and has a mime content type of multipart/report; report-type=disposition-notification.

Actual read receipt found in the wild below:

A further thing to note is that delivery reports originate from the system administrator or postmaster or Microsoft Exchange Recipient account (depending on which version of Exchange we are talking about) while Read Receipts come from the recipient that has requested a receipt.

Still with me? Ok so if we circle back to the original Exchange 2003 kb it should be noted that those instructions only prevent INCOMING read receipts from entering your org. They do NOT stop internal users from sending read receipts to each other or from requesting read receipts of external users.

What adding that key to the metabase actually accomplishes is stripping of the Disposition-Notification-To mime header from incoming read receipt requests.

Read that again: read receipt REQUESTS.

Going back to the RFCs (I’ll be quick I promise) there is a difference between the actual read receipt itself and the read receipt request (same goes for delivery reports and the initial delivery report request).

A read receipt request contains a Disposition-Notification-To header like the one below:

This is an important distinction as it is the read receipt request that causes the receiver to generate a Read Receipt.

This is what causes the receiver of the request to see this pop-up in Outlook:

If we strip that header the receiver is never prompted for a Read Receipt and thus never generates one.

Doing this for incoming messages is easy in Exchange 2003 since it is just a mime header we can strip.

Outgoing is not possible as the header is now a tnef MAPI property and part of the message structure.

Stopping outgoing read receipt requests requires a much greater code change investment and ultimately was never possible in exchange 2003 (for the curious and for completeness sake – a delivery report also has a corresponding delivery report request which is identified by the NOTIFY=SUCESS,FAILURE,DELAY parameters after a RCPT TO:. However unchecking "Allow Delivery Reports" on the remote domain object effectively blocks all Delivery Reports from coming out.)

Enter Exchange 2007. Yippee!

With Exchange 2007 we now have transport rules so we can totally block Read Receipts from leaving and entering, right?

Well, sort of.

For incoming read receipt requests we can create a transport rule to strip the Disposition-Notification-To header. Such a rule might look like this:

For outgoing Read Receipt requests we fall into a new twist on the Exchange 2003 issue.

Certain properties of an outgoing internally originated message are kept in a special x-header called X-ExtendedProps and you guessed it, Read Receipt request information is one of them.

This is a "pesudo-base64" encoded header that Exchange hub transport servers stamp on internal messages and which gets stripped out later by header firewall.

You can see this header by suspending the submission queue on a hub and export one of the suspended messages in there.

You will see something like this:

I’d like to pause here for a brief break and say that you will not see this header if you do a pipeline trace. It will only be visible if you export the message from the queue. The reason for this is that due to certain issues with custom transport agents in Exchange 2007 SP 1 we moved the content conversion stage further down the transport pipeline in Categorizer so a pipeline trace will only show you the state of a message PRE-conversion.

Ok, break over.

Since we have all the Read Receipt request info in this X-ExtendedProps header having a rule strip the Disposition-Notification-To header will have no effect. And transport rules cannot act on the system X-header (and even if they could very bad things may happen if you try to strip them. Just sayin’).

Really the best way to strip outgoing Read Receipt requests is to stand up an Edge Transport server and have the identical rule above as an Edge rule. As stated earlier, once the message leaves the org Header Firewall will strip the X-header and replace it (in our case) with the standard RFC Disposition-Notification-TO.

This will prevent external recipients from receiving the dreaded pop-up (shown here again for effect) which will generate a incoming read receipt:

A second option is to deploy the Office ADM template in a GPO to remove the ability of users to send out read receipt requests. (You will still need the hub transport rule to block incoming Read Receipt requests).

Now we can move on to Exchange 2010 (can I hear a double yippee?).

With Exchange 2010 we have many new additions to transport rules which would make the subject of a great blog post on its own. The one new addition we are concerned with here is the ability to act on messages based on class. Specifically here we are concerned with the read receipt class. With Exchange 2010 we can craft a transport rule to drop messages based on the read receipt class as shown below:

Now the above Exchange 2010 rule should solve our issue! This is great and wonderful! Finally no read receipt requests leaving OR entering my org!

Well… not so fast.

You see, what the above rule does is block the actual read receipt (the multipart/report; report-type=disposition-notification content type. Check the beginning of this blog post if you forgot. Its ok I’ll wait).

This rule will not block the original read receipt request (shown here again because I believe in learning through repetition):

So we are back to either:

1. Create an incoming rule on your hub and an outgoing rule on your Edge to remove the header.
2. Set an incoming rule on your hub and use the Outlook ADM file to create a GPO to remove the option to request Read Receipts

So at the end of all this we’ve learned that while finally in Exchange 2010 we can block actual read receipts with ease, it still takes a bit of doing to block the read receipt request and be rid of all types of RRs entirely. But it is possible.

Source: Tom Kern

The Microsoft Exchange RPC Extractor (RPX) is a command-line tool that can parse network captures and interpret remote procedure calls made from a client to Microsoft Exchange . RPX uses the information provided in the Microsoft Exchange protocol documentation to parse RPCs, remote operations (ROPs) and the parameters for each ROP.

You can install the Exchange RPC Extractor 1.0 on computers that are running 32 or 64-bit versions of the Windows Vista or Windows 7 operating systems.

Download the tool here

Instructions
Download and install the .msi file. See Readme.htm and ExchRPX10.htm for further instructions.

A FREE tool from Quest – Migration Assessment Tool, that help any Exchange guy in migration scenarios or to get an inventory of the Exchange infrastructure.

This free, browser-based application provides expert guidance for evaluating Exchange Online, Google Gmail, and Exchange 2010 as your next messaging solution. Optionally collect information from your existing Exchange 2003 / 2007 mail system to get:

• A customized feature comparison for each mail system
• A current inventory of Exchange 2003 / 2007 servers, mailboxes, public folders and mobile devices

Access the tool here

Now that you might have seen the announcement for general availability of Windows 2008 R2 SP1, we wanted to get ahead of the inevitable question: "Is Exchange supported running on Windows Server 2008 R2 SP1?"

We wanted to let you know that we’ve completed testing with Windows 2008 R2 SP1 and the following versions of Exchange are supported to run on Windows 2008 R2 SP1 (the RTM version of SP1):

• Exchange 2010 SP1
• Exchange 2010 RTM
• Exchange 2007 SP3

Please note that Exchange 2007 was not supported to run on Windows 2008 R2 at all before Exchange 2007 SP3 release.

Also note, Windows 2008 R2 SP1 includes the hotfixes required to install Exchange 2010 SP1 (listed in Exchange 2010 SP1 FAQ and Known Issues — 979744, 983440, 979099, 982867 and 977020). If you’re installing Exchange 2010 SP1 on a server running Windows 2008 R2 SP1, you don’t need to install these hotfixes separately.

Source: Nino Bilic

New post on the Exchange Team Blog regarding Exchange 2010 Personal Archives support in Outlook 2007 :

Quick post to inform you that we’ve found an issue in Exchange 2010 Personal Archives support for Outlook 2007 in the December 2010 Cumulative Update for Office 2007, which may result in users being unable to access their archive mailbox.

Our friends in the Outlook team have been working hard to fix this. The fix has been checked-in in the February 2011 Cumulative Update for Office 2007, which will be available later this month. As with all updates, we recommend that you test them in a non-production environment before deploying them in production.

Full article at :

You Had Me At EHLO… : Important update about Exchange 2010 Personal Archives support in Outlook 2007
http://msexchangeteam.com/archive/2011/02/01/457903.aspx