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:


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:


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

Exchange Management Shell:

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


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


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


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.

13 thoughts on “Managing users’ Outlook rules from Exchange Management Shell (with PowerShell)

    • As long as the specific rule has the same name at each mailbox, you can use the following syntax:
      $mailboxes = import-csv *CSV with the list of mailboxes*
      foreach($mailbox in $mailboxes) {Remove-InboxRule -Mailbox $mailbox -Identity *rule name*}

      Instead of import-csv, you can use get-mailbox with the right parameters. It all depends on where you keep the list of those “multiple mailboxes”.
      A word of warning – Before running this cmdlet on production, create a test user, add a few Outlook rules and use the cmdlet to delete one of them. Then, verify if the other rules are there and work as expected.

    • Hi Robert,
      Unfortunately, Get-InboxRule does not retrieve the rule creation date. You might be able to find the date using mailbox audit logs, but you would have to enable them before trying to get any information.

  1. @Adam

    We use Public folders to auto-archive sent emails based on what job number is in the subject field. Each user now has to individually set those rules in case it’s them sending the email that needs to be archived. I was hoping to find a way to centrally push out those rules to the clients or otherwise manage them centrally on the server. I’ll have another look at inbox rules but I don’t think it applies here.

    • You could use New-InboxRule with -SubjectContainsWords and -MoveToFolder attributes to distribute rules with specific job numbers to all employees who use public folders. It would work, and it would be less problematic than each user doing it manually. If that does not work for you, you could also use the export/import feature from within Outlook. It would make things at least a bit less problematic.
      Personally, I would try setting the inbox rule directly for the public folder. Though I’m not entirely sure how exactly your auto-archiving and job number feature works, so I can’t tell if that’s the best solution for you.

  2. Does the Powershell commands work for regular users, or is it only possible for Exchange admins?

    If it works for users which Powershell module do I have to install? Because Get-InboxRule is not available in a regular Powershell.

    • Hi Robert,
      To run inbox-rule-related cmdlets, you need to have some permissions. To find out which permissions exactly, simply run the following: get-managementrole -cmdlet get-inboxrule. All the cmdlets I mention, require the Exchange PowerShell module and connection to the Exchange Server (or using Exchange Management Shell).

    • What do you mean by outbox rules? If you mean rules that apply to outgoing messages, those are still inbox rules. Unfortunately, those rules are client-side, so you will not be able to do much managing via PowerShell. If you want to manage outgoing emails, you should use transport rules (Get-TransportRule).

    • Hello Allen,
      I’m afraid that the only available way to export and import inbox rules is the built-in Outlook manual tool available in Rules’ Options.

  3. It seems rather odd that this isn’t exposed natively, but do you happen to know how to discover WHEN an inbox rule was created?

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>