Outlook rules help users organize their mailboxes. Thanks to them, sieving spam from important messages can be more automatic and users mailboxes can look less chaotic. That is the bright side of Outlook rules. The less bright side is that users highly depend on them and every time there is an issue concerning the rules, admins find themselves to be in the eye of the storm. You can remain calm, though, as I will show you how to manage users’ Outlook rules using PowerShell. But first, you have to know the difference between the two types of those rules, to learn what you can do with PowerShell and what requires a direct intervention in the users’ email clients.
Server-side rules vs. client-side rules
Outlook rules can be either server-side or client-side. Understanding the differences between them is crucial for an admin, as the type determines when they are executed and which cmdlets can be used to manage them.
- Server-side rules: Their execution is performed entirely by the Exchange Server. They are enforced even when the user’s Outlook client is offline. You can use all cmdlets listed in the further part of the article. Mind that rules created in Outlook Web App are always server-side. Possible uses of These Outlook rules include:
- Change the priority of an email,
- Move an incoming message to another folder,
- Delete an email.
- Client-side rules: Those rules are executed only when Outlook is online, and the user is logged in. It will not work if an email is accessed from a different email client or a mobile device. What is more, it is impossible to use PowerShell to create or modify them with New-InboxRule and Set-InboxRule Using client-side rules, Outlook can e.g.:
- Move messages to a PST file,
- Play a specific sound when mail from a certain address arrives
- Mark a message as read
To check whether a rule is Server-side or Client-side, you can use Manage Rules & Alerts window in Outlook. Client-side rules have (client only) text added to their name, while server rules do not:
This Outlook window is the only place where you can check the type of an Outlook rule for sure. There is no certain way to determine this in Exchange Management Shell. It is true that, usually, client-side rules have a shorter description in EMS, as shown in the further part of the article, but it is hardly a foolproof way to determine a rule type.
Managing Outlook Rules with PowerShell
Starting from Exchange Server 2010, Microsoft has given the ability to use PowerShell for remote management of Outlook Rules. The cmdlets used for that purpose are as follows:
- Get-InboxRule, which previews the ruleset for a specified mailbox,
- New-InboxRule, which creates a new rule remotely,
- Enable-InboxRule and Disable-InboxRule used to turn rules on and off,
- Set-InboxRule, which modifies rules,
- Remove-InboxRule, which can be used to delete rules
Mind that successful execution of any cmdlet from the list above (apart from Get-InboxRule), removes all client-side rules created in Outlook for a user (Refer to this docs site for more information).
This cmdlet is primarily used to preview all rules set for a specific mailbox. In its basic form it looks like that:
Get-InboxRule -Mailbox <mailbox_name>
As you can see, each rule has its own, distinct RuleIdentity parameter. This parameter can be used to view its settings and description, like that:
Get-InboxRule –Mailbox <mailbox_name> -Identity <number> | FL
However, it is much easier and more efficient to search and view Outlook rules by their name and description:
Get-InboxRule –Mailbox <mailbox_user> | Select Name, Description | FL
Here, you can see the difference between server-side and client-side rules, mentioned before: In PowerShell, the description of the former is complete, while the description of the latter is much shorter, showing only the rule’s conditions:
Exchange Management Shell:
This cmdlet lets an Exchange Server administrator create a server-side rule remotely. It cannot be used to create a client-side rule. In other words, you can set up such a rule only using a user’s Outlook client.
I will show how to create two different rules using this cmdlet.
The following cmdlet creates a rule which moves messages which contain the word “spam” in the subject to the Junk E-mail folder:
New-InboxRule -Name "Move to Spam" -Mailbox j.doe -MoveToFolder 'firstname.lastname@example.org:\Junk Email' -SubjectContainsWords "Spam" -StopProcessingRules $True
Mind that you can combine it with a mail flow rule which adds the word ”spam” to the email subject when meeting certain conditions.
The next cmdlet generates a rule which moves emails received before April 15, 2017, from Inbox to the Archive subfolder:
New-InboxRule -Name "To archive" -Mailbox email@example.com -MoveToFolder "firstname.lastname@example.org:\Inbox\Archive" -ReceivedBeforeDate "04.15.2017"
You can use them to turn Outlook rules on and off
You can check which rules are enabled using Get-InboxRule:
Get-InboxRule –Mailbox <mailbox_name>
Disabling and enabling a rule works in the same way:
Disable-InboxRule -Identity <rule_name> -Mailbox <mailbox_name>
Enable-InboxRule -Identity <rule_name> -Mailbox <mailbox_name>
This cmdlet lets you modify any server-side rule. It is a good practice to check the detailed description of the rule you want to modify. You can do it with the previously described Get-InboxRule cmdlet:
Get-InboxRule –Identity <rule_name> Mailbox <mailbox_user> | Select Name, Description | FL
Let’s change its conditions so that it reacts to the word “spam” included in the email body, instead of its subject:
Set-InboxRule -Identity <rule_name> -Mailbox <mailbox_name> -BodyContainsWords "spam" -SubjectContainsWords $nule
The last cmdlet irreversibly removes any rule you specify from a mailbox.
Remove-InboxRule -Identity <rule_name> -Mailbox <mailbox_name>
Common problems with Outlook rules
Outlook rules give users the ability to control and organize their mailboxes content. At the same time, those rules generate problems with the messages. Below are the most common problems Exchange Server admins come across:
Conflicts usually occur when more than one rule applies to an incoming email. For example:
John receives a message from Tony with the subject Important. John’s Outlook has two rules which apply to this email. The first one should move all messages from Tony to the Co-workers subfolder. The second rule is supposed to move emails with the subject Important to the Important e-mails subfolder.
If both rules are the client-side type, they will be executed according to the priority they have (you can check rules’ priority using Get-InboxRule -Mailbox <mailbox_name>). In this situation, the message from Tony will go to the Co-workers subfolder and the second rule will not be enforced due to the conflict.
But the real problem begins, when server-side and client-side rules mix. When the Outlook client is offline, server-side rules will be executed first, even if they have a lower priority. Let’s go back to the example above. If the first rule is client-side and the second one is server-side, the message will be moved to different folders, depending on whether the client is running or not.
The ability to create such rules often leads to emails either being duplicated, going missing or going to a wrong recipient. Such problem may occur if a user forgets that before going on vacation they set a rule which forwards their correspondence to someone else (and it happens a lot).
You can solve such problems using logs from Get-MessageTracingLog cmdlet. You can find such anomalies by looking for MAILBOXRULE entry under the Source header:
Then you can filter this MAILBOXRULE event:
And finally, use Get-InboxRule rule to learn whose Rule is responsible for the issue:
Outlook Rules in a company
Apart from helping individual users, Outlook rules can also be used to organize workflow of a whole company. For example, you could remotely create subfolders in users’ Inbox folders, and then create a rule which moves emails from an internal company application to the newly created folders. It will help keep the correspondence well organized throughout a whole company.
First, you can use an EWS-based script to create folders in your users’ mailboxes.
Next, using New-InboxRule, you can create a rule which will move the messages of your choosing to the newly created subfolders.
Note that this is a single example of how Outlook rules can be used in a company.
No doubt, Outlook rules can come in handy in many situations. At the same time, managing them along with mail flow rules can be quite overwhelming from an Exchange Server Administrator’s perspective. In some cases, a multitude of those rules can cause a major disturbance in mail flow of the company. To make an admin’s job much easier, you can use Exchange Rules Pro. One of its many features is that it helps with managing transport rules and ensuring that mail flow is not disturbed.