Skip to content

Est. 2011·Microsoft Partner 7033487·Delivery under 3 min·Support 7 days a week

Your vault is empty.

Free Fix Event ID 1053

Event ID 1053: ActiveSync lacks permission to create the device container

11 min read Updated October 4, 2026 Exchange Server

Fix it now

Event 1053 says ActiveSync does not have sufficient permissions to create the device container under a user’s Active Directory object. Microsoft’s documented cause is that the Exchange Servers group can create and delete the msExchActiveSyncDevices object but cannot change permissions on it, and the fix is to grant that group Modify Permissions on descendant objects of that class.

  1. Read the event and note which account it names. That is the mailbox whose device cannot sync.
  2. Open Active Directory Users and Computers and turn on Advanced Features from the View menu.
  3. Right-click the object you want to change permissions at – the user, the organisational unit, or the domain – and choose Properties, then Security, then Advanced.
  4. Select Add, type Exchange Servers, and select OK. In the Apply to box choose Descendant msExchActiveSyncDevices objects, and under Permissions tick Modify Permissions.
  5. Select OK three times, then ask the device to sync again. No Exchange restart is needed: the next attempt creates the container.

Apply this at the organisational unit or the domain rather than one user at a time if the event names more than one account. The permission is inherited down to the objects that need it.

If the device syncs and no new 1053 appears, you can stop. If the permission reverts, or the event names accounts in one part of the directory only, the next section explains both.

Why it happens

Each ActiveSync partnership is stored in Active Directory as an object beneath the user, of the class msExchActiveSyncDevices, in a container Exchange creates the first time that mailbox syncs a device. Without the container the partnership is never recorded, and without a partnership the sync cannot proceed, so the device is refused. Event 1053 is Exchange reporting that the directory refused the creation, and the event text spells the failure out: access is denied, with the Active Directory response naming INSUFF_ACCESS_RIGHTS.

The event goes on to say what to check: that the user has inherited permission granted to the Exchange Servers group to allow List, Create child and Delete child of object type msExchActiveSyncDevices, and that no deny permission blocks those operations. That is the sentence most people act on, and it is not wrong. It is also not the whole story.

Microsoft’s article on this event names a narrower cause. By default the Exchange Servers group has rights to create and delete msExchActiveSyncDevices objects, but not to change permissions on them; permission changes are inherited from the Owner Rights security principal, which should hold Full control by default. Where Owner Rights does not have it, creation fails even though the create rights themselves look correct. The published fix is to grant the Exchange Servers group Modify Permissions on descendant msExchActiveSyncDevices objects, applied at the user, the organisational unit or the domain.

Inheritance still matters, because the permission has to reach the object. If inheritance is switched off on a user object, nothing granted above it arrives, and that produces the same event. What is different is the fix worked and then stopped working pattern: accounts in protected groups carry an adminCount value and have their permissions rewritten from the AdminSDHolder template on a schedule, with inheritance deliberately off. That is a security mechanism working as designed, and turning inheritance back on by hand is undone at the next pass.

The Exchange Servers group cannot modify permissions on the device object

You have this one if The event names one or more accounts, inheritance looks normal on them, and the Exchange Servers group appears to have create rights already.

  1. In Active Directory Users and Computers with Advanced Features on, open the Security tab of the user, organisational unit or domain and select Advanced.
  2. Add the Exchange Servers group.
  3. Set Apply to: Descendant msExchActiveSyncDevices objects.
  4. Tick Modify Permissions, then apply and retry the device.

This is Microsoft’s documented resolution for this event. Do it at the highest sensible scope so new mailboxes inherit it rather than reappearing on this list next month.

Inheritance has been switched off on the user object

You have this one if One user is affected, everyone else is fine, and the Advanced Security dialog shows inheritance disabled for that object alone.

  1. Enable inheritance on the object from the Advanced Security dialog and apply.
  2. Ask the device to sync again; no restart is needed.
  3. Find out who disabled it, because a script or a delegation exercise that ran once will run again.
  4. Confirm an hour later that inheritance is still enabled, which distinguishes this from the protected-group case.

Enabling inheritance adds the permissions that flow from above. It does not remove an explicit permission already on the object.

The account is in a protected group

You have this one if The change reverts within about an hour, and the account is a member of a group such as Domain Admins or Account Operators.

  1. Find the affected accounts: Get-ADUser -Filter "adminCount -eq 1" -Properties adminCount,MemberOf.
  2. Decide which of them genuinely need to be privileged. Most historical memberships do not survive that question.
  3. Where the membership is not needed, remove it, then clear the adminCount value and re-enable inheritance – in that order.
  4. Where the account must stay privileged, give the person a separate ordinary account for mail and move the mailbox to it.

AdminSDHolder exists so that a delegated permission elsewhere cannot be used to take over a privileged account. Working around it for a phone is the wrong trade.

Inheritance is blocked at the organisational unit

You have this one if Every mailbox in one organisational unit fails while the rest of the organisation is fine, and none of the accounts is privileged.

  1. Check the organisational unit’s own Advanced Security dialog for blocked inheritance.
  2. Re-enable it, or add the required permissions explicitly at that unit if the block was deliberate.
  3. Retest with one mailbox in the unit before assuming it is fixed for all of them.
  4. Record why the block exists, because someone put it there for a reason worth knowing.

The device is refused for a policy reason rather than a permission one

You have this one if No 1053 events appear at all, but devices receive HTTP 403 while the mailbox works normally in Outlook and the browser.

  1. Check the mailbox: Get-CASMailbox <user> | Format-List ActiveSyncEnabled,ActiveSyncBlockedDeviceIDs.
  2. Check organisation defaults and any device access rules that quarantine or block a device family.
  3. Allow the specific device if it should be allowed, then let it complete one full synchronisation.
  4. Remember that a device shown 0x85010004 is being told E_HTTP_FORBIDDEN, which is this branch rather than a permission fault in the directory.

Full reference

Telling the permission fault from its neighbours

What you observe What it points at
One user affected, everyone else fine Inheritance disabled on that user object, or the Modify Permissions grant missing
The fix reverts within about an hour The account is in a protected group and AdminSDHolder is rewriting it
Everyone in one organisational unit affected Inheritance blocked at that unit
The device receives HTTP 403 The server is refusing the device: access rules or the mailbox’s ActiveSync state
The device receives HTTP 401 Authentication, which is a different problem entirely
The device receives HTTP 451 A redirect to a different server, with the URL in the X-MS-Location header
Every user affected at once Not this event. Look at the virtual directory or its application pool

The permission, written out

Field Value
Where The user, the organisational unit, or the domain – whichever scope the failures share
Principal Exchange Servers
Apply to Descendant msExchActiveSyncDevices objects
Permission Modify Permissions
Prerequisite Advanced Features turned on in the View menu of Active Directory Users and Computers

The reason this is needed is worth understanding rather than memorising. Exchange is allowed to create and delete the device object; what it is not allowed to do by default is change permissions on it, and that ability normally arrives through the Owner Rights principal holding Full control. Where a hardening exercise or a delegation model has taken Owner Rights away, creation fails with an access denied that looks like a missing create right.

HTTP 451, which is not an error

If devices report a redirect rather than a failure, that is the protocol working. The Exchange ActiveSync HTTP documentation states that a 451 is returned when the client is connecting to a server that cannot reach the user’s mailbox, or where a more efficient server exists. If the response carries an X-MS-Location header, subsequent requests should use the URL in that header; if it does not, the device repeats the full Autodiscover process. A device that follows the redirect and syncs is behaving correctly.

Finding every account this will affect

  1. Run Get-ADUser -Filter "adminCount -eq 1" -Properties adminCount,MemberOf and read the list rather than skimming it.
  2. Separate the service accounts from the people. Service accounts rarely have mailboxes and rarely matter here.
  3. For each person on the list, ask whether the privileged membership is still needed. Most were granted for a project that ended.
  4. For those that are needed, plan a separate ordinary account for mail rather than an exception to AdminSDHolder.
  5. Re-run the query a month later. This list grows quietly.

Clearing adminCount and re-enabling inheritance while the group membership is still in place achieves nothing: the next AdminSDHolder pass puts both back. Remove the membership first, then clear the attribute, then re-enable inheritance.

What not to do

  • Do not grant the Exchange Servers group broad rights over user objects to make the event stop. The documented permission is narrow on purpose.
  • Do not disable AdminSDHolder or exclude groups from it so that an administrator’s phone syncs. The mechanism is protecting the account from exactly the kind of delegated permission you would be adding.
  • Do not delete and recreate the user object. It changes the SID and takes the mailbox, the group memberships and every permission with it.
  • Do not remove and re-add the device account on the phone before fixing the directory. The next partnership fails in the same way.

Every code this article covers

Code What it points at Source
Event ID 1053 MSExchange ActiveSync: Exchange ActiveSync does not have sufficient permissions to create the device container under the user’s Active Directory object; the directory answered with INSUFF_ACCESS_RIGHTS Microsoft Learn
HTTP 403 Forbidden: the server understood the request and refused it Microsoft Learn
HTTP 401 Access denied: the request was not authenticated Microsoft Learn
HTTP 451 An ActiveSync redirect, returned when the client is connecting to a server that cannot reach the mailbox or where a better one exists. The target is in the X-MS-Location header Microsoft Learn

Confirm the fix worked

  1. Trigger a sync on the affected device and confirm no new Event ID 1053 appears.
  2. Get-MobileDeviceStatistics -Mailbox <user> shows a recent successful sync.
  3. The Exchange Servers group shows Modify Permissions on descendant msExchActiveSyncDevices objects at the scope you applied it.
  4. Reopen the account’s Advanced Security dialog an hour later and confirm inheritance is still enabled.
  5. Re-run the adminCount query and confirm no mailbox-enabled account is stamped unnecessarily.

Questions people ask about this

Does this cost anything to put right?

No. It is a directory permissions change on infrastructure you already run, and it takes minutes. Nobody needs to buy anything to make a phone sync again.

Is re-enabling inheritance enough on its own?

Sometimes, and it is worth checking. But Microsoft’s documented cause for this event is narrower: the Exchange Servers group can create the device object and cannot change permissions on it, because the Owner Rights principal has lost Full control. Granting Modify Permissions on descendant msExchActiveSyncDevices objects is the published fix.

Why does it only affect our administrators?

Because they are the accounts in protected groups. AdminSDHolder deliberately strips inherited permissions from those accounts so that a delegated permission elsewhere cannot be used to take one over, and it restores that state on a schedule.

Is enabling inheritance a security risk?

On an ordinary user account, no: it restores the permission model every other user already has. On a privileged account it works against a protection that exists for good reason, which is why moving the mailbox off that account is the better answer.

Should administrators have mailboxes on their admin accounts at all?

Preferably not. Separating day-to-day mail from privileged access avoids this problem entirely and removes a large amount of risk at the same time. It is the single change most likely to stop this recurring.

Related error codes

Was this article helpful?

Your feedback helps us improve our documentation.

Related articles

Free Fix MapiExceptionLogonFailed: the store rejects a MAPI logon for this mailbox License Error Error -1018 JET_errReadVerifyFailure: page checksum damage in a mailbox database Free Fix TooManyBadItemsPermanentException: the move stops on corrupt mailbox items Free Fix 441 4.4.1 and 471 4.4.1: Exchange cannot hold a connection to the target host
← Back to Knowledge Base