Hi, I have set some users up with delegated exchange view only exchange admninistrator through ESM 2000 and delegated management of users though an OU. This allows non privileged users to create mailboxes. However on creation thenon priveliged user then has access to add themselves to the mailbox through exchange advanced mailbox rights. I do not want the no priv users to be able to do this.Can anyone help?

Sure...set a deny rule for said users/groups on the info store level for the permissions 'send as' and 'full mailbox accesss'. Generally adsiedit is the tool of choice to set the deny. The deny will be inhertied (so greyed out to the users who has been delegated control) and deny over-rides and allows he may set.

One problem thow with inherited deny is that an explicit allow is evaluated before an inherited deny and access will be allowed. So you might end up with writing a script that sets the explicit deny permission which does have priority over explicit allow. I hope this is a little bit clear as this is a mistake lots of people make Deli

Test it. Deny permissions allways over-ride allows. Its even on the MCSE tests :-) No matter how the deny is applied, as long as it is applied to the user in question in wins no matter what. Again, if you don't believe me, try it in your lab.

You may think that but... but there is really a difference between inherited and explicit permissions! Read this article: http://technet2.microsoft.com/windowsserver/en/library/005ea897-f26f-4223-9af6-49540a9451021033.mspx?mfr=true Notes Inherited Deny permissions do not prevent access to an object if the object has an explicit Allow permission entry. Explicit permissions take precedence over inherited permissions, even inherited Deny permissions. Deli

A technet article is one thing. A working info store (which is slightly different than NTFS) is another. I'm just going off what i've seen in real life (on many occasions). Similar to our disagreement about the RG connector on HT install :-)

AD permissions work just the same way as NTFS permissions do http://technet2.microsoft.com/windowsserver/en/library/373a4e2b-89a6-4ccc-9e20-be07c741f47b1033.mspx?mfr=true Look for this explenations in this article for Send-As permissions http://technet.microsoft.com/en-us/library/110e37bf-a68c-47bb-b4d5-1cfd539d9cba.aspx Why can domain administrators spoof mailbox-enabled user accounts in their domain? Active Directory includes a base set of permissions that can be applied against objects within the directory. In particular, Active Directory includes the Send As extended permission. By default, the Administrators group, the Domain Admins group, the Enterprise Admins group, and the Account Operators group have Send As permissions for all users. The Administrators group permissions and the Enterprise Admins group permissions are inherited from the domain level. The Account Operators group and the Domain Admins group receive explicit permissions that are based on the definition of the user object that is in the Active Directory schema. You may consider implementing a Deny "Send As" access control entry (ACE) against administrators for user objects in the domain. If you decide to implement a Deny "Send As" ACE against administrators for user objects in the domain, consider the following: An explicit Allow ACE will override an inherited Deny (in other words, explicit ACEs are applied before inherited ACEs). Members of the Domain Admins group are able to remove the Deny ACE and/or add an explicit Allow ACE. The addition of a Deny ACE may have additional consequences in your environment. For more information, see Where to Apply Permissions. If implementing a Deny "Send As" ACE against administrators for user objects in the domain puts your messaging environment at risk, you should implement one or more of the following: Limit the number of domain administrators in the domain by delegating specific tasks. For more information, see Best Practices for Delegating Active Directory Administration (http://go.microsoft.com/fwlink/?LinkId=31309). Use auditing to monitor the account logon events for those accounts that are members of the Domain Admins group. Deli