Home » Clients » Mobile Devices » PowerShell Script for TroubleShooting Exchange ActiveSync Devices

PowerShell Script for TroubleShooting Exchange ActiveSync Devices

On a recent case I was investigating a mobile device that couldn't connect to a mailbox over ActiveSync. After spending a few minutes collecting information about the mailbox and its associated devices I realized that this task could be performed a lot faster by using a PowerShell script.

Most mobile device troubleshooting cases boil down to one of a few common issues:

  • AD accounts with permission inheritance disabled
  • Mailboxes with disabled protocols
  • Devices blocked by personal block lists, device access rules, or organization policies
  • EWS block lists (as is the case with Outlook for iOS when it connects using the REST API)

Even though Office 365 MDM and Intune are available, there's still a lot of usage of ActiveSync out there in the world, especially for on-premises customers. So I am sharing the PowerShell script that I wrote for ActiveSync troubleshooting.

EAS Troubleshooter helps you to troubleshoot Exchange ActiveSync device problems by collecting relevant information about a mailbox's configuration and device associations. When you run EAS Troubleshooter against a mailbox you'll see information about the mailbox protocol configuration, associated devices, device status, and more. This information will give you a fast look at the state of ActiveSync for the mailbox, helping you to narrow in on any problems quickly.


You can download EAS Troubleshooter from the TechNet Gallery. Run the script from an Exchange Management Shell or Exchange Online remote PowerShell session.

EAS Troubleshooter uses simple console output with color-coding to draw your attention to potential issues. The goal is to highlight factors that may be contributing to mobile device connectivity problems so that you know where to focus your investigation.

Frequently Asked Questions

Here are some answers and tips that will help you interpret the output of EAS Troubleshooter. If your question is not answered here please leave a comment below.

Q: What is the AD Perms Inheritance item?

For ActiveSync to work the Exchange servers need access to read information from the Active Directory user object of the mailbox user. If permissions inheritance is disabled on the user object then the correct ACLs may not be in place. You can enable permissions inheritance on the object by opening Active Directory Users and Computers, selecting View -> Advanced Features, and then in the properties of the user object choosing the Security tab and then selecting Advanced.

Note that permissions inheritance will be disabled automatically if the user is in a protected security group such as Domain Admins, Account Operators, or any other “admin” group.

This AD permissions check is not applicable to Exchange Online mailboxes.

Q: What do I do if the ActiveSync protocol is disabled?

You can re-enable the ActiveSync protocol for the mailbox using the Exchange Admin Center or the Set-CASMailbox cmdlet in the Exchange Management Shell.

Q: What do the EWS Protocol and EWS Access Policy items mean?

The EWS settings are applicable to Outlook for iOS and Android when connecting to Exchange Online mailboxes using the REST API. See this blog post for more details.

Q: What are the allow/block device ID lists?

Each mailbox can have specific device IDs blocked or allowed. These personal exemptions will override other controls such as device access rules or the organization-level ActiveSync settings. You can add or remove device IDs from these lists using Set-CASMailbox.

Q: What does the ActiveSync Access State mean?

Refer to this article about the allow/block/quarantine process and how ActiveSync device state is determined.

Q: What does the ActiveSync Access State Reason mean?

This property explains how the ActiveSync access state has been determined. Possible values include:

  • Global – access has been determined by the organization-level ActiveSync settings
  • Individual – access has been determined by a personal allow/block list (refer to earlier info in this FAQ)
  • DeviceRule – access has been determined by a device access rule (examples here, here and here)

Q: EAS Troubleshooter says a device is blocked/allowed but that doesn't seem correct?

EAS Troubleshooter is just giving you information to help with your investigation. It can't accurately diagnose every possible cause or account for every scenario. Use the information provided to lead you to a solution that takes into account your own environment and the specifics of your support case.

Q: What about Intune/MDM?

EAS Troubleshooter looks at configurations that impact ActiveSync devices/apps as well as the EWS configuration that impacts Outlook for iOS/Android REST API connectivity. If your devices are controlled by Intune, Office 365 MDM, or a third party MDM, then there may be other configurations in those systems that you need to look into.

Q: What else can I use to troubleshoot ActiveSync connections?

The Remote Connectivity Analyzer can be used to perform external ActiveSync connectivity tests. You can also use Exchange Analyzer to look for problems with your on-premises server configuration. For on-premises troubleshooting there is also the Exchange Server Troubleshooting Companion, and for Exchange Online there is Office 365 for IT Pros.

Paul is a Microsoft MVP for Office Servers and Services. He works as a consultant, writer, and trainer specializing in Office 365 and Exchange Server. Paul is a co-author of Office 365 for IT Pros and several other books, and is also a Pluralsight author.
Category: Mobile Devices


  1. Preston says:

    Great script. One of the biggest issues we run into with Active Sync seems to be with users having too many folders. Can you add that sort of check into the script?

  2. Rob Moritz says:

    Great Script Paul. However how do you get the AD Perms Inheritance to work when you have a multi domain? Exchange is at the root with users in other domains. with the AD module it will only run in the root so it will not find the users. Love that to be a update to the script, beyond that its perfect!!

    • Rob Moritz says:

      I figured it out for anyone else who has a multiple DC’s within a forest. On line 179 add in -server “your rootdomain:3268” this was it is looking at the Global catalog and will find the user to do the search. So my line looks like the following..

      Get-ADUser -Filter ‘SamAccountName -eq $samAccountName’ -server XYZ-AB.com:3268 -Properties nTSecurityDescriptor -ErrorAction STOP

  3. Michael Völker says:

    Many thanks! It’s very helpful for my daily work with employees and students and their mobile devices.

    Greetings, Michael

Leave a Reply

Your email address will not be published. Required fields are marked *