Active Directory property homeMDB is not writeable on recipient

During an Exchange 2013 migration project the  first attempt to migrate a mailbox failed with the following error:

Error: MigrationPermanentException: Active Directory property 'homeMDB' is not writeable on recipient 'testing.local/Users/Dummy'. --> Active Directory property 'homeMDB' is not writeable on recipient 'testing.local/Users/Dummy'.

The error message clearly stated, that this was a permission issue. A quick search pointed me to the right direction. I found a thread in the TechNet forums, in which the same error message were discussed. This error occurs, if the Exchange Trusted Subsystem group is missing in the ACL of the user object. This group contains the exchange server and it’s usually inherited from the domain object to all child containers and objects. I checked the ACL of the user and the Exchange Trusted Subsystem group was missing in the ACL. This was caused by the disabled permissions inheritance. An object ACL with disabled permissions inheritance is sometimes called a protected ACL. Bill Long wrote a nice Power Shell script to search for object which have permissions inheritance disabled.

How to enable permissions inheritance?

Start the Active Directory Users and Computers MMC. Click “View” and enable “Advanced Features”. Otherwise the needed tabs will not shown.

Patrick Terlisten/ vcloudnine.de/ Creative Commons CC0

Patrick Terlisten/ vcloudnine.de/ Creative Commons CC0

Open the user that can’t be migrated. Switch to the “Security” tab. Click “Advanced” and enable the “Include inheritable permissions from this object’s parent” check box. Click “OK” and confirm popups regarding added ACL entries.

Patrick Terlisten/ vcloudnine.de/ Creative Commons CC0

Patrick Terlisten/ vcloudnine.de/ Creative Commons CC0

Check if the Exchange Trusted Subsystem group is now part of the ACL. If yes, try the migration of the mailbox again.

Why is  permissions inheritance disabled?

Good question, the customer asked me the same question. But the answer is easy. As above mentioned, is a ACL with disabled permission inheritance called a protected ACL. When should a ACL be protected? If the ACL of the associated object shouldn’t be changed, when a permission from a parent object is inherited. A good example for such an object is the Administrator account. Active Directory protects members of the following groups

  • Enterprise Admins
  • Schema Admins
  • Domain Admins
  • Administrators
  • Account Operators
  • Server Operators
  • Print Operators
  • Backup Operators
  • Cert Publishers

and the following users

  • Administrator
  • krbtgt

with three simple steps:

  1. Set the value of the AdminCount attribute to 1.
  2. Disable permission inheritance
  3. Apply permissions from the AdminSDHolder template

This process runs once an hour on a Active Directory Domain Controller and recovers the ACL of the two user accounts and the member accounts of the mentioned groups to a protected state and well-known permissions. What happens if you add an user account to the Domain Admins group? AdminCount is set to 1, the permission inheritance is disabled and the permissions specified in the AdminSDHolder template are applied. If you remove the user account from the Domain Admins group, the changes are not rolled back and so  permission inheritance stays disabled! Changes to parent ACLs are not applied to the user account and, in the case of my customer, the Exchange Trusted Subsystem group wasn’t added to the user objects ACL.

You can search for accounts with AdminCount=1 easily with the PowerShell:

PS C:UsersAdministrator> ([adsisearcher]"(AdminCount=1)").findall()

Path                                                        Properties
---- ----------
LDAP://CN=Administrator,CN=Users,DC=testing,DC=local        {msexchrecipientdisplaytype, logoncount, codepage, objec...
LDAP://CN=Administrators,CN=Builtin,DC=testing,DC=local     {objectcategory, usnchanged, distinguishedname, grouptyp...
LDAP://CN=Print Operators,CN=Builtin,DC=testing,DC=local    {iscriticalsystemobject, usnchanged, distinguishedname, ...
LDAP://CN=Backup Operators,CN=Builtin,DC=testing,DC=local   {iscriticalsystemobject, usnchanged, distinguishedname, ...
LDAP://CN=Replicator,CN=Builtin,DC=testing,DC=local         {iscriticalsystemobject, usnchanged, distinguishedname, ...
LDAP://CN=krbtgt,CN=Users,DC=testing,DC=local               {logoncount, codepage, objectcategory, description...}
LDAP://CN=Domain Controllers,CN=Users,DC=testing,DC=local   {usnchanged, distinguishedname, grouptype, whencreated...}
LDAP://CN=Schema Admins,CN=Users,DC=testing,DC=local        {objectcategory, usnchanged, distinguishedname, grouptyp...
LDAP://CN=Enterprise Admins,CN=Users,DC=testing,DC=local    {objectcategory, usnchanged, distinguishedname, grouptyp...
LDAP://CN=Domain Admins,CN=Users,DC=testing,DC=local        {objectcategory, usnchanged, distinguishedname, grouptyp...
LDAP://CN=Server Operators,CN=Builtin,DC=testing,DC=local   {iscriticalsystemobject, usnchanged, distinguishedname, ...
LDAP://CN=Account Operators,CN=Builtin,DC=testing,DC=local  {iscriticalsystemobject, usnchanged, distinguishedname, ...
LDAP://CN=Read-only Domain Controllers,CN=Users,DC=testi... {usnchanged, distinguishedname, grouptype, whencreated...}

Why is this a problem? With AdminCount=1 and disabled permission inheritance you will face a lot of problems:

  • Changes to an object ACLs are rolled back after an hour
  • Send-As doesn’t work
  • ActiveSync doesn’t work
  • Language settings in Outlook Web Access isn’t saved
  • ..and some other nasty effects

I have seen this error so often. Mostly at customers, that use normal work accounts for administrative tasks, or that add normal user accounts to admin groups during the setup of new profiles or clients. The solution is easy: Don’t do it!