It is well known that an Outlook client sending too many RPC connections per second could result in overall Exchange server performance degradation. It could be a desktop search engine, e-mail archiving products, custom apps written to manipulate exchange mailbox data… the list goes on.

In the past, the solution to this for Exchange administrators was limited. It is not practical at times to call the user who is causing too many RPC requests and wouldn’t it be better if the issue can be handled transparently?

Exchange Team answered that in Exchange Server 2007. The feature is called Client Throttling. RPC Client Throttling computes remote operation (ROP) statistics based on overall RPC average latencies. If high ROPs per second is detected (excluding short spikes) the back-off request is sent to the client.

For Outlook 2007 clients, a ropBackoff request is added to the back-off queue. ropBackoff is a new function in Outlook 2007 and earlier Outlook client do not understand this function.

Yes grasshopper, I know, I have the answer, patience!

For Outlook 2003 clients and earlier versions, the status code RPC_S_SERVER_TOO_BUSY is sent instead.

You can tune Throttling Factor using RPC Throttling Factor registry key. I can write a lot but I will instead send you to the great article written by great minds at Exchange Team. If you read this article, I promise, you will not be disappointed.

It must be satisfying when you say back-off and they obey!

I have spent a lot of time recently investigating storage solutions as part of a migration design for Exchange 2007.

The current implemented solution is a multi-node Exchange 2003 cluster with SAN based storage (No HA/DR). With Exchange 2007 the desire is to deploy a  CCR/SCR solution to allow for data redundancy, disaster recovery, and site resiliency. The toughest decision that I have been faced with (given that I am not a storage guru) is in storage design. Should it be a DAS or SAN based solution? Each has benefits and negatives. Here are my random thoughts on the subject.

Performance:

Traditionally storage has always been the bottleneck in systems hosting heavy IO applications like Exchange. With the transition to 64-bit in Exchange 2007, IO has been significantly reduced. This has allowed DAS (mainly Serial-Attached SCSI) to become a viable alternative solution for Exchange deployments.

Scalability:

SANs are very scalable but as they scale the TCO increases. DAS based solutions are able to scale less but at a much lower cost.

Availability:

Any shared storage represents a single point of failure. Although it is rare for a SAN to fail, anything is possible. The HA and DR solutions offered by SAN vendors are generally very expensive and difficult to implement and support. The CCR/SCR solutions offered by Exchange 2007 in combination with DAS storage, offer a lower cost and easier to manage, high availability solution.

Cost:

DAS based solutions can offer a significant cost savings over SAN based storage.

Some additional points to consider:

Footprint – DAS based storage array cabinets from most vendors (HP, Dell) that I have investigated, require 2U of rack space each. Any significant storage requirements would lead to significant rack space, power, and cooling requirements.

Administration – DAS allows for more centralized control of the storage configuration by the messaging team. The setup and maintenance is less complex than prior SAN configurations and does not include the need  to rely on a storage administrator for assistance.

This is an interesting and important area to investigate as part of any Exchange deployment. As with any solution, a lot depends on what you current requirement is and future requirements are.

References:

http://technet.microsoft.com/en-us/library/cc500980.aspx

http://www.emc.com/collateral/demos/microsites/mediaplayer-video/henderson-exchange.htm

http://msexchangeteam.com/archive/2006/10/05/429103.aspx