Exchange Server's 32 KB Rules Limitation - Exchange 2010

Exchange 2003 and older supports just 32 KB worth of rules. If each rule is small and simple, you might get about 50 – 70 rules when using Outlook 2002 and older. Outlook 2003 (and up) uses Unicode when writing the rules and this requires more space per rule, leaving most users with about 20 rules.

In Outlook 2000, you could force rules to be client rules, which are stored in Outlook. This would allow you to have many more rules. This does not work in Outlook 2002 and 2003 (and up) – all rules, both client and server, are stored on the Exchange server and subject to the 32 KB size limit.

In Exchange Server 2007/2010/2013 and Office365, the limit is higher – 64KB by default and configurable up to 256KB. This change will allow in the neighborhood of 100 rules, or about 90 more than I want to manage in the Rules dialog.

Here is the below the below shell command to explore the rule size.

Set-Mailbox username -RulesQuota:256KB

See Set-Mailbox cmdlet (TechNet) for more information
See the tools listed below to overcome this limitation and for better rules handling.

iOS6.1 causing Excessive logging - Assigning a Throttling Policy to all iOS 6.1 Devices in Exchange 2010

If you're an Exchange administrator, you have probably heard about the issues caused by Apple's iOS 6.1 on Exchange servers. It seems that screwy calendar code in iOS 6.1 ends up generating masses of transaction logs in Exchange, and can bring CAS servers to its laps.

The temporary workarounds that MS recommends were to either apply a throttling policy to affected users, or block iOS 6.1 devices completely. Since an all-out block is generally is not good method, throttling policy is the way to go. However, determining who is using iOS 6.1 and applying a throttling policy to them was not provided.

Avoid database defragmentation (Event 629) on Exchange 2010

Sometime, we had an issue with database full and we generally get the event 629 to run an offline defrag on the databases. For doing defragmentation, we require a downtime we will get some white space.

In order to avoid the downtime for doing defragmentation, To overcome this action we can move the mailboxes to available databases and delete the problematic database and recreate the same. In this we will get more white space and there is no downtime require. Here is the below step to follow once you have moved the mailboxes to available database.