ActiveSync not syncing on Exchange Server: quarantine, Event ID 1053 and HTTP errors

When phones stop syncing with Exchange Server, the cause is usually one of three things: device access rules quarantined or blocked the phone, Exchange can't create the device partnership in Active Directory, or the request fails at the HTTP layer before it reaches the mailbox. In this post I'll show how to tell which one you have from Get-MobileDevice, the Application log and the IIS log, and how to fix each.

Symptoms#

• A new phone never finishes setup or shows no mail; existing phones stop updating.
• A quarantined phone shows a single message saying it can't sync until an administrator allows it.
• Get-MobileDevice shows DeviceAccessState : Quarantined or Blocked.
• The first sync for some users, often administrators, fails and the Application log records:

Source:   MSExchange ActiveSync
Event ID: 1053
Exchange ActiveSync doesn't have sufficient permissions to create the "CN=Jane Admin,OU=Admins,DC=contoso,DC=com"
container under Active Directory user "Active Directory operation failed on DC01.contoso.com. This error is not
retriable. Additional information: Access is denied.
Active directory response: 00000005: SecErr: DSID-xxxxxxxx, problem 4003 (INSUFF_ACCESS_RIGHTS), data 0".
Make sure the user has inherited permission granted to domain\Exchange Servers to allow List, Create child,
Delete child of object type "msExchangeActiveSyncDevices" and doesn't have any deny permissions that block such operations.

Why it happens#

• Device access control. Each new device is checked against the user's own allowed and blocked device IDs, then the organization's device access rules (matching device type, model, OS or user agent), and finally the default access level. With DefaultAccessLevel set to Quarantine and no matching rule, every new phone waits for an administrator.
• Active Directory permissions. On a device's first sync, Exchange creates an msExchActiveSyncDevices container under the user object and then changes permissions on it. If the user object doesn't inherit the Exchange Servers permissions, or the domain's Owner Rights permissions were tightened, that fails with Event ID 1053. Protected accounts (adminCount = 1) are the classic case, because AdminSDHolder turns off inheritance on them.
• Protocol and policy. The user isn't enabled for ActiveSync, the phone can't apply the mobile device mailbox policy, the sign-in name is wrong, or the server or load balancer fails the request.

How to fix it#

1. Read the device's state#

Get-MobileDevice -Mailbox jane@contoso.com |
    Format-List FriendlyName, DeviceId, DeviceType, DeviceAccessState, DeviceAccessStateReason, DeviceAccessControlRule
Get-MobileDeviceStatistics -Mailbox jane@contoso.com | Format-List DeviceId, LastSuccessSync, LastSyncAttemptTime, Status
Get-CASMailbox jane@contoso.com | Format-List ActiveSyncEnabled, ActiveSyncMailboxPolicy, ActiveSync*DeviceIDs

DeviceAccessStateReason tells you who made the decision: Global is the organization default, DeviceRule is an access rule (named in DeviceAccessControlRule) and Individual is the user's own allow or block list. ActiveSyncEnabled must be True. No phone listed at all means no partnership was created: check the IIS log (step 4) and look for Event ID 1053.

2. Release or allow quarantined devices#

Get-ActiveSyncOrganizationSettings | Format-List DefaultAccessLevel, AdminMailRecipients
Get-ActiveSyncDeviceAccessRule | Format-Table Name, Characteristic, QueryString, AccessLevel -AutoSize

# Allow one device for one user
Set-CASMailbox jane@contoso.com -ActiveSyncAllowedDeviceIDs @{Add="<DeviceId>"}

# Or allow a device family (copy the exact DeviceType value from Get-MobileDevice)
New-ActiveSyncDeviceAccessRule -Characteristic DeviceType -QueryString "iPhone" -AccessLevel Allow

In the Exchange admin center the same list lives under Mobile › Mobile device access, where quarantined devices can be allowed or blocked. If you use quarantine on purpose, set AdminMailRecipients so someone is actually told about new devices.

3. Fix Event ID 1053#

Get-ADUser jane.admin -Properties adminCount, nTSecurityDescriptor |
    Select-Object Name, adminCount, @{n="InheritanceBlocked"; e={ $_.nTSecurityDescriptor.AreAccessRulesProtected }}

InheritanceBlocked = True means the user object doesn't inherit permissions from its OU. In Active Directory Users and Computers, turn on View › Advanced Features, open the user's Properties › Security › Advanced and select Enable inheritance (older consoles: Include inheritable permissions from this object's parent). Allow AD replication, then have the user retry.

If adminCount is 1, AdminSDHolder resets the permissions about every hour, so the change won't stick. The clean fix is a separate, non-privileged account for the mailbox on the phone. Admins report that once the device container exists, sync keeps working after the reset, but don't build on that. If inheritance is already on, Microsoft's Event ID 1053 article covers the Owner Rights cause and the permission the Exchange Servers group needs.

4. Read the IIS log#

$log = Get-ChildItem C:\inetpub\logs\LogFiles\W3SVC1\*.log | Sort-Object LastWriteTime | Select-Object -Last 1
Select-String -Path $log.FullName -Pattern "Microsoft-Server-ActiveSync.*jane" | Select-Object -Last 10

Each line shows the command (Cmd=Sync, Cmd=Ping, Cmd=FolderSync), the device ID and type, and the HTTP status near the end:

Get-ActiveSyncVirtualDirectory | Format-List Server, ExternalUrl, BasicAuthEnabled, WindowsAuthEnabled, ClientCertAuth
Get-MobileDeviceMailboxPolicy | Format-List Name, IsDefault, AllowNonProvisionableDevices

Most native mail apps sign in with Basic authentication, so BasicAuthEnabled should be True. If users sign in with their email address and it differs from their UPN, Microsoft's ActiveSync walkthrough suggests adding the UPN suffix or changing the UPN.

5. Test the service#

• Run the Exchange ActiveSync test on the Exchange Server tab of the Microsoft Remote Connectivity Analyzer with a test account.
• Test-ActiveSyncConnectivity -ClientAccessServer EX01 -MailboxCredential (Get-Credential) -TrustAnySSLCertificate is a quick smoke test, but Microsoft notes it works best on Exchange 2010; on later versions also check Get-HealthReport EX01 | Where-Object { $_.HealthSet -like "ActiveSync*" }.
• For one stubborn device, enable mailbox logging with Set-CASMailbox jane@contoso.com -ActiveSyncDebugLogging $true, reproduce the problem, collect it with Get-MobileDeviceStatistics -Mailbox jane@contoso.com -GetMailboxLog -NotificationEmailAddresses admin@contoso.com, then turn logging off.

Verify the fix#

• Get-MobileDevice shows DeviceAccessState : Allowed and LastSuccessSync keeps moving forward.
• The IIS log shows Cmd=Sync and Cmd=Ping requests returning 200.
• No new Event ID 1053 appears when the next user adds a phone.

Prevent it next time#

• Choose the default access level deliberately and document your access rules.
• Keep privileged admin accounts off phones; give admins a separate everyday mailbox account.
• Remove partnerships for retired phones with Remove-MobileDevice so device lists stay accurate.
• Probe /Microsoft-Server-ActiveSync/healthcheck.htm on the load balancer.
• Outlook for iOS and Android against on-premises mailboxes? Check Hybrid Modern Authentication too.

References#

• Event ID 1053: Exchange ActiveSync doesn't have sufficient permissions to create container (Microsoft Learn)
• Troubleshoot ActiveSync with Exchange Server (Microsoft Learn)
• Test-ActiveSyncConnectivity (Microsoft Learn)