HOW TO: Delegate recipient administration for an OU

by Bharat Suneja

Exchange Server 2007 allows easier delegation of administration responsibilities, based on the following predefined administration roles:
1) Exchange Organization Administrator
2) Exchange Server Administrator
3) Exchange Recipient Administrator
4) Exchange Public Folder Administrator and
5) Exchange View Only Administrator.

Figure 1: Exchange Server 2007 allows delegation of administrative responsibilities

The delegation wizard in the EMC allows you to delegate the Recipient Administrator role for the entire Organization, but doesn’t allow more granular delegation at the Domain or OU level.

More about the Exchange Recipient Administrator role

Security principals that have the Exchange Recipient Administrator role delegated get membership of the Exchange View Only Administrators role. Additionally, they are assigned:
Read access to all the Domain Users containers in AD (in domains where Setup /DomainPrep has been run)
Write access to all the Exchange-specific attributes in those domains

When delegating the Exchange Recipient Administrator role using the Exchange console or the Add-ExchangeAdministrator command in the Exchange shell, all you’re doing is adding the security principal (user/group) to Exchange Recipient Administrators, a (Universal) Security Group in the Microsoft Exchange Security container in AD.

For more details about Exchange Server 2007 permissions, refer to “Configuring Permissions in Exchange Server 2007“.

Here’s how you can delegate recipient administration for an OU.
Exchange Organization: E12Labs
Domain: (DC=E12Labs,DC=com)
OU: San Francisco (OU=San Francisco,DC=E12Labs,DC=com)
User: foo (Best Practice: Assign permissions to Security Groups)

1 Allow generic read permission for objects in the OU:

Add-ADPermission -Identity “ou=San Francisco,dc=E12Labs,dc=com” -User “E12Labs\foo” -AccessRights GenericRead

2 Allow ReadProperty and WriteProperty permissions on Exchange-related attributes for objects in the OU

Add-ADPermission –Identity “ou=San Francisco,dc=E12Labs,dc=com” –User “E12Labs\foo” -AccessRights ReadProperty, WriteProperty -Properties Exchange-Information, Exchange-Personal-Information, legacyExchangeDN, displayName, adminDisplayName, displayNamePrintable, publicDelegates, garbageCollPeriod, textEncodedORAddress, showInAddressBook, proxyAddresses, mail

Property Sets in Active Directory

Exchange-Information and Exchange-Personal-Information are property sets – a number of related properties grouped together. Assigning permissions on a property set results in a single ACE in DACLS, making them much smaller and faster to process.

Exchange Server 2003 adds Exchange attributes to the Public Information and Private Information property sets that exist in Active Directory.

Exchange Server 2007 does not rely on these existing AD property sets, but creates 2 of its own. If deploying in an existing Exchange 2003 Forest, Exchange Server 2007 removes the Exchange properties added to the AD property sets and adds them to the new Exchange 2007 property sets. The Exchange-Information property set has 105 properties. Exchange-Personal-Information has 7. More information about the Exchange Server 2007 property sets and which properties are included in them can be found in “Property Sets in Exchange 2007“.

3 Allow creation and management of Dynamic Distribution Groups in the OU
Exchange Server 2007 RTM:

Add-ADPermission -Identity “ou=San Francisco,dc=E12Labs,dc=com” -User “E12Labs\foo” -AccessRights GenericAll –InheritanceType Descendents -InheritedObjectType msExchDynamicDistributionList

Add-ADPermission -Identity “ou=San Francisco,dc=E12Labs,dc=com” -User “E12Labs\foo” -AccessRights CreateChild, DeleteChild -ChildObjectTypes msExchDynamicDistributionList

Exchange Server 2007 SP1:

Add-ADPermission -Identity “ou=San Francisco,dc=E12Labs,dc=com” -User “E12Labs\foo” -AccessRights CreateChild, DeleteChild -ChildObjectTypes msExchDynamicDistributionList

4 Allow permission to access RUS:

Add-ADPermission -Identity “CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=E12Labs,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=E12Labs,DC=com” -User “E12labs\foo” -InheritedObjectType ms-Exch-Exchange-Server -ExtendedRights ms-Exch-Recipient-Update-Access -InheritanceType Descendents

5 Allow permission to update Address Lists and Email Address Policies:

Add-ADPermission –Identity “CN=Address Lists Container,CN=E12Labs,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=E12Labs,DC=com” –User “E12Labs\foo” -AccessRights WriteProperty -Properties msExchLastAppliedRecipientFilter, msExchRecipientFilterFlags

Add-ADPermission –Identity “CN=Recipient Policies,CN=E12Labs,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=E12Labs,DC=com” –User “E12Labs\foo” -AccessRights WriteProperty -Properties msExchLastAppliedRecipientFilter, msExchRecipientFilterFlags

6In addition to these Active Directory permissions, recipient administrators also need Exchange View Only Administrator permission on the Exchange Organization. Use the following command to assign it:

Add-ExchangeAdministrator “E12Labs\foo” -Role ViewOnlyAdmin

A script for SP1: If you’re on Exchange Server 2007 SP1, a script written by Ross Smith IV makes delegating recipient administration permissions on an OU a simple task accomplished quickly (No, it’s not for Exchange Server 2007 RTM). The script – Confi
, resides in the \Scripts folder in the Exchange Server install path. Usage:

.\ConfigureSplitPerms.ps1 -user “MyDomain\foo” -identity “OU=San Francisco,DC=ExchangeLabs,DC=net”

{ 5 comments… read them below or add one }

Anonymous March 14, 2008 at 9:39 am

Good article, thanks for that. One thing I am finding though is that recipient admins cannot create new mailboxes. The cannot view any of the stores when running through the wizard. Is this working by design and I need to add additional permissions?


Anonymous August 8, 2008 at 12:56 pm

Thanks for the info,

I was able to delegate user and contact creation on the OU, that will allow you to create a mailbox for a non-existant user, and allow you to create contacts.

The problem I am having is on the delete side. When I delete a mailbox, the mailbox goes away and shows up in disconnected, also the AD user object is deleted too.

But I still get the error:
Action ‘Disable’ was performed successfully on object ‘testuser3’, but there are some warning(s).


Failed to commit the change on object “4166edc3-4017-4b60-a699-f6b6f7c6c718” because access is denied.

I get the same error when I delete or disable the mailbox.



Anonymous October 15, 2008 at 11:37 pm

I get exactly the same symptoms as above.
My Exchange Recipient Administrators group did not properly apply permissions from the install. I re-applied them using the script above but get the same warning on disabling mailboxes.


[email protected] December 30, 2008 at 1:17 am


Good Article and Helped us a lot in Split Permission configuration for department admins.

Department admins can create and delete accounts.
But with the scripts , Manage Full Permission cannot be delegated.

How do we accomplish delegation. Is it really requires more permission


Anonymous June 9, 2009 at 2:03 pm

Hi Bharat,

Thanks for this detailed article with step-by-step intructions – I was able to easily carry out the instructions.

Its interesting how in Exchange 2007, they have defined roles that we can delegated using security groups. We came across a situation where we needed to know precisely who all can perform Exchange management, and that turned out to be a little hard to determine.

Fortunately, we fou d step-by-step instructions on how to find out who is delegated what access and that helped us out a great deal. In case you are interested, the instructions can be found at

If you guys know of any automated way to find out how is delegated what access, please do share, as it could help save us a lot of time and effort.

Thanks again,


Leave a Comment

Previous post:

Next post: