Export (0) Print
Expand All

Setting Folder-Level Permissions in Exchange 2010

Last modified: July 27, 2009

Applies to: Exchange Server 2007 | Exchange Server 2010

In Microsoft Exchange Server 2010, you can use folder-level permissions to enable a delegator to control a delegate's access to specific folders. A delegator, also known as a principal, can assign folder-level permissions to delegates to allow delegates to perform actions on the principal's behalf. For information about delegate access, see Delegate Access in Exchange 2010.

Folder-level permissions are supported in the following operations:

  • CreateFolder

  • GetFolder

  • UpdateFolder

  • SyncFolderHierarchy

A principal can configure folder-level permissions to do the following:

  • Grant, deny, and edit the permissions of a user or security group to a specified folder through role-based permission levels and a combination of individual member permissions.

  • Remove a user or security group from the permission set of a folder.

  • Configure default and anonymous sharing permissions on a specified folder.

Note Note

Individual permissions can only be set on non-calendar folders. If a client uses an individual permission to call CreateFolder or UpdateFolder against a calendar folder, the ErrorCannotSetNonCalendarPermissionOnCalendarFolder error code will be returned in the response.

You can set individual permissions on a folder, or you can set a permission level on a folder. The following are the individual permissions that you can set:

  • Can Create

  • Can Read

  • Can Create Subfolders

  • Is Folder Owner

  • Is Folder Contact

  • Is Folder Visible

  • Edit Items

  • Delete Items

The following table lists the permission levels that you can set on mailbox folders and calendar folders. If you try to set a calendar-only permission level on a non-calendar folder, an ErrorCannotSetCalendarPermissionOnNonCalendarFolder error will be returned in the response.

Mailbox folder and Calendar folder permission levels

Permission Level

Mailbox Folder

Calendar Folder

None

Yes

Yes

Owner

Yes

Yes

PublishingEditor

Yes

Yes

Editor

Yes

Yes

PublishingAuthor

Yes

Yes

Author

Yes

Yes

NoneditingAuthor

Yes

Yes

Reviewer

Yes

Yes

Contributor

Yes

Yes

Custom

Yes

Yes

FreeBusyTimeOnly

No

Yes

FreeBusyTimeAndSubjectAndLocation

No

Yes

The following table shows which individual permissions apply to each permission level.

Permissions by permission level

Permission Level

Can Create

Can Read

Can Create Sub Folders

Is Folder Owner

Is Folder Contact

Is Folder Visible

Edit Items

Delete Items

None

Not Set

Not Set

Not Set

Not Set

?

?

None

None

Owner

true

true

true

true

true

true

All

All

PublishingEditor

true

true

true

Not Set

Not Set

true

All

All

Editor

true

true

Not Set

Not Set

Not Set

Not Set

All

All

PublishingAuthor

true

true

true

Not Set

Not Set

true

Own

Own

Author

true

true

Not Set

Not Set

Not Set

true

Own

Own

NoneditingAuthor

true

true

Not Set

Not Set

Not Set

true

None

Own

Reviewer

Not Set

true

Not Set

Not Set

Not Set

true

None

None

Contributor

true

Not Set

Not Set

Not Set

Not Set

true

None

None

Custom

?

?

?

?

?

?

?

?

Question marks indicate that the flag can be either true or false for that permission level. In Microsoft Outlook, when the permission level is set to None, IsFolderContact and IsFolderVisible can be either true or false and the permission level remains unchanged. If changes are made to other individual permission settings, the permission level property also changes.

If a non-Custom permission level is specified in the folder-level permissions request, the individual permission settings should not be specified. If you specify an individual permission when a permission level has been specified, an ErrorInvalidPermissionSettings error will be returned in the response.

If the client has to specify individual settings, you must use the Custom permission level; otherwise, an ErrorInvalidPermissionSettings error will be returned in the response.

Important note Important

Attempts to use CreateFolder and UpdateFolder to set permissions will not succeed unless all the permission settings succeed. The request will fail and will not continue to edit other properties if a set permission attempt fails.

Folder-level permissions work with other Exchange Web Services operations in the following ways:

  • The GetFolder operation will return the permissions that are set on the folder when the AllProperties shape is specified.

  • The SyncFolderHierarchy operation synchronizes PermissionSets.

  • The UpdateFolder operation will fail if multiple Permission entries are provided for the same user. The UpdateFolder response will return the ErrorDuplicateUserIdsSpecified response code.

  • The SetFolderField option of the UpdateFolder operation will overwrite all the permission settings on the folder. The client cannot change the permissions for each user.

  • The DeleteFolderField option of the UpdateFolder operation will delete all the permission settings on the folder.

Note Note

A delegate who has been given Author-level permissions to the Calendar folder through EWS will receive an error if the principal forwards a meeting request to the delegate. Microsoft Outlook does not allow the forwarding flag to be set unless the delegate has Editor permissions.

The following code example shows how to set folder-level permissions when a folder is created. The authenticated user grants user3 the Editor permission level on a new folder named NewFolderWithPermissionsSet that is created in the Inbox default folder.

static void CreateFolderLevelPermissions(ExchangeServiceBinding esb)
{
    // Create user identifier.
    UserIdType user = new UserIdType();
    user.PrimarySmtpAddress = "user3@example.com.com";

    // Set the folder permission level to Editor.
    PermissionSetType permissionSet = new PermissionSetType();
    permissionSet.Permissions = new PermissionType[] { new PermissionType() };
    //permissionSet.Permissions[0] = new PermissionType();
    permissionSet.Permissions[0].PermissionLevel = PermissionLevelType.Editor;
    permissionSet.Permissions[0].UserId = user;

    FolderType folder = new FolderType();
    folder.DisplayName = "NewFolderWithPermissionsSet";
    folder.PermissionSet = permissionSet;

    // Specify the target folder.
    DistinguishedFolderIdType inbox = new DistinguishedFolderIdType();
    inbox.Id = DistinguishedFolderIdNameType.inbox;
    TargetFolderIdType targetFolder = new TargetFolderIdType();
    targetFolder.Item = inbox;

    CreateFolderType request = new CreateFolderType();
    request.Folders = new FolderType[] { folder };
    request.ParentFolderId = targetFolder;

    try
    {
        // Send the request and get the response.
        CreateFolderResponseType response = esb.CreateFolder(request);

        // Get the response messages.
        ResponseMessageType[] rmta = response.ResponseMessages.Items;

        // Cast to appropriate response message type.
        if (((FolderInfoResponseMessageType)rmta[0]).ResponseClass == ResponseClassType.Success)
        { 
            // Continue.
        }
        
    }

    catch 
    {
        // Handle errors.
    }
}

This code example was created by using proxy objects that were created by using Microsoft Visual Studio 2005.

Show:
© 2014 Microsoft