Had they migrated to Exchange 2010, this would not have been necessary because Exchange 2010 allows you to manage rules using these six commandlets: Get-InboxRule, Set-InboxRule, Remove-InboxRule, Disable-InboxRule, Enable-InboxRule and New-InboxRule.
One approach is to use "Get-InboxRule" to find all enabled, server-side rules. Disable those rules (remember which rules you disabled so you can re-enable them after the migration.)
We came up with another approach: Add a new rule that has the "highest" priority, have that rule do nothing, then say "stop processing rules." After the migration, remove that rule.
Here's how we approached it for one user, say, Zyg:
• New-inboxrule -mailbox:zyg@mailbox.sumatra.com -name:"_sumatraHiPriorityRule" -Priority "0" -StopprocessingRules:$true -Confirm:$false
and then to remove:
• Remove-inboxrule -mailbox zyg@cod.sumatra.local -Identity:"_sumatraHiPriorityRule" -Confirm:$False
Caveats:
- Note the priority zero (0) makes this rule the highest-priority rule. All others drop down one.
- We are ignoring the power-rule-user scenario: the user exceeds Exchange's inbox rule memory size buffer limit (it's 32KB) (or about 40-50 rules.) Obviously when you're at the limit you can't add any more rules. We don't have a suggestion except to say "look" for disabled rules and ask the end user if a few could be removed.
- The "-force" parameter - removes disabled rules AND all Outlook client-side rules.
- new-InboxRules doesn't accept pipelined userlist from "get-mailbox -filter {isResource -eq $false}". What happens if you have 5,000 accounts? Stay tuned ---
No comments:
Post a Comment