Exchange Server

SELF Permission on Exchange Mailboxes

Why is the SELF permission the only permission seen on the Mailbox Rights properties on Exchange 2000/2003 mailboxes?

MS KB 272153 has more info:

In Microsoft Exchange 2000 Server or Microsoft Exchange Server 2003, when you create new mailbox-enabled accounts in Active Directory, they do not have inherited mailbox rights. The only object that is granted permission is Self, which is granted full mailbox access and read rights.

Sponsored Content

What is “Inside Microsoft Teams”?

“Inside Microsoft Teams” is a webcast series, now in Season 4 for IT pros hosted by Microsoft Product Manager, Stephen Rose. Stephen & his guests comprised of customers, partners, and real-world experts share best practices of planning, deploying, adopting, managing, and securing Teams. You can watch any episode at your convenience, find resources, blogs, reviews of accessories certified for Teams, bonus clips, and information regarding upcoming live broadcasts. Our next episode, “Polaris Inc., and Microsoft Teams- Reinventing how we work and play” will be airing on Oct. 28th from 10-11am PST.

To view mailbox rights, follow these steps:

  1. In Active Directory Users and Computers, click Advanced Features on the View menu.

Note: This is not necessary on Exchange Server 2003 because of the fact that the Exchange Advanced tab is exposed by default.

  1. Under Active Directory Users and Computers, click the account, click the Exchange Advanced tab, and then click Mailbox Rights.
  2. The rights are displayed in the Permissions for account name dialog box.

= Bad!

This behavior occurs because the mailbox security descriptor is not read from the Active Directory account object until the user logs on or gets mail. The Recipient Update Service (RUS) does not stamp the inherited permissions when the mailbox is created. After the mailbox is created in the store, the store calculates inherited mailbox rights.

To resolve this behavior perform one of the following actions:

  • Log on to the mailbox you’ve created. You can do so by opening an Outlook profile for the new user and running Outlook, or by opening a OWA session the the destination mailbox by typing http://servername/exchange/username in the address bar of your browser.

Note: Opening Outlook requires you to be logged on as the destination user, while OWA does not require you to be logged on as the user. However, both methods require that you know the destination user’s password.

  • Send a message to the mailbox.

Note: The second method is quicker and easier to perform, that’s why you’ll need to know how to Send Mail from Script and to Test SMTP Service in IIS and Exchange.

When the mailbox is created in the store, the store itself calculates the inherited permissions and stamps them on the store’s copy of the mailbox security descriptor.

= Good


Mailbox Rights for New Users Shows Only Self – 272153


Related Topics:

External Sharing and Guest User Access in Microsoft 365 and Teams

This eBook will dive into policy considerations you need to make when creating and managing guest user access to your Teams network, as well as the different layers of guest access and the common challenges that accompany a more complicated Microsoft 365 infrastructure.

You will learn:

  • Who should be allowed to be invited as a guest?
  • What type of guests should be able to access files in SharePoint and OneDrive?
  • How should guests be offboarded?
  • How should you determine who has access to sensitive information in your environment?

Sponsored by: