Home » Exchange Server » Test-ActiveSyncConnectivity Failure Due to Exchange ActiveSync Policies

Test-ActiveSyncConnectivity Failure Due to Exchange ActiveSync Policies

When you are testing ActiveSync using the Test-ActiveSyncConnectivity cmdlet you may encounter failures.

Depending on the specific cause of the failure you may see different results. For example here is a failure at the FolderSync stage of the test.

These failures can be caused by different ActiveSync policies within your organization.

Creating a Test CAS User

As a first step, if you are planning to use Test-ActiveSyncConnectivity you should create a CAS test user using the supplied script from Microsoft. On a mailbox server in your organization open the Exchange Management Shell and navigate to the Exchange scripts folder.

Run the following script. By default it will create the user in the “Users” OU in Active Directory. If you have more than one OU named “Users” you should manually specify a different OU, or specify the exact path to the OU you want to use.

Take note of that generated username, eg extest_0bcca07661e94, as you’ll be using it again for the steps below.

Identifying the ActiveSync Device Access State

After a failed Test-ActiveSyncConnectivity test take a look at the ActiveSync device associated with the test user.

If you don’t know the test user account name, run the following command.

If you do know the exact username, run this command instead.

You should see a result similar to this.

The items of interest at this point are the device access state and the reason. You will likely see a state of “Blocked” or “Quarantined”, each of which requires a different approach. In fact you may encounter both (after solving the first the second will appear) depending on your organization’s policies.

Resolving Blocked Device Access State for Test CAS User

For a device that has been blocked with a reason of “Policy”, the likely issue is the ActiveSync mailbox policy associated with the mailbox is too strict for the capabilities of the Test-ActiveSyncConnectivity cmdlet.

To resolve this, configure an ActiveSync mailbox policy that allows non-provisionable devices with no password requirement.


Assign that ActiveSync mailbox policy to the test account.

Depending on your environment there may be some delay before this takes effect. After running Test-ActiveSyncConnectivity again you should see a successful test result.

Resolving Quarantined Device Access State Due to Organization Policy

If you have a the default access level for ActiveSync in your organization set to “Quarantine” you may see a different result from Test-ActiveSyncConnectivity.

Look at the ActiveSync devices for the test mailbox, and you will likely see that the device has been quarantined.

Before addressing this, you should first review the existing allowed device IDs for the test user.

If there are no device IDs already specified, add the device ID that you discovered above as an allowed device ID for the test user.

If there were already device IDs allowed a slightly different approach is taken. Each server or management workstation that you run the Test-ActiveSyncConnectivity cmdlet from will have a different device ID. Over time you may need to allow multiple device IDs.

To append a new device ID to the existing list run the following command instead.

Test-ActiveSyncConnectivity should now run successfully.

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: Exchange Server


  1. Seb says:


    I encountered a similar error 403 because my “extest…” account had reached the maximum number of ActiveSync devices authorized by the default throttling policy (10 devices).

    I deleted some ActiveSync Devices for my test account.

    And now it works fine.

  2. Carol Ostos says:

    Thanks for the article Paul. I’m troubleshooting the following event that has started appearing in one of my CAS servers since Friday.

    1040 Warning MSExchange ActiveSync

    The average of the most recent heartbeat intervals [494] for request [Sync] used by clients is less than or equal to [540].
    Make sure that your firewall configuration is set to work correctly with Exchange ActiveSync and direct push technology. Specifically, make sure that your firewall is configured so that requests to Exchange ActiveSync do not expire before they have the opportunity to be processed.

    For more information about how to configure firewall settings when using Exchange ActiveSync, see Microsoft Knowledge Base article 905013, “Enterprise Firewall Configuration for Exchange ActiveSync Direct Push Technology”

    I have asked one of the guys to check TMG firewall rules to see if increasing the time out helps.

    After applying the TestOnly EAS Policy to the exchange test account, Test-ActiveSyncConnectivity works like a charm


    CasServer LocalSite Scenario Result Latency(MS) Error
    ——— ——— ——– —— ———– —–
    cas… HQ Options Success 15.60
    cas… HQ FolderSync Success 93.60
    cas… HQ First Sync Success 46.80
    cas… HQ GetItemEstimate Success 31.20
    cas… HQ Sync Data Success 78.00
    cas… HQ Ping Success 2070.06
    cas… HQ Sync Test Item Success 62.40

    I know its just a warning but you think I should worry if this event does not go away? Thanks!

  3. Valentin says:


    Something strange appeared for me.
    After following the guide the issue with folder sync error was resolved but another error appeared.
    The test is running against 12 CAS servers from one workstation only.
    The activesync devices were allowed but the test is failing on 4 from the 12 CASes. And this 4 CASes IDs are changing. The error:

    ScenarioDescription : Issue an HTTP OPTIONS command to retrieve the Exchange ActiveSync protocol version.
    PerformanceCounterName : DirectPush Latency
    Result : Failure
    Error : The OPTIONS command returned HTTP 200, but the Exchange ActiveSync header (MS-Server-ActiveSync) wasn’t returned. The request likely did not reach a Client Access serv
    , either because

    – A proxy server intervened (check the headers below for any that may have been returned by a proxy)

    -The virtual directory could not be reached: https://XXXXX.XXXX.XXX/Microsoft-Server-ActiveSync

    – The virtual directory does not point to a Client Access server: https://XXXXX.XXXX.XXX/Microsoft-Server-ActiveSync

    HTTP response headers:

    Content-Length: 0
    Date: Wed, 16 Oct 2013 09:21:21 GMT
    Server: Microsoft-IIS/7.5
    X-Powered-By: ASP.NET

    In 30minutes start working for the same server but have the error for other – always following the pattern 4 failures from 12 🙂

  4. Glen says:

    Thank Paul, your blogs regarding Exchange helped me a lot. Especially this article which talks exactly about the issue I was having about the FolderSync. Thanks again

  5. Rekha Joshi says:

    Thanks for the article, I had a different issue when I run “Test-ActiveSyncConnectivity”
    “Warning: Test user “extest_xxxxxxxx” was not accessible, so this cmdlet won’t be able to test client access server connectivity”

    from the script folder ran the command to create a new test account – “Creating a Test CAS User” from this article.
    This enabled back the existing account which was showing up in warning & the test of ActiveSyncConnectivty went through smoothly..

  6. Navneet says:

    Hello Paul,

    We are looking to clear up the stale active sync devices
    so one user called test as mention in your article. is it safe to remove that account device also. as last success sync was 2 year ago

    Please suggest

Leave a Reply

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