Exchange 2007 /prepareschema and inherited permissions in AD



This is my first ever blog (welcome to 2002 Craig!).

I have just visited a customer who had a big mail flow problem immediately after they ran /prepareschema for Exchange Server 2007. Lets look at why.

prepareschema is the process you first run to add new attributes to the schema. A list of all the changes made during Exchange 2007 to the directory are detailed here:

Two of the new "attributes" it adds are "property-sets". These are a collection of attributes specific to Exchange Server information and to Personal Information as it relates to Exchange. These are used so that when you apply delegation to allow administrators edit attributes of objects, they only need one ACE entry. ACLs which have many ACEs are dangerous as once they become large, they stop allowing access to the objects.

Why is this important to this case? An attribute can only be a member of ONE property-set. So, in order to add an Exchange-specific property set, Exchange /prepareschema will remove the old property-set.

In our case, the customer had disabled inheritance of permissions on some AD objects (more on that below). Because the inheritance wasn't enabled, the new delegation performed by Exchnage /prepareschema didn't pass down to all the required objects. The objects maintained an ACL with a "dud" ACE for the old property-sets, which have been deleted.

The 4 ACEs were (approximately):

  • Authenticated Users: READ: Personal Information
  • Authenticated Users: READ: Private Information
  • Exchange Enterprise Servers: READ: Personal Information
  • Exchange Enterprise Servers: READ: Private Information

What they were missing were the equivalent ACEs for the new Exchange 2007 property sets, which they would have had if the inheritance was permitted.

Here's the official explanation of Exchange property-sets:


But why the big fuss? Well, when an authenticated user (i.e. a user with a mailbox who has logged onto Exchange or an anonymous internet user using the credentials of the Exchange Server who first received the message) sent a message to one of these objects, because the users/servers credentials are used to determine the access rights to the object for the end destination, they were getting NDRs saying the end destinations' email address has become missing. This was because they had no permission to read important details about the end destination, like proxyAddresses, altRecipient and so on.

The objects we are talking about for this case are AD objects for each mail-enabled public folder. PFs which are not mail-enabled do not need an object in AD. The object in AD is needed for the attributes mentioned above, things like proxyAdresses and altrecipient.

These objects are held in the "MESO" container:

"CN=Microsoft Exchange System Objects,DC=DOMAIN,DC=NAME"

There were around 81,000 of them. Running dsacls over multiple high-spec'ed DCs we were able to add the relevant permissions in 6hrs.

The reasons /prepareschema doesn't check the inheritance flag of these objects first are:

  1. It is "unsupported" to disable inheritance of these objects in AD - the product needs to be able to make some assumptions about the state of AD, this is one of those assumptions
  2. If the process checked the inheritance of all those objects, it would appear to hang for many hours potentially running the risk that the schema admin may prematurely terminate the schema upgrade, leaving AD in a "messy" state.

To find out if you have any objects in AD which don't have inheritance enabled, you can run the following command on each domain:

adfind -b "DC=domain,DC=name" -sddl++ ntsecuritydescriptor -onlydaclflag -resolvesids -list -csv | find /i "(FLAGS:PROTECTED INHERIT)" | find /v /i "CN=Policies,CN=System"

adfind.exe is one of many great tools from

Skip to main content