Throttling Policy Fallback Logic

The throttling framework is intended to protect Exchange resources, so if it is going to "fail", it needs to do so in a safe and predictable way. Let's say that Ken Malcolmson is assigned to non-default throttling policy XYZ. Unfortunately, an Active Directory elf climbed into your domain controller and scrambled things around a bit. So, when Exchange Web Services (EWS) (or some other process) tries to load policy XYZ, it fails. Or does it? Actually, it fails along a fallback path.

If the non-default policy is corrupt or missing, it will first fall back to the default throttling policy for the organization in question. Aha! What if the default policy is corrupt? Well, then it falls back to a special policy defined in code called the "fallback policy". Given that this policy is embedded in the Exchange assemblies, there is little chance that such a read will fail.

What are the values of the fallback policy? They are the exact values that default policies are assigned when Exchange is first installed.

One interesting thing about the fallback policy is that it will also be applied to authenticated callers that don’t fall neatly into an organization. Computer accounts, cross-forest contacts, typical Active Directory users (with no mailboxes), etc… will all be given budgets based on the fallback policy, so Exchange is protected against such activity. The downside to this is that because the fallback policy is defined in code, there is no way to modify the policy values for any such accounts.

David Sterling
Exchange Web Services
Inside Microsoft Exchange Server 2007 Web Services