So, you decide that you want to edit a throttling policy. In the Exchange Management Shell, you run Set-ThrottlingPolicy and set some odd parameter to a new value. Then you make your EWS/Outlook Web App/etc. call and notice that the results have not taken effect. Bummer!
Slightly miffed, you open up the Exchange Management Shell again and call Get-ThrottlingPolicy, and lo, the policy was indeed changed. Why didn’t Exchange pick up the policy??
Welcome to the world of caching. The throttling policy framework that Exchange uses works off a “frequency of use” cache. By default, when a policy is first accessed, the process that is using that policy will load it from Active Directory and stick it in a process-wide cache for a *minimum* of 5 minutes. If no one else in that process accesses that policy from the cache, it will expire after 5 minutes so that any future calls will pick up the new data from Active Directory. However, if that policy *is* used over and over and over again, it will extend the life of that policy in the cache up to 15 minutes. After 15 minutes, the policy will expire and an up-to-date version will be loaded.
1. You cannot expect policy updates to immediately be picked up by an Exchange process. No special keys, flags, calls, or whining will help.
2. If you can wait, the policy will automatically be picked up after 15 minutes, and possibly sooner – no need to cycle the process.
3. If you cannot wait for the 15 minutes to pass, you will need to cycle the process.
4. I have found that 15 minutes is the perfect amount of time to obtain a cup of coffee from the kitchen and to begin enjoying said beverage.
Exchange Web Services
Inside Microsoft Exchange Server 2007 Web Services