Managing users’ Outlook rules from Exchange Management Shell (with PowerShell)

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:
  1. Change the priority of an email,
  2. Move an incoming message to another folder,
  3. 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.:
  1. Move messages to a PST file,
  2. Play a specific sound when mail from a certain address arrives
  3. 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:

Managing Outlook Rules and Alerts

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

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>

Managing Outlook rules Get-InboxRule rule list

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

Managing Outlook rules Get-InboxRule rule description

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

Get-InboxRule rule list name description

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:

Outlook:

Get-InboxRule rules server-side vs client-side outlook

Exchange Management Shell:

Get-InboxRule rules server-side vs client-side Managing Outlook rules

New-InboxRule

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 'j.doe@dstdomain2.lan:\Junk Email' -SubjectContainsWords "Spam" -StopProcessingRules $True

New-InboxRule rule move to spam

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 j.doe@dstdomain2.lan -MoveToFolder "j.doe@dstdomain2.lan:\Inbox\Archive" -ReceivedBeforeDate "04.15.2017"

New-InboxRule rule move to archive

Enable-InboxRule, Disable-InboxRule,

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>

Get-InboxRule rule list enabled

Disabling and enabling a rule works in the same way:

Disable-InboxRule -Identity <rule_name> -Mailbox <mailbox_name>

Managing Outlook rules Disable-InboxRule 1

Enable-InboxRule -Identity <rule_name> -Mailbox <mailbox_name>

Managing Outlook rules Enable-InboxRule 1

Set-InboxRule

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

Get-InboxRule rule check name description

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

Set-InboxRule change subject to body

Remove-InboxRule

The last cmdlet irreversibly removes any rule you specify from a mailbox.

Remove-InboxRule -Identity <rule_name> -Mailbox <mailbox_name>

Managing Outlook rules Remove-InboxRule

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:

Rules conflict

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.

Forwarding rules

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:

Managing Outlook rules Get-MessageTrackingLog

Then you can filter this MAILBOXRULE event:

Managing Outlook rules Get-MessageTrackingLog details

And finally, use Get-InboxRule rule to learn whose Rule is responsible for the issue:

Managing Outlook rules Get-MessageTrackingLog anomaly

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.

To create folders in users mailboxes, you can use the following script:

Create folders in 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.

Leave a Reply

Your email address will not be published.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*