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

Learn even more in the Beginner's Guide to Exchange Server 2010 ActiveSync. Grab your copy here.

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.

.\new-TestCasConnectivityUser.ps1 -ou "Service Accounts"
Please enter a temporary secure password for creating test users. For security
purposes, the password will be changed regularly and automatically by the system
if SCOM is installed. The password must be changed manually if SCOM is not installed.
Enter password: ***********
Create test user on: HO-EX2010-MB1.exchangeserverpro.net
Click CTRL+Break to quit or click Enter to continue.:
UserPrincipalName: extest_0bcca07661e94@exchangeserverpro.net

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.

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.

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.

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

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: