Configuring Permissions in Exchange Server 2007

menguin · Sep 10, 2018

When planning how to integrate Exchange 2007 into your Active Directory service structure, consider the administrative model in your organization. With Exchange 2007, you have flexibility in how you assign permissions to administrators. In many Exchange organizations, especially in medium and large organizations, there may be more than one Exchange administrator. Because these administrators can perform a specific set of administration tasks, Exchange 2007 provides predefined administrator roles and a split permissions model that allow you to configure specific permissions in Active Directory for various administrative roles in your organization.

This document provides the following information about Exchange 2007 permissions:

Planning content that will help you implement your Exchange 2007 permissions model, including a discussion of how the Exchange 2007 permissions model differs from Exchange Server 2003
Detailed procedures that show you how to configure and manage domain, recipient, and public folder permissions

Permission Considerations

With Exchange 2007, you have flexibility in how you assign permissions to administrators. Generally, we recommend that you consider how the following capabilities of Active Directory and Exchange 2007 affect the way that you organize your administrative roles:

A single administrator can perform tasks for both Microsoft Windows Server 2003 and Exchange.
You can split permissions between Exchange administrators and Windows administrators.
You can isolate the Exchange administrator roles and the Windows administrator roles by using an Exchange resource forest.

The sections in this topic describe the flexibility of permissions configuration and the administrative roles available in Exchange 2007.

Understanding the Exchange and Active Directory Split Permissions Model

In many Microsoft Exchange organizations, especially in medium and large organizations, there may be more than one Exchange administrator. Because these administrators can perform a specific set of administration tasks, Exchange Server 2007 provides predefined administrator roles and a split permissions model that allow you to configure specific permissions in Active Directory for various administrative roles in your organization. In Exchange 2007, permissions on Exchange recipient attributes are grouped together. This minimizes the manual permission configuration that you must do to split Exchange permissions from other administrative permissions. For more information about how to plan and implement your permissions model, see Planning and Implementing a Split Permissions Model.

Changes to the Security and Permission Model

The security and permissions model from Exchange Server 2003 has changed for Exchange 2007. This section provides information about the changes to the Exchange permissions model and describes the differences.

Property Sets

A property set is a grouping of Active Directory attributes. You can control access to this grouping of Active Directory attributes by setting one access control entry (ACE) instead of setting an ACE on each property. The property set that groups all Exchange recipient attributes is called e-mail information.

Note:

Exchange Server 2003 security groups that had permission to access the recipient properties on Exchange Server 2003 servers will have permission to access the Exchange 2007 e-mail information property set, as long as you use Exchange 2007 Setup.com or Setup.com with the /PrepareAD parameter to update the Active Directory schema.

For more information on property sets, see Property Sets in Exchange 2007.

Exchange 2003 Security and Permissions Model

To help simplify management of permissions, Exchange Server 2003 provided predefined security roles that were available in the Exchange 2003 Administrative Delegation Wizard. These roles were a collection of standardized permissions that could be applied at either the organization or the administrative group level.

In Exchange 2003, the following security roles were available through the Delegation Wizard in Exchange System Manager:

Exchange Full Administrator
Exchange Administrator
Exchange View Only Administrator

This model had the following limitations:

A lack of specificity. The Exchange Administrator group was too large, and some customers wanted to manage their security and permissions model at the individual server-level.
A perception that the Exchange Server 2003 security roles only differed in subtle ways.
There was no clear separation between administration of users and groups by the Windows (Active Directory) administrators and Exchange recipient administrators. For example, to perform Exchange recipient related tasks, you had to grant Exchange administrators high level permissions (Account Operator permissions on Windows domains).

Exchange 2007 Security and Permissions Model

To improve the management of your Exchange administrator roles, which were called "security groups" in Exchange 2003, the following new or improved features have been made to the Exchange security and permissions model:

New administrator roles that are similar to the built-in Windows Server security groups. For more information about these administrator roles, see "Administrator Roles in Exchange 2007" later in this topic.
You can use the Exchange Management Console (formerly Exchange System Manager) and the Exchange Management Shell to view, add, and remove members from any administrator role.

Administrator Roles in Exchange 2007

Exchange 2007 has the following predefined groups that manage Exchange configuration data:

Exchange Organization Administrators
Exchange Recipient Administrators
Exchange View-Only Administrators

During the Exchange Setup /PrepareAD phase (the organization-preparation phase that is similar to Exchange 2003 ForestPrep), these Exchange Administrator roles (except Exchange Server Administrators) are created in a new Microsoft Exchange security group's organizational unit (OU) that is located in the domain where /PrepareAD was run.

When you add an administrator role to a user, that user inherits the permissions that are permitted by that role. These administrator roles have permissions to manage Exchange data in Active Directory. There are three types of Exchange data that can be managed by these groups:

Global Data This is data in an Active Directory configuration container that is not associated with a particular server. This data includes, but is not limited to, mailbox policies, address lists, and Exchange Unified Messaging configuration. Global data generally affects the whole organization and can potentially affect all users. As a best practice, allow only a few trusted users to configure or change global data.
Recipient Data Recipients in Exchange are Active Directory user objects that can receive or send e-mail messages. Examples of recipient data include mail-enabled contacts, distribution groups, mailboxes, and specific recipient types such as public folder proxy objects.
Server Data Exchange server data is contained in Active Directory under the specified server’s node. Examples of this data include receive connectors, virtual directories, per-server settings, and mailbox and storage group data.

Exchange Organization Administrators Role

The Exchange Organization Administrators role gives administrators full access to all Exchange properties and objects in the Exchange organization. During Exchange setup, in the root domain, Setup /PrepareAD creates the Active Directory security group named Exchange Organization Administrators in the Microsoft Exchange Security Groups container of Active Directory Users and Computers.

When you add a user to the Exchange Organization Administrators role, that user becomes a member of the administrator role called Exchange Organization Administrators. Exchange 2007 creates this role during Active Directory preparation. Members of the Exchange Organization Administrators role have the following permissions:

Owners of the Exchange organization in the configuration container of Active Directory. As owners, members of the role have full control over the Exchange organization data in the configuration container in Active Directory and the local Exchange server Administrator group.
Read access to all domain user containers in Active Directory. Exchange grants this permission during setup of the first Exchange 2007 server in the domain, for each domain in the organization. These permissions are granted by being a member of the Exchange Recipient Administrator role.
Write access to all Exchange-specific attributes in all domain user containers in Active Directory. Exchange 2007 grants this permission during setup of the first Exchange 2007 server in the domain, for each domain in the organization. These permissions are granted by being a member of the Exchange Recipient Administrator role.
Owner of all local server configuration data. As owners, members have full control over the local Exchange server. Exchange 2007 grants this permission during setup of each Exchange server.

Users who are members of the Exchange Organization Administrators role have the highest level of permissions in the Exchange organization. All tasks that affect your whole Exchange organization will require membership in this group. Examples of tasks that require Exchange Organization Administrator permissions include creating or deleting connectors, changing server policies, and changing any global configuration settings.

Note:

When you install Exchange 2007, Setup will add the Exchange Organization Administrators role as a member of the local Administrators group on the computer on which you are installing Exchange. Be aware that the local Administrators group on a domain controller has different permissions than the local Administrators group on a member server. If you install Exchange 2007 on a domain controller, the users in the Exchange Organization Administrators role will have additional Windows permissions that they do not have if you install Exchange 2007 on a computer that is not a domain controller.

Exchange Recipient Administrators Role

The Exchange Recipient Administrators role has permissions to modify any Exchange property on an Active Directory user, contact, group, dynamic distribution list, or public folder object. During Exchange Setup /PrepareAD, the Exchange Recipient Administrator role is created in the Microsoft Exchange Security Groups container in Active Directory. This role also lets you manage Unified Messaging mailbox settings and Client Access mailbox settings. Members of the Exchange Organization Recipient Administrators role have the following permissions:

Read access to all the Domain User containers in Active Directory that have had Setup /PrepareDomain run in those domains.
Write access to all the Exchange specific attributes on the Domain User containers in Active Directory that have had Setup /PrepareDomain run in those domains.
Membership in the Exchange View-Only Administrator role.

Users who are members of the Exchange Recipient Administrators role will not have permissions to Domains where Setup /PrepareDomain has not been run. When you add a new Exchange domain, make sure that you run Setup /PrepareDomain in the new domain to grant permissions to the Exchange administrator roles in that domain.

Exchange Server Administrators Role

The Exchange Server Administrators role has access to only local server Exchange configuration data, either in the Active Directory or on the physical computer on which Exchange 2007 is installed. Users who are members of the Exchange Server Administrators role have permissions to administer a particular server, but do not have permissions to perform operations that have global impact in the Exchange organization.

Exchange 2007 creates this administrator role during setup. Members of the Exchange Server Administrator role have the following permissions:

Owner of all local server configuration data. As owners, members of the role have full control over the local server configuration data.
Local administrator on the computer on which Exchange is installed.
Members of the Exchange View-Only Administrators role.

Exchange View-Only Administrators

The Exchange View-Only Administrators role has read-only access to the whole Exchange organization tree in the Active Directory configuration container, and read-only access to all the Windows domain containers that have Exchange recipients.

During Exchange Setup /PrepareAD, the Exchange View-Only Administrators role is created in the Microsoft Exchange Security Groups container in Active Directory.

Summary of Administrator Roles and Permissions

The following table lists the Exchange 2007 administrator roles and their related Exchange permissions.

Administrator role

Members

Member of

Exchange permissions

Exchange Organization Administrators

Administrator, or the account that was used to install the first Exchange 2007 server

Exchange Recipient Administrator

Administrators local group of <Server Name>

Full control of the Microsoft Exchange container in Active Directory

Exchange Recipient Administrators

Exchange Organization Administrators

Exchange View-Only Administrators

Full control of Exchange properties on Active Directory user object

Exchange Server Administrators

Exchange Organization Administrators

Exchange View-Only Administrators

Administrators local group of <Server Name>

Full control of Exchange <Server Name>

Exchange View-Only Administrators

Exchange Recipient Administrators

Exchange Server Administrators (<Server Name> )

Exchange Recipient Administrators

Exchange Server Administrators

Read access to the Microsoft Exchange container in Active Directory.

Read access to all the Windows domains that have Exchange recipients.

Exchange Servers

Each Exchange 2007 computer account

Exchange View-Only Administrators

Special

Address Book Attributes

Exchange uses many attributes to store Exchange data. Exchange also uses other recipient attributes that can be used by other directory-aware applications that use the Exchange data. Therefore, these attributes were not added to the Exchange-specific property sets. These attributes may reside in other property sets created during Active Directory installation or they may not belong to any property set.

The attributes listed in the following table are the data that is provided to end-users via Microsoft Office Outlook in the Global Address List (GAL). If an Exchange administrator requires the ability to update these attributes and is not a member of a domain privileged security group, such as the Account Operators group, the Active Directory administrator must grant read/write permission.

Applies to object

Exchange Management Console location

Attribute

Description

User, Contact

User Information or Contact Information tab in User or Contact properties

givenName

First name

User, Contact

User Information or Contact Information tab in User or Contact properties

initials

Middle initial

User, Contact

User Information or Contact Information tab in User or Contact properties

sn

Last name

User, Contact

User Information or Contact Information tab in User or Contact properties

info

Notes field

User, Contact

Address and Phone tab in User or Contact properties

streetAddress

Street address

User, Contact

Address and Phone tab in User or Contact properties

l

City

User, Contact

Address and Phone tab in User or Contact properties

st

State/Province

User, Contact

Address and Phone tab in User or Contact properties

postalCode

ZIP/Postal code

User, Contact

Address and Phone tab in User or Contact properties

countryCode

Country/Region

User, Contact

Address and Phone tab in User or Contact properties

telephoneNumber

Business phone

User, Contact

Only available in the Exchange Management Shell

otherTelephoneNumber

Alternative business phone

User, Contact

Address and Phone tab in User or Contact properties

pager

Pager

User, Contact

Address and Phone tab in User or Contact properties

facsimileTelephoneNumber

Fax

User, Contact

Address and Phone tab in User or Contact properties

homePhone

Home phone

User, Contact

Only available in the Exchange Management Shell

otherHomePhone

Alternative home phone

User, Contact

Address and Phone tab in User or Contact properties

mobile

Mobile phone

User, Contact

Only available in the Exchange Management Shell

otherfacsimileTelephoneNumber

Alternative fax

Contact

Only available in the Exchange Management Shell

telephoneAssistant

Assistant phone

Contact

Active Directory Service Interfaces (ADSI) Edit/LDAP

telephoneAssistant

Assistant phone

User, Contact

Organization tab in User or Contact properties

title

Title

User, Contact

Organization tab in User or Contact properties

company

Company

User, Contact

Organization tab in User or Contact properties

department

Department

User, Contact

Organization tab in User or Contact properties

physicalDeliveryOfficeName

Office

User, Contact

Organization tab in User or Contact properties

manager

Manager

User, Contact

Organization tab in User or Contact properties

directReports

Direct reports

User, Contact

Only available in the Exchange Management Shell

msExchAssistantName

Assistant name

Group

Group Information tab in Group properties

managedBy

Group owner

Group

Group Information tab in Group properties

info

Notes field

For More Information

For detailed syntax and parameter information, see "Add-ExchangeAdministrator" in Exchange Server 2007 Help (http://go.microsoft.com/fwlink/?LinkId=79424).

For information about how to prepare Active Directory and your domains for Exchange 2007, see "How to Prepare Active Directory and Domains" in Exchange Server 2007 Help (http://go.microsoft.com/fwlink/?linkid=65320).

Planning and Implementing a Split Permissions Model

Organizations that implement a split permissions model typically want to restrict specific permissions granted to administrators to enhance accountability and security. In Microsoft Exchange Server 2007, permissions on Exchange recipient attributes are grouped together. This minimizes the manual permission configuration that you must do to split Exchange permissions from other administrative permissions.

By default, only Exchange Organization Administrators can manage both Exchange recipient and configuration data. However, to manage object creation, modification, and deletion within a specific domain, these administrators also require membership in the Windows Account Operators security group or a higher level security group. For information about how to grant Account Operators permissions, see Windows Server 2003 Product Help.

Access Control

To manage Exchange-related attributes on objects within the domain naming context of the forest, Modify permissions must be granted to the Exchange Server Administrators group. You do this by changing the security descriptor on the object that contains the attributes.

A security descriptor contains two access control lists (ACL). An ACL is a list of user or security group objects that have access or are denied access to a resource or object. ACLs allow specific permissions to be applied to the whole object, a set of properties of the object, or to an individual property of an object. Two types of ACLs are in the security descriptor of an object:

Discretionary access control lists (DACL) DACLs determine the users and groups that are assigned or denied access permissions on an object. If a DACL does not explicitly determine a user or any groups that a user is a member of, the user is denied access to that object. By default, a DACL is controlled by the owner of an object or the person who created the object, and it contains access control entries (ACE) that determine user access to the object.
System access control lists (SACL) SACLs determine the users and groups that you want to audit when they successfully access or cannot access an object. By default, a SACL is controlled by the owner of an object or the person who created the object. A SACL contains ACEs that determine whether to record a successful or failed attempt by a user who uses a specific permission, such as Full Control and Read, to access an object.

An ACE is an entry in the DACL of an object that grants permissions to a user or group. An ACE is also an entry in the SACL of an object that specifies the security events that are to be audited for a user or group.

Where to Apply Permissions

An Active Directory directory service forest consists of one or more domains that share a common configuration and schema boundary. Within those domains, objects can also be arranged into containers known as organizational units (OU). The administrators of each organization must design an OU structure that meets their business needs and optimizes delegation of administrative permissions.

For more information about how to design an OU structure, see Best Practice Active Directory Design for Managing Windows Networks and Best Practices for Delegating Active Directory Administration.

When you design a delegation model, there are several methods for applying permissions. This topic discusses only the following two methods:

Applying permissions at the domain level
Applying permissions at the OU level

Applying Permissions at the Domain Level

When you apply delegated permissions on the domain level, the permissions are inherited by all objects. This includes users, contacts, groups, domain DNS, and computers. On domain controllers that are running Microsoft Windows 2000 Server, adding an inheritable ACE at the domain level causes the DACL to change for every object within the domain. Depending on the number of ACEs added and the number of objects within the domain, these changes can result in what is known as ACL bloat. ACL bloat means unnecessary ACEs on objects increase the size of the ACL. An ACL bloat increases the physical size of the Ntds.dit file across all domain controllers within the domain. This can cause Active Directory performance issues.

On domain controllers that are running Microsoft Windows Server 2003, a unique security descriptor is stored only one time instead of being stored for every object that inherits it. This change reduces data redundancy and the database growth that can result from changes to inheritable ACEs.

Applying Permissions at the OU Level

The recommended practice for applying permissions is to apply the permissions on a parent OU. This isolates the application of the permissions to specific class objects that are contained within the OU and its child containers. This method requires that all managed objects be put within a parent OU. Business requirements may prevent your organization from applying this method. If business requirements prevent this, you can apply the permissions across multiple OUs.

How to Apply Permissions

Microsoft provides two tools to apply permissions:

ADSI Edit (AdsiEdit.msc)
DSACLS (Dsacls.exe)

Both tools are included on the Windows Server 2003 CD in Support\Tools. Several third-party products can also be used to apply permissions.

Note:

If you incorrectly modify the attributes of Active Directory objects when you use Active Directory Service Interfaces (ADSI) Edit, DSACLS, the LDP (Ldp.exe) tool, or another Lightweight Directory Access Protocol (LDAP) version 3 client, serious problems may occur. These problems may require that you reinstall Windows Server, Exchange 2007, or both. Modify Active Directory object attributes at your own risk.

For more information about how to use ADSI Edit, see How to Use ADSI Edit to Apply Permissions.

The recommended practice for applying permissions in Exchange 2007 is to use the Add-ADPermission cmdlet in the Exchange Management Shell. For detailed syntax and parameter information, see "Add-ADPermission" in Exchange Server 2007 Help (http://go.microsoft.com/fwlink/?LinkId=79424). For more information about the Exchange Management Shell, see "Using the Exchange Management Shell" in Exchange Server 2007 Help (http://go.microsoft.com/fwlink/?linkid=65320).

Examples of How to Apply Permissions

Because of the implementation of property sets in Exchange 2007, implementation of a split permission model requires far fewer ACEs than in earlier versions of Exchange Server.

For an Exchange 2007 administrator to manage all mail-related properties, the administrator must have the following permissions within the domain partition:

Write access to the following property sets:
Exchange Personal Information
Exchange Information
Write access to the following attributes:
legacyExchangeDN
displayName
adminDisplayName
displayNamePrintable
publicDelegates
garbageCollPeriod
textEncodedORAddress
showInAddressBook
proxyAddresses
mail
Create permission for msExchDynamicDistributionList objects
Delete permission for msExchDynamicDistributionList objects
Full control permission for msExchDynamicDistributionList objects
Generic Read permission. This includes Read Permissions, List Contents, List Object, and Read All Properties.

In addition to these permissions, the recipient administrator must also have the following permissions in the Exchange organization:

Exchange View-Only Administrator role or higher

Note:

Certain operations, such as moving mailboxes, require Exchange Server Administrator role or higher.

Write access to the msExchLastAppliedRecipientFilter and msExchRecipientFilterFlags attributes on the Address Lists container in the Exchange organization. These permissions are required so the recipient administrator can execute the Update-AddressList cmdlet.
Write access to the msExchLastAppliedRecipientFilter and msExchRecipientFilterFlags attributes on the Recipient Policies container within the Exchange organization. These permissions are required so the recipient administrator can execute the Update-EmailAddressPolicy cmdlet.
The Access Recipient Update Service extended right on the Exchange 2007 administrative group. This extended right is required because in Exchange 2007, the address-related information is stamped on the recipient during the provisioning process.

Note:

These permissions are for managing attributes that are specific to Exchange. Exchange administrators cannot manage attributes that were created outside Exchange unless the administrators are delegated the appropriate permissions.

How to Use the Exchange Management Shell to Apply Permissions

This section provides an example of how to use the Exchange Management Shell to delegate permissions.

The commands in this example enable the administrators in the OU1AdminGroup security group to mail-enable and mail-disable recipients, manage e-mail addresses, and display names for all users, groups, and contacts that are contained in the Container1 OU hierarchy in the Contoso.com forest that contains the ContosoOrg Exchange organization.

If you want to perform these tasks for your organization, run the following commands for each container where you want to grant access. Replace the domain name, Exchange organization, and account information with your own domain information.

You must run the following commands in this order to grant the permissions.

1. Run the following command to manage Exchange-related attributes on objects within the OU.

Add-ADPermission –Identity "ou=Container1,dc=Contoso,dc=com" –User "Contoso\OU1AdminGroup" -AccessRights ReadProperty, WriteProperty -Properties Exchange-Information, Exchange-Personal-Information, legacyExchangeDN, displayName, adminDisplayName, displayNamePrintable, publicDelegates, garbageCollPeriod, textEncodedORAddress, showInAddressBook, proxyAddresses, mail

2. Run the following command to provide Generic Read permission for all objects within the OU.

Add-ADPermission -Identity "ou=Container1,dc=Contoso,dc=com" -User "Contoso\OU1AdminGroup" -AccessRights GenericRead

3. Run the following command to grant the appropriate permission to manage dynamic distribution groups within the OU.

Add-ADPermission -Identity "ou=Container1,dc=Contoso,dc=com" -User "Contoso\OU1AdminGroup" -AccessRights GenericAll –InheritanceType Descendents -InheritedObjectType msExchDynamicDistributionList

4. Run the following command to grant the appropriate permission to create and delete dynamic distribution groups within the OU.

Add-ADPermission -Identity "ou=Container1,dc=Contoso,dc=com" -User "Contoso\OU1AdminGroup" -AccessRights CreateChild, DeleteChild -ChildObjectTypes msExchDynamicDistributionList

5. Run the following command to grant the OU1AdminGroup security group extended right to access the Recipient Update Service.

Add-ADPermission -Identity "CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=ContosoOrg,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=Contoso,DC=com" -User "Contoso\OU1AdminGroup " -InheritedObjectType ms-Exch-Exchange-Server -ExtendedRights ms-Exch-Recipient-Update-Access -InheritanceType Descendents

6. Run the following commands to grant OU1AdminGroup security group the ability to update the address lists and e-mail address policies.

Add-ADPermission –Identity "CN=Address Lists Container,CN=ContosoOrg,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=Contoso,DC=com" –User "company\OU1AdminGroup" -AccessRights WriteProperty -Properties msExchLastAppliedRecipientFilter, msExchRecipientFilterFlags

Add-ADPermission –Identity "CN=Recipient Policies,CN=ContosoOrg,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=Contoso,DC=com" –User "company\OU1AdminGroup" -AccessRights WriteProperty -Properties msExchLastAppliedRecipientFilter, msExchRecipientFilterFlags

If this is successful, each command will output the ACEs that were added to the object.

How to Use DSACLS to Apply Permissions

This section provides an example of how to use DSACLS (Dsacls.exe) to apply permissions.

DSACLS is a command-line tool that you can use to query and change permissions and security attributes of Active Directory objects. DSACLS is included with the Windows Server 2003 Support Tools. Also, it is the command-line equivalent of the Security tab in the Windows 2000 Server Active Directory snap-in tools, such as Active Directory Users and Computers and Active Directory Sites and Services.

The commands in this example enable the administrators in the OU1AdminGroup security group to mail-enable and mail-disable recipients, manage e-mail addresses, and display names for all users, groups, and contacts that are contained in the OUContainer1 OU hierarchy in the Contoso.com forest that contains the ContosoOrg Exchange organization.

Note:

DSACLS is case sensitive. You must be precise in the syntax that you pass to DSACLS because all characters are passed literally. This includes white spaces and carriage returns. If you receive errors from DSACLS, review the command to make sure that it is correct, or try breaking the command into smaller segments. For more information about how to use DSACLS, see Microsoft Knowledge Base article 281146, How to Use Dsacls.exe in Windows Server 2003 and Windows 2000.

You must run the following commands in this order to grant the permissions.

1. Log on to a computer within the forest that has the Windows Support Tools installed by using an account that can perform the tasks, such as Domain Administrator. Replace the domain name, Exchange organization, and account information with your own domain information.

2. Open a Command Prompt window, and type the following commands to manage Exchange-related attributes on objects within the OU.

dsacls "OU=OUContainer1,DC=Contoso,DC=com" /I:T /G "Contoso\OU1AdminGroup:RPWP;legacyExchangeDN" "Contoso\OU1AdminGroup:RPWP;displayName" "Contoso\OU1AdminGroup:RPWP;adminDisplayName" "Contoso\OU1AdminGroup:RPWP;displayNamePrintable" "Contoso\OU1AdminGroup:RPWP;publicDelegates" "Contoso\OU1AdminGroup:RPWP;garbageCollPeriod" "Contoso\OU1AdminGroup:RPWP;textEncodedORAddress" "Contoso\OU1AdminGroup:RPWP;showInAddressBook" "Contoso\OU1AdminGroup:RPWP;proxyAddresses" "Contoso\OU1AdminGroup:RPWP;mail" "Contoso\OU1AdminGroup:RPWP;Exchange Personal Information" "Contoso\OU1AdminGroup:RPWP;Exchange Information" "Contoso\OU1AdminGroup:CCDC;msExchDynamicDistributionList" "Contoso\OU1AdminGroup:GR;"

3. Open a Command Prompt window, and type the following command to grant the appropriate rights to manage dynamic distribution groups within the OU.

dsacls "OU=OUContainer1,DC=Contoso,DC=com" /I:S /G "Contoso\OU1AdminGroup:GA;; msExchDynamicDistributionList"

4. Open a Command Prompt window, and type the following command to grant the OU1AdminGroup security group extended right to access the Recipient Update Service.

dsacls "CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=ContosoOrg,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=Contoso,DC=com" /I:S /G "Contoso\OU1AdminGroup:CA;Access Recipient Update Service;msExchExchangeServer"

5. Open a Command Prompt window, and type the following commands to grant the OU1AdminGroup security group the ability to update the address lists and e-mail address policies.

dsacls "CN=Address Lists Container, CN=ContosoOrg,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=Contoso,DC=com" /I:T /G "company\OU1AdminGroup:WP;msExchLastAppliedRecipientFilter" "company\OU1AdminGroup:WP;msExchRecipientFilterFlags"

dsacls "CN=Recipient Policies, CN=ContosoOrg,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=Contoso,DC=com" /I:T /G "company\OU1AdminGroup:WP;msExchLastAppliedRecipientFilter" "company\OU1AdminGroup:WP;msExchRecipientFilterFlags"

If this is successful, the command will output the revised Windows security descriptor and display The command completed successfully at the command prompt.

Property Sets in Exchange 2007

Earlier versions of Microsoft Exchange Server did not rely heavily on property sets for applying permissions in the domain partition. Although this was not an issue in typical deployments, this became an issue for distributed environments that delegated all tasks. Administrators in these environments had to assign permissions for a multitude of attributes for mail recipients so that appropriate tasks could be delegated in a least-privilege access model. Depending on the version of the Active Directory directory service servers, this can cause serious access control list (ACL) bloat, increasing the size of the Ntds.dit file.

Exchange Server 2007 improves administrative delegation by using property sets for most mail recipient attributes.

What Are Property Sets?

A property set is a grouping of Active Directory attributes. You can control access to this grouping of Active Directory attributes by setting one access control entry (ACE) instead of setting an ACE on each property. Also, an attribute can only be a member of a single property set.

For example, the Personal-Information property set includes properties such as street address and telephone number. Both of these are properties of user objects.

Property Sets in Exchange Server 2003

In Exchange Server 2003, the Exchange schema extension process added many Exchange-related mail recipient attributes to the built-in Active Directory property sets, Personal Information and Public Information. The Exchange Enterprise Servers domain local security groups were assigned access to these property sets on the domain partitions during the domain preparation phase so that Recipient Update Service (RUS) could update objects. The following tables list the attributes in the Personal Information and Public Information property sets.

Public Information property set

allowedAttributes

allowedAttributesEffective

allowedChildClasses

allowedChildClassesEffective

altRecipient

altRecipientBL

altSecurityIdentities

attributeCertificate

authOrig

authOrigBL

autoReply

autoReplyMessage

cn

co

company

deletedItemFlags

delivContLength

deliverAndRedirect

deliveryMechanism

delivExtContTypes

department

description

directReports

displayNamePrintable

distinguishedName

division

dLMemberRule

dLMemDefault

dLMemRejectPerms

dLMemRejectPermsBL

dLMemSubmitPerms

dLMemSubmitPermsBL

dnQualifier

enabledProtocols

expirationTime

extensionAttribute1

extensionAttribute10

extensionAttribute11

extensionAttribute12

extensionAttribute13

extensionAttribute14

extensionAttribute15

extensionAttribute2

extensionAttribute3

extensionAttribute4

extensionAttribute5

extensionAttribute6

extensionAttribute7

extensionAttribute8

extensionAttribute9

extensionData

folderPathname

formData

forwardingAddress

givenName

heuristics

hideDLMembership

homeMDB

homeMTA

importedFrom

initials

internetEncoding

kMServer

language

languageCode

legacyExchangeDN

mail

mailNickname

manager

mAPIRecipient

mDBOverHardQuotaLimit

mDBOverQuotaLimit

mDBStorageQuota

mDBUseDefaults

msDS-AllowedToDelegateTo

msDS-Approx-Immed-Subordinates

msDS-Auxiliary-Classes

msExchADCGlobalNames

msExchALObjectVersion

msExchAssistantName

msExchConferenceMailboxBL

msExchControllingZone

msExchCustomProxyAddresses

msExchExpansionServerName

msExchFBURL

msExchHideFromAddressLists

msExchHomeServerName

msExchIMACL

msExchIMAddress

msExchIMAPOWAURLPrefixOverride

msExchIMMetaPhysicalURL

msExchIMPhysicalURL

msExchIMVirtualServer

msExchInconsistentState

msExchLabeledURI

msExchMailboxFolderSet

msExchMailboxGuid

msExchMailboxSecurityDescriptor

msExchMailboxUrl

msExchMasterAccountSid

msExchOmaAdminExtendedSettings

msExchOmaAdminWirelessEnable

msExchOriginatingForest

msExchPfRootUrl

msExchPFTreeType

msExchPoliciesExcluded

msExchPoliciesIncluded

msExchPolicyEnabled

msExchPolicyOptionList

msExchPreviousAccountSid

msExchProxyCustomProxy

msExchQueryBaseDN

msExchRecipLimit

msExchRequireAuthToSendTo

msExchResourceGUID

msExchResourceProperties

msExchTUIPassword

msExchTUISpeed

msExchTUIVolume

msExchUnmergedAttsPt

msExchUseOAB

msExchUserAccountControl

msExchVoiceMailboxID

name

notes

o

objectCategory

objectClass

objectGUID

oOFReplyToOriginator

otherMailbox

ou

pOPCharacterSet

pOPContentFormat

protocolSettings

proxyAddresses

publicDelegatesBL

replicatedObjectVersion

replicationSensitivity

replicationSignature

reportToOriginator

reportToOwner

securityProtocol

servicePrincipalName

showInAddressBook

sn

submissionContLength

supportedAlgorithms

systemFlags

targetAddress

telephoneAssistant

textEncodedORAddress

title

unauthOrig

unauthOrigBL

unmergedAtts

userPrincipalName

Personal Information property set

assistant

c

facsimileTelephoneNumber

homePhone

homePostalAddress

info

internationalISDNNumber

ipPhone

l

mobile

mSMQDigests

mSMQSignCertificates

otherFacsimileTelephoneNumber

otherHomePhone

otherIpPhone

otherMobile

otherPager

otherTelephone

pager

personalTitle

physicalDeliveryOfficeName

postalAddress

postalCode

postOfficeBox

preferredDeliveryMethod

primaryInternationalISDNNumber

primaryTelexNumber

publicDelegates

registeredAddress

st

street

streetAddress

telephoneNumber

teletexTerminalIdentifier

telexNumber

thumbnailPhoto

userCert

userCertificate

userSharedFolder

userSharedFolderOther

userSMIMECertificate

x121Address

However, when it came to delegation of permissions for management of mail recipients, many Active Directory administrators did not assign permissions to Exchange administrators by using these property sets because they provided access to many additional non-Exchange related attributes.

Property Sets in Exchange 2007

Exchange 2007 takes advantage of property sets by creating two new property sets exclusively for Exchange Server, instead of by relying on preexisting Active Directory property sets. Several of the improvements in Exchange 2007 include the following:

There is no longer a reliance on default Active Directory property sets. The Exchange-specific property sets address the uncertainty of potential change in future versions of the Active Directory property sets.
Attributes created by the Exchange schema extension are the only members of the Exchange-specific property sets.
Exchange-specific property sets enable the creation and deployment of a delegated security permission model that is specific to management of Exchange mail recipient data.

During the schema extension phase, Exchange 2007 performs several actions. These include the following:

It extends the schema with new classes and attributes.
It creates the Exchange Information and Exchange Personal Information property sets.
It adds the appropriate attributes to the Exchange Information and Exchange Personal Information property sets.

Exchange 2003 attributes that had been previously added to the Personal Information or Public Information property sets are moved accordingly to the Exchange-specific property sets.

Because attributes are moved between property sets, you must update the Exchange 2003 recipient permission structure when you implement Exchange 2007 in a legacy environment. You do this either by executing the setup /PrepareLegacyExchangePermissions command or the setup /PrepareSchema command. For more information about what the setup /PrepareLegacyExchangePermissions command does, see "Preparing Legacy Exchange Permissions" in Exchange Server 2007 Help (http://go.microsoft.com/fwlink/?linkid=65320).

The Exchange Information property set includes the attributes that are listed in the following table. In addition, Authenticated Users have read access to this property set so that they can look up specific pieces of information about mail recipients, for example, by using the Address Book in Microsoft Office Outlook.

Exchange Information property set

altRecipient

altRecipientBL

attributeCertificate

authOrig

authOrigBL

autoReply

autoReplyMessage

deletedItemFlags

delivContLength

deliverAndRedirect

deliveryMechanism

delivExtContTypes

dLMemberRule

dLMemDefault

dLMemRejectPerms

dLMemRejectPermsBL

dLMemSubmitPerms

dLMemSubmitPermsBL

dnQualifier

enabledProtocols

expirationTime

extensionAttribute1

extensionAttribute10

extensionAttribute11

extensionAttribute12

extensionAttribute13

extensionAttribute14

extensionAttribute15

extensionAttribute2

extensionAttribute3

extensionAttribute4

extensionAttribute5

extensionAttribute6

extensionAttribute7

extensionAttribute8

extensionAttribute9

extensionData

folderPathname

formData

forwardingAddress

heuristics

hideDLMembership

homeMDB

homeMTA

importedFrom

internetEncoding

kMServer

language

languageCode

mailNickname

mAPIRecipient

mDBOverHardQuotaLimit

mDBOverQuotaLimit

mDBStorageQuota

mDBUseDefaults

msExchADCGlobalNames

msExchALObjectVersion

msExchAssistantName

msExchConferenceMailboxBL

msExchControllingZone

msExchCustomProxyAddresses

msExchELCExpirySuspensionEnd

msExchELCExpirySuspensionStart

msExchELCMailboxFlags

msExchExpansionServerName

msExchExternalOOFOptions

msExchFBURL

msExchHideFromAddressLists

msExchHomeServerName

msExchIMACL

msExchIMAddress

msExchIMAPOWAURLPrefixOverride

msExchIMMetaPhysicalURL

msExchIMPhysicalURL

msExchIMVirtualServer

msExchInconsistentState

msExchLabeledURI

msExchMailboxFolderSet

msExchMailboxGuid

msExchMailboxOABVirtualDirectoriesLink

msExchMailboxSecurityDescriptor

msExchMailboxTemplateLink

msExchMailboxUrl

msExchMasterAccountHistory

msExchMasterAccountSid

msExchMaxBlockedSenders

msExchMaxSafeSenders

msExchMDBRulesQuota

msExchMessageHygieneSCLJunkThreshold

msExchMobileAllowedDeviceIDs

msExchMobileDebugLogging

msExchMobileMailboxFlags

msExchMobileMailboxPolicyLink

msExchOmaAdminExtendedSettings

msExchOmaAdminWirelessEnable

msExchOriginatingForest

msExchPfRootUrl

msExchPFTreeType

msExchPoliciesExcluded

msExchPoliciesIncluded

msExchPolicyEnabled

msExchPolicyOptionList

msExchPreviousAccountSid

msExchProxyCustomProxy

msExchPurportedSearchUI

msExchQueryBaseDN

msExchQueryFilterMetadata

msExchRecipientDisplayType

msExchRecipientTypeDetails

msExchRecipLimit

msExchRequireAuthToSendTo

msExchResourceCapacity

msExchResourceDisplay

msExchResourceGUID

msExchResourceMetaData

msExchResourceProperties

msExchResourceSearchProperties

msExchServerAdminDelegationBL

msExchTUIPassword

msExchTUISpeed

msExchTUIVolume

msExchUMAudioCodec

msExchUMDtmfMap

msExchUMEnabledFlags

msExchUMFaxId

msExchUMListInDirectorySearch

msExchUMMaxGreetingDuration

msExchUMOperatorNumber

msExchUMPinPolicyAccountLockoutFailures

msExchUMPinPolicyDisallowCommonPatterns

msExchUMPinPolicyExpiryDays

msExchUMPinPolicyMinPasswordLength

msExchUMRecipientDialPlanLink

msExchUMServerWritableFlags

msExchUMSpokenName

msExchUMTemplateLink

msExchUnmergedAttsPt

msExchUseOAB

msExchUserAccountControl

msExchUserCulture

msExchVersion

msExchVoiceMailboxID

oOFReplyToOriginator

pOPCharacterSet

pOPContentFormat

protocolSettings

publicDelegatesBL

replicatedObjectVersion

replicationSensitivity

replicationSignature

reportToOriginator

reportToOwner

securityProtocol

submissionContLength

supportedAlgorithms

targetAddress

telephoneAssistant

unauthOrig

unauthOrigBL

unmergedAtts

The Exchange Personal Information property set includes the attributes that are listed in the following table. To make sure that ordinary users cannot retrieve the data that is stored in these attributes, the attributes are put into a separate property set where Authenticated Users are not assigned read access.

Exchange Personal Information property set

msExchMessageHygieneFlags

msExchMessageHygieneSCLDeleteThreshold

msExchMessageHygieneSCLQuarantineThreshold

msExchMessageHygieneSCLRejectThreshold

msExchSafeRecipientsHash

msExchSafeSendersHash

msExchUMPinChecksum

For More Information

For more information, see the following topics in Exchange Server 2007 Help (http://go.microsoft.com/fwlink/?linkid=65320):

Preparing Legacy Exchange Permissions
Exchange 2007 Permissions: Frequently Asked Questions
Permission Considerations

How to Remove a User or Group from an Administrator Role

This topic explains how to use the Microsoft Exchange Management Console or the Exchange Management Shell to remove a user or group from an administrator role.

Before You Begin

To perform this procedure, the account you use must be delegated the following:

Exchange Organization Administrator role

For more information about permissions, delegating roles, and the rights that are required to administer Exchange Server 2007, see Permission Considerations.

To use Exchange Management Console to remove a user or group from an administrator role

1. Start the Exchange Management Console.

2. In the console tree, click Organization Configuration.

3. In the result pane, on the Delegate tab, you will see your users and groups, their relevant Administrator roles, and the scope of their permissions to Exchange 2007.

4. Select the user or group that you want to remove, and then, in the action pane, click Remove.

To use Exchange Management Shell to remove an administrator from the Exchange Organization Administrators role

1. Run the following command:

Remove-ExchangeAdministrator -Identity Administrator -Role OrgAdmin

For detailed syntax and parameter information, see "Remove-ExchangeAdministrator" in Exchange Server 2007 Help (http:// go.microsoft.com/fwlink/?LinkId =79424).

For More Information

For more information about administrator roles in Exchange 2007, see Permission Considerations.

How to Add a User or Group to an Administrator Role

This topic explains how to use the Exchange Management Console and the Exchange Management Shell to add a user or group to a Microsoft Exchange Server 2007 administrator role. In Exchange 2007, an administrator role is a predefined security group that provides specific permissions to allow role members to manage Exchange configuration data. Exchange 2007 provides the following four administrator roles: Exchange Recipient Administrators, Exchange Organization Administrators, Exchange Server Administrators, and Exchange View-Only Administrators. To learn more about Exchange 2007 administrator roles, see Permission Considerations.

Before You Begin

To perform this procedure, the account you use must be delegated the following:

Exchange Organization Administrator role

For more information about permissions, delegating roles, and the rights that are required to administer Exchange Server 2007, see Permission Considerations.

To use the Exchange Management Console to add a user or group to an administrator role

1. Start the Exchange Management Console.

2. In the console tree, click Organization Configuration.

3. In the action pane, click Add Exchange Administrator. The Add Exchange Administrator wizard appears.

4. On the Add Exchange Administrator page, click Browse to select the user or group for which you want to add an Exchange administrator role.

5. Under Select the role and scope of this Exchange administrator, select the Exchange administrator role you want. If you select the Exchange Server Administrator role, be sure to select the appropriate Exchange servers to which the user or group will have access.

6. Click Add.

7. On the Completion page, click Finish to complete the task.

Note:

If you delegate Exchange Administrator permissions to an administrator, that administrator must be a member of the local administrators group. Delegating local administrator permissions to Exchange Recipient or Exchange View Only administrator roles on an Exchange 2007 server is not recommended. Exchange Recipient and View Only administrators should use a computer running the Exchange Management Console only.

To use the Exchange Management Shell to add a user or group to an administrator role

Run the following command:

Add-ExchangeAdministrator -Role OrgAdmin -Identity Contoso\Ted

For detailed syntax and parameter information, see "Add-ExchangeAdministrator" in Exchange Server 2007 Help (http:// go.microsoft.com/fwlink/?LinkId =79424).

For More Information

For more information about configuring Exchange 2007 administrator roles, see "Configuring Permissions" in Exchange Server 2007 Help (http://go.microsoft.com/fwlink/?linkid=65320).
To learn more about Exchange 2007 administrator roles, see Permission Considerations.

How to View the Administrator Roles for Users and Groups

This topic explains how to use the Exchange Management Console and the Exchange Management Shell to view administrator roles for users and groups.

Before You Begin

To perform this procedure, the account you use must be delegated the following:

Exchange View-Only Administrator role

For more information about permissions, delegating roles, and the rights that are required to administer Exchange Server 2007, see Permission Considerations.

To use the Exchange Management Console to view administrator roles for users and groups

1. Start the Exchange Management Console.

2. In the console tree, click Organization Configuration.

3. In the result pane, on the Exchange Administrator tab, you will see your users, their relevant administrator roles, and the scope of their permissions to Exchange 2007.

To use the Exchange Management Shell to view administrator roles for users and groups

1. Run the following command:

Get-ExchangeAdministrator

For detailed syntax and parameter information, see "Get-ExchangeAdministrator" in Exchange Server 2007 Help (http://go.microsoft.com/fwlink/?LinkId=79424).

For More Information

For instructions about how to add users or groups to an administrator role, see How to Add a User or Group to an Administrator Role.
For instructions about how to remove users or groups from an administrator role, see How to Remove a User or Group from an Administrator Role.

How to Modify Permissions for Users and Groups

This topic explains how to use the Exchange Management Console and the Exchange Management Shell to add or modify the permissions for an existing user or group. For example, you can add Exchange Organization permissions to an administrator who already has Exchange View-Only permissions.

Before You Begin

To perform this procedure, the account you use must be delegated the following:

Exchange Organization Administrator role

For more information about permissions, delegating roles, and the rights that are required to administer Exchange Server 2007, see Permission Considerations.

To use the Exchange Management Console to modify permissions for users and groups

1. Start the Exchange Management Console.

2. In the console tree, click Organization Configuration.

3. In the result pane, on the Exchange Administrators tab, you will see the users, their administrator roles, and the scope of their permissions for Microsoft Exchange Server 2007.

4. In the action pane, click Add Exchange Administrator. The Add Exchange Administrator wizard appears.

5. On the Add Exchange Administrator page, click Browse to select the user or group for which you want to modify permissions.

6. Under Select the role and scope of this Exchange administrator, select the Exchange administrator role you want. If you select the Exchange Server Administrator role, be sure to select the appropriate Exchange servers to which the user or group will have access.

7. Click Add.

8. On the Completion page, click Finish to complete the task.

To use the Exchange Management Shell to modify permissions for users and groups

Run the following command:

Add-ExchangeAdministrator -Role OrgAdmin -Identity Contoso\Ted

For detailed syntax and parameter information, see "Add-ExchangeAdministrator" in Exchange Server 2007 Help (http://go.microsoft.com/fwlink/?LinkId=79424).

For More Information

For instructions about how to add users or groups to an administrator role, see How to Add a User or Group to an Administrator Role.

For instructions about how to remove users or groups from an administrator role, see How to Remove a User or Group from an Administrator Role.

How to Grant Send As Permissions for a Mailbox

This topic explains how to use Active Directory Users and Computers or the Exchange Management Shell to grant Send as permissions for a mailbox. Use Send as permissions in Microsoft Exchange Server 2007 to configure a mailbox so that users other than the mailbox owner can use that mailbox to send messages. After this permission is granted, any messages that are sent from the mailbox will appear as if they were sent by the mailbox owner.

The Send as permission is not granted until after replication has occurred. Replication times depend on your Microsoft Exchange and network configuration. To grant the permission immediately, stop and then restart the Microsoft Exchange Information Store service.

Before You Begin

To perform this procedure, the account you use must be delegated the following:

Exchange Organization Administrator role

For more information about permissions, delegating roles, and the rights that are required to administer Exchange Server 2007, see Permission Considerations.

To use Active Directory Users and Computers to grant a user "Send as" permissions for another user's mailbox

1. On a computer that is running Exchange, click Start, point to All Programs, point to Administrative Tools, and then click Active Directory Users and Computers.

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

3. Expand the domain node, and then click Users.

4. In the details pane, right-click the user for which you want to grant the Send as permission, and then click Properties.

5. In <User> Properties, on the Security tab, click Advanced.

6. In Advanced Security Settings for <User>, click Add.

7. In the Enter the object name to select box, type the name of the mailbox user or the group to which you want to grant Send as permissions, and then click Check Name to verify the user or group. Click OK.

8. In Permission Entry for <User>, in the Apply onto list, select This object only.

9. In the Permissions list, locate Send As, and then select the Allow check box.

10. Click OK to close the dialog boxes.

To use the Exchange Management Shell to grant a user "Send as" permissions for another user's mailbox

1. Run the following command:

Add-ADPermission "Mailbox" -User "Domain\User" -Extendedrights "Send As"

For detailed syntax and parameter information, see "Add-ADPermission" in Exchange Server 2007 Help (http://go.microsoft.com/fwlink/?LinkId=79424).

For More Information

For more information about granting Microsoft Outlook permissions, see Delegate Access permissions in Outlook Help.

How to Allow Mailbox Access

This topic explains how to use the Exchange Management Shell to grant full access permissions for a mailbox or Receive As permissions for a mailbox database.

When you grant a user full access permissions to a mailbox, that user has full access to only the mailbox for which the permissions are applied. With full access permissions, the user can open and read the contents of the mailbox. However, the user cannot send as that mailbox without additional permissions. For information about granting Send As permissions, see How to Grant Send As Permissions for a Mailbox.

When you grant a user has Receive As permissions to a mailbox database, that user can log in to all mailboxes within that database, but is not able to send e-mail messages from those mailboxes. Also, if you grant Receive As permissions at the storage group level, the specified user can log in to all mailboxes within all databases in the storage group. For example, you may want to grant access to the mailbox database for mobile access or for legal review.

Full access or Receive As permissions are not granted until Microsoft Exchange Information Store service caches the permissions and updates the cache. To grant the permission immediately, stop and then restart the Microsoft Exchange Information Store service.

Before You Begin

To perform this procedure, the account you use must be delegated the following:

Exchange Organization Administrator role

For more information about permissions, delegating roles, and the rights that are required to administer Exchange Server 2007, see Permission Considerations.

To use the Exchange Management Shell to grant full access permissions for a mailbox

Run the following command to add the permission directly to the mailbox:

Add-MailboxPermission "Mailbox" -User "Trusted User" -AccessRights FullAccess

To use the Exchange Management Shell to grant Receive As permissions for a mailbox database

Run the following command to add the permission to the mailbox database:

Add-ADPermission -Identity "Mailbox Store" -User "Trusted User" -ExtendedRights Receive-As

For detailed syntax and parameter information, see "Add-MailboxPermission" in Exchange Server 2007 Help (http://go.microsoft.com/fwlink/?LinkId=79424).

For More Information

For more information about granting Microsoft Outlook permissions, see Delegate Access permissions in Outlook Help.

How to Set or Change a Windows Password by Using Outlook Web Access

This topic explains how to use Microsoft Office Outlook Web Access to change a Microsoft Windows password.

Before You Begin

To use Outlook Web Access to change a Windows password, you must be logged on to Outlook Web Access by using the account for which you want to change the password.

To use Outlook Web Access to change a Windows password

1. Open Outlook Web Access by using the account for which you want to change the password.

2. Click Options.

3. Click Change Password.

4. Enter your old password.

5. Enter your new password.

6. Confirm your new password by entering it again.

7. Click Save.

How to Add an Exchange Recipient Configuration Node to Microsoft Management Console

This topic explains how to add an Exchange recipient configuration snap-in to Microsoft Management Console 3.0. In Microsoft Exchange Server 2007, you can customize the presentation of object properties that you access when you use the Exchange Management Console.

Before You Begin

To perform this procedure, the account you use must be delegated the following:

Exchange Organization Administrator role

Note:

If you want permissions to only view your recipients, you must have Exchange View-Only Administrator permissions.

To add an Exchange Recipient Configuration node to Microsoft Management Console

1. Click Start, click Run, type MMC in the Open field, and then click OK.

2. On the Console menu bar, click File, and then click Add/RemoveSnap-in.

3. In Add/Remove Snap-in, on the Standalone tab, click Add.

4. In Add Standalone Snap-in, select Exchange Server 2007 from the list of available stand-alone snap-ins, and then click Add.

5. Click Close to close the Available Snap-ins dialog box, and then click OK on the Add/Remove Snap-in dialog box.

6. Expand the Microsoft Exchange node, and then right-click the Recipient Configuration node and select New Window from Here.

7. Maximize the Recipient Configuration window, and then select File and Options.

8. Change the console name from Console 1 to EMC - Recipient Configuration.

9. Change the console mode from Author Mode to User Mode - Full Access.

10. Enable the Do not save changes to this console check box and then click OK.

For more information about permissions, delegating roles, and the rights that are required to administer Exchange 2007, see Permission Considerations.

How to Delegate Server Administration

Microsoft Exchange Server 2007 provides the ability for Exchange administrators to delegate administrative and management responsibility for a server to an individual or group of individuals when it operates in a distributed operations management scenario. This topic explains how to delegate administrative and management responsibility for a server by using the Exchange Management Console or the Exchange Management Shell.

The Exchange Server Administrators delegated role has access to only local server Exchange configuration data, either in the Active Directory directory service or on the physical computer on which Exchange 2007 is installed. Users who are members of the Exchange Server Administrators role have permissions to administer a particular server, but do not have permissions to perform operations that have global effect in the Exchange organization.

In addition, Exchange Server Administrators can add and remove server roles to the Exchange server. However, they cannot remove the last server role from the server. Therefore, Exchange Server Administrators cannot uninstall an Exchange server.

When you delegate a user or group the Exchange Server Administrator role, that user or group is assigned permissions so that the user or group is owner of all local server configuration data. As owner, the server administrator has full control over the local server configuration data on the server object within the configuration partition.

The following access control entries are granted to the delegated account on the server object within the configuration partition:

Full control on the server object and its children
Deny access control entry for the Send As extended right
Deny access control entry for the Receive As extended right
Deny CreateChild and DeleteChild permissions for Exchange Public Folder Store objects. Public folders are an organizational responsibility and therefore the creation, deletion, or both of public folder stores is restricted to Exchange Organization Administrators.

The delegated account is added automatically to the target server’s local administrator group on the computer on which Microsoft Exchange is installed.

The delegated account is also added to the membership of the Exchange Organization View-Only Administrators security group.

You can delegate server administration by using the Exchange Management Console or the Exchange Management Shell.

Important:

As explained earlier in this topic, the Exchange Server Administrator role is a delegated set of permissions that allows a user or group to administer a particular Exchange computer. Do not confuse the Exchange Server Administrator role with the Exchange Server security group in Active Directory. The Exchange Server security group contains the computer objects that are running Exchange in your organization.

Before You Begin

To perform this procedure, the account you use must be delegated the Exchange Organization Administrator role.

For more information about permissions, delegating roles, and the rights that are required to administer Exchange 2007 see Permission Considerations.

To use the Exchange Management Console to delegate Server Administrator role to a user or group

1. In the Exchange Management Console, select Organization Configuration.

2. In the Action pane, select the Add Exchange Administrator link.

3. On the Add Exchange Administrator page, click Browse and select the user or group that you want to delegate control to, and then select Exchange Server Administrator role.

4. Under Select the server(s) to which this role has access, click Add, and then select the server to which you want to delegate control. Click OK. Click Add.

5. On the Completion page, click Finish.

To use the Exchange Management Shell to delegate the Server Administrator role to a user or group

Run the following command:

Add-ExchangeAdministrator -Identity “contoso.com/Users/KwekuA” -Role ServerAdmin -Scope server1.contoso.com

Where “contoso.com/Users/KwekuA” is the full path of the user or group that you want to delegate permission to and server1.contoso.com is the fully qualified domain name (FQDN) of the server that you want to provision.

For detailed syntax and parameter information, see "Add-ExchangeAdministrator" in Exchange Server 2007 Help (http:// go.microsoft.com/fwlink/?LinkId =79424).

For More Information

For more information, see the following topics in Exchange Server 2007 Help (http://go.microsoft.com/fwlink/?linkid=65320):

Configuring Permissions
Permission Considerations
Add-ExchangeAdministrator

Configuring Public Folder Permissions

You can configure public folder permissions for both administrators of Microsoft Exchange Server 2007 or for users of client programs such as Microsoft Office Outlook 2007. Public folder permissions consist of various access rights that specify the level of control a client user or administrator has over a public folder or public folder hierarchy.

This topic includes the following information about public folder permissions:

The access rights and predefined permission roles (which consist of specific access rights) that you can configure for client users.
The access rights that you can configure for administrators. (There are no predefined public folder permission roles for administrators.)
Links to the management tasks you can perform for client users and administrators.

Note:

When you create a new public folder within an existing public folder hierarchy, that public folder inherits the permissions of the parent folder.

Client User Access Rights and Permission Roles

In Exchange 2007, you use the Exchange Management Shell to configure the permissions for the users who use client programs such as Outlook to access public folders. Whether you want to manually select the access rights or use predefined permission roles that contain specific access rights, you will use the Add-PublicFolderClientPermissions cmdlet to perform the tasks. The following is a list of client user access rights (followed by a table that shows the predefined permission roles):

ReadItems The user has the right to read items within the specified public folder.
CreateItems The user has the right to create items within the specified public folder.
EditOwnedItems The user has the right to edit the items that the user owns in the specified public folder.
DeleteOwnedItems The user has the right to delete items that the user owns in the specified public folder.
EditAllItems The user has the right to edit all items in the specified public folder.
DeleteAllItems The user has the right to delete all items in the specified public folder.
CreateSubfolders The user has the right to create subfolders in the specified public folder.
FolderOwner The user is the owner of the specified public folder.
FolderContact The user is the contact for the specified public folder.
FolderVisible The user can view the specified public folder, but cannot read or edit items within the specified public folder.

The following table lists the predefined permission roles and the access rights that are included in each role.

Permission role

CanCreate

CanRead

CanCreateSubfolders

IsFolderOwner

Is Folder Contact

IsFolderVisible

EditItems

DeleteItems

None

X

None

None

Owner

X

X

X

X

X

X

All

All

PublishingEditor

X

X

X

X

All

All

Editor

X

X

X

All

All

PublishingAuthor

X

X

X

X

Own

Own

Author

X

X

X

Own

Own

Non-EditingAuthor

X

X

X

None

Own

Reviewer

X

X

None

None

Contributor

X

X

None

None

Note:

Client users can use Outlook to manage public folder client access permissions. For information about how to manage public folder permissions from Outlook 2007, see Create and share a public folder. For information about how to manage public folder permissions from Outlook 2003, see Outlook folder permissions.

Administrator Access Rights

By default, when you create a top-level public folder, users who have permissions that are granted by specific Exchange administrator roles and Microsoft Windows security groups are automatically added as administrators to that public folder. The following list shows which roles and groups automatically have administrative rights to a new top-level public folder, including the specific access rights granted to each:

Exchange administrator roles:
Exchange Server Administrator (granted AllExtendedRights)
Exchange Organization Administrator (granted AllExtendedRights)
Exchange View-Only Administrator (granted ViewInformationStore)
Windows security groups:
Enterprise Admins (granted AllExtendedRights)
Administrator (granted AllExtendedRights)
Domain Admins (granted AllExtendedRights)

The following list describes the standard set of administrative access rights that can be set on a public folder:

None The administrator does not have any rights to modify public folder attributes.
ModifyPublicFolderACL The administrator has the right to modify client access permissions for the specified folder.
ModifyPublicFolderAdminACL The administrator has the right to modify administrator permissions for the specified public folder.
ModifyPublicFolderDeletedItemRetention The administrator has the right to modify the Public Folder Deleted Item Retention attributes (RetainDeletedItemsFor, UseDatabaseRetentionDefaults).
ModifyPublicFolderExpiry The administrator has the right to modify the Public Folder Expiration attributes (AgeLimit, UseDatabaseAgeDefaults).
ModifyPublicFolderQuotas The administrator has the right to modify the Public Folder Quota attributes (MaxItemSize, PostQuota, PostWarningQuota, UseDatabaseQuotaDefaults)
ModifyPublicFolderReplicaList The administrator has the right to modify the replica list attribute for the specified public folder (Replicas).
AdministerInformationStore The administrator has the right to modify all other public folder properties not defined previously.
ViewInformationStore The administrator has the right to view public folder properties.
AllExtendedRights The administrator has the right to modify all public folder properties.

Management Tasks for Configuring Public Folder Permissions

This section lists the management tasks that you can perform to configure and maintain public folder permissions:

How to Add Permissions for Client Users to Access Public Folder Content

You can use the Add-PublicFolderClientPermission cmdlet or the AddUserToPFRecursive.ps1 user management script to specify the permissions for the client user. You can create the access rights by using either the predefined permission roles or by creating custom access rights.

How to Remove or Replace Public Folder Client Permissions

You can use the Remove-PublicFolderClientPermission cmdlet or the RemoveUserFromPFRecursive.ps1 script to remove permissions for the client user. You can remove access rights by using either the predefined permission roles or by using the access rights.

You can use the ReplaceUserWithUserOnPFRecursive.ps1 and ReplaceUserPermissionOnPFRecursive.ps1 scripts to replace client permissions on a public folder. For more information about the public folder management scripts, see "Scripts for Managing Public Folders in the Exchange Management Shell" in Exchange Server 2007 Help (http://go.microsoft.com/fwlink/?linkid=65320).

How to View Public Folder Client Permissions Settings

You can use the Get-PublicFolderClientPermission cmdlet to view the client access rights associated with a public folder.

How to Add Administrative Permissions for Users to Access Public Folders

You can use the Add-PublicFolderAdministratorPermission cmdlet to grant administrative rights for a user to access a public folder or public folder hierarchy.

How to Remove Public Folder Administrative Permissions

You can use the Remove-PublicFolderAdministratorPermission cmdlet to remove administrative access rights from a user for a public folder or public folder hierarchy.

How to View Public Folder Administrative Permission Settings

You can use the Get-PublicFolderAdministratorPermission cmdlet to view the administrative rights that are associated with a public folder or public folder hierarchy.

For More Information

To learn more about public folders, see "Understanding Public Folders" in Exchange Server 2007 Help (http://go.microsoft.com/fwlink/?linkid=65320).

For more information about managing public folders, see "Managing Public Folders" in Exchange Server 2007 Help (http://go.microsoft.com/fwlink/?linkid=65320).

How to Add Permissions for Client Users to Access Public Folder Content

This topic explains how to use the Exchange Management Shell to add permissions for users of client programs (such as Microsoft Outlook) to access and modify public folder content. When adding these permissions, you can either use predefined permission roles (which consist of specific access rights) or you can customize permissions by manually applying the available access rights. To specify the permissions for the client user, you can use the Add-PublicFolderClientPermission cmdlet or the AddUsersToPFRecursive.ps1 user management script. For more information about the permission roles and access rights, see Configuring Public Folder Permissions.

Note:

If a client user already has a specific access right to a public folder, you cannot add the same access right again. Therefore, if you use the AddUsersToPFRecursive.ps1 script, and the user already has one of the access rights that you are trying to grant, a warning will appear stating that the current access rights will be removed before new access rights are granted.

Before You Begin

To perform this procedure, the account you use must be delegated the following:

Exchange Server Administrator role and local Administrators group for the target server

For more information about permissions, delegating roles, and the rights that are required to administer Exchange 2007, see Permission Considerations.

Also, before you perform this procedure, be sure to read the topic Configuring Public Folder Permissions.

To use the Exchange Management Shell to specify client access rights to a public folder by using the Add-PublicFolderClientPermission cmdlet

To add Publishing Editor permissions for the user Kim to access the public folder named West Coast, run the following command:

Add-PublicFolderClientPermission -Identity "\Marketing\West Coast" -AccessRights PublishingEditor -User Kim

For detailed syntax and parameter information, see "Add-PublicFolderClientPermission" in Exchange Server 2007 Help (http://go.microsoft.com/fwlink/?LinkId=79424).

To use the Exchange Management Shell to specify client access rights to a public folder by using the AddUsersToPFRecursive.ps1 management script

To add Reviewer permissions for the user David to access the top-level public folder named Sales and all of the public folders contained within the Sales tree, run the following command:

AddUsersToPFRecursive.ps1 -TopPublicFolder "\Sales" -User "David" -Permission Reviewer

For more information about how to use public folder management scripts, see "Scripts for Managing Public Folders in the Exchange Management Shell" in Exchange Server 2007 Help (http://go.microsoft.com/fwlink/?linkid=65320).

For More Information

To learn more about public folders, see "Understanding Public Folders" in Exchange Server 2007 Help (http://go.microsoft.com/fwlink/?linkid=65320).

For more information about managing public folders, see "Managing Public Folders" in Exchange Server 2007 Help (http://go.microsoft.com/fwlink/?linkid=65320).

For more information about configuring public folder permissions, see Configuring Public Folder Permissions.

How to Remove or Replace Public Folder Client Permissions

This topic explains how to use the Exchange Management Shell to perform the following tasks:

Remove permissions for users of client programs (such as Microsoft Outlook) to access and modify the content within a public folder or public folder hierarchy.
Replace a user with a new user in the client permissions list for a public folder or public folder hierarchy.
Replace permissions for users of client programs to access and modify the content within a public folder or public folder hierarchy.

Note:

You cannot use the Exchange Management Console to perform this procedure.

When removing these permissions, you can either use predefined permission roles (which consist of specific access rights) or manually remove the available access rights. To remove the permissions from the client user, you can use the Remove-PublicFolderClientPermission cmdlet or the RemoveUserFromPFRecursive.ps1 user management script.

To replace the users or permissions, use the following scripts:

ReplaceUserWithUserOnPFRecursive.ps1 This script replaces a user with a new user in the client permissions list for a public folder and any folders that exist within it. Existing permissions for the first user are retained. Public folders that do not contain permissions for the user are not modified.
ReplaceUserPermissionOnPFRecursive.ps1 This script replaces a user's permissions to a public folder and any folders that exist under it with a new set of permissions. Public folders that do not contain permissions for the user are not modified.

For more information about the public folder management scripts, see "Scripts for Managing Public Folders in the Exchange Management Shell" in Exchange Server 2007 Help (http://go.microsoft.com/fwlink/?linkid=65320).

Before You Begin

To perform these procedures, the account you use must be delegated the following:

Exchange Server Administrator role and local Administrators group for the target server

For more information about permissions, delegating roles, and the rights that are required to administer Microsoft Exchange Server 2007, see Permission Considerations.

Also, before you perform these procedures, be sure to read the topic Configuring Public Folder Permissions.

To use the Exchange Management Shell to remove a client user's permissions to access a public folder

To remove user David's permissions to create items in the public folder named Oregon, run the following command:

Remove-PublicFolderClientPermission -Identity "Sales\West Coast\Oregon" -User David -AccessRights CreateItems

For detailed syntax and parameter information, see "Remove-PublicFolderClientPermission" in Exchange Server 2007 Help (http:// go.microsoft.com/fwlink/?LinkId =79424).

To use the Exchange Management Shell to remove a user's client permission for a public folder and all folders under it

To remove user David's permissions to access the public folder named Oregon and all folders under it, run the following command:

RemoveUserFromPFRecursive.ps1 -Server "SERVER01" -TopPublicFolder -"\Sales\Oregon" -User "David"

To use the Exchange Management Shell to replace a user with a new user in the client permissions list for a public folder and all public folders under it

To replace user David with user Kim to access items in the public folder Sales and all folders under it, run the following command:

ReplaceUserWithUserOnPFRecursive.ps1 -TopPublicFolder "\Sales" -UserOld "David" -UserNew "Kim"

To use the Exchange Management Shell to replace the permissions of a user in the client permissions list for a public folder with a new set of permissions

To replace user Kim's current permissions to access the public folder named Marketing and all folders under it with Publishing Editor permissions, run the following command:

ReplaceUserPermissionOnPFRecursive.ps1 -Server "SERVER01" -TopPublicFolder "\Marketing" -User "Kim" -Permissions PublishingEditor

For More Information

To learn more about public folders, see "Understanding Public Folders" in Exchange Server 2007 Help (http://go.microsoft.com/fwlink/?linkid=65320).

For more information about managing public folders, see "Managing Public Folders" in Exchange Server 2007 Help (http://go.microsoft.com/fwlink/?linkid=65320).

How to View Public Folder Client Permissions Settings

This topic explains how to use the Exchange Management Shell to view information about the client access permissions to a public folder.

Note:

You cannot use the Exchange Management Console to perform this procedure.

Before You Begin

To perform this procedure, the account you use must be delegated the following:

Exchange View-Only Administrator

For more information about permissions, delegating roles, and the rights that are required to administer Microsoft Exchange Server 2007, see Permission Considerations.

Also, before you perform this procedure, be sure to read Configuring Public Folder Permissions.

To use the Exchange Management Shell to view the client access permissions to a public folder

To view the entire list of the client access permissions for the public folder named Marketing, run the following command:

Get-PublicFolderClientPermission -Identity "\Marketing" | fl

To view the user David's client access permissions to the public folder named East Coast, run the following command:

Get-PublicFolderClientPermission -Identity "\Marketing\EastCoast" -User David

For detailed syntax and parameter information, see "Get-PublicFolderClientPermission" in Exchange Server 2007 Help (http://go.microsoft.com/fwlink/?LinkId=79424).

For More Information

To learn more about public folders, see "Understanding Public Folders" in Exchange Server 2007 Help (http://go.microsoft.com/fwlink/?linkid=65320).

For more information about managing public folders, see "Managing Public Folders" in Exchange Server 2007 Help (http://go.microsoft.com/fwlink/?linkid=65320).

For more information about managing public folder permissions, see Configuring Public Folder Permissions.

How to Add Administrative Permissions for Users to Access Public Folders

This topic explains how to use the Exchange Management Shell to add administrative permissions for users to access a public folder or public folder hierarchy. When adding these permissions, the access rights you apply depend on the level of access you want the user to have. For a list of the available access rights for administrative permissions, see Configuring Public Folder Permissions.

Before You Begin

To perform the following procedure, the account you use must be delegated the following:

Exchange Server Administrator role and local Administrators group for the target server

For more information about permissions, delegating roles, and the rights that are required to administer Microsoft Exchange Server 2007, see Permission Considerations.

Also, before you perform this procedure, be sure to read the topic Configuring Public Folder Permissions.

To use the Exchange Management Shell to add administrative permissions for a user to access a public folder

To add AllExtendedRights permissions for the user Chris to access the public folder named Marketing, run the following command:

Add-PublicFolderAdministrativePermission -Identity "\Marketing" -User "Chris" -AccessRights AllExtendedRights -Inheritance SelfAndChildren

For detailed syntax and parameter information, see "Add-PublicFolderAdministrativePermission" in Exchange Server 2007 Help (http://go.microsoft.com/fwlink/?LinkId=79424).

For More Information

For more information about public folders, see "Understanding Public Folders" in Exchange Server 2007 Help (http://go.microsoft.com/fwlink/?linkid=65320).

For more information about managing public folders, see "Managing Public Folders" in Exchange Server 2007 Help (http://go.microsoft.com/fwlink/?linkid=65320).

For more information about using the Exchange Management Shell, see "Using the Exchange Management Shell" in Exchange Server 2007 Help (http://go.microsoft.com/fwlink/?linkid=65320).

How to Remove Public Folder Administrative Permissions

This topic explains how to use the Exchange Management Shell to remove administrative permissions from users to access a public folder or public folder hierarchy.

Note:

You cannot use the Exchange Management Console to perform this procedure.

Before You Begin

To perform the following procedure, the account you use must be delegated the following:

Exchange Server Administrator role and local Administrators group for the target server

For more information about permissions, delegating roles, and the rights that are required to administer Microsoft Exchange Server 2007, see Permission Considerations.

Also, before you perform this procedure, be sure to read the topic Configuring Public Folder Permissions.

To use the Exchange Management Shell to remove administrative permissions for a user to access a public folder or public folder hierarchy

1. To remove all administrative rights for the user Kim to the entire public folder tree, run the following command:

Remove-PublicFolderAdministrativePermission -Identity "\" -User "Kim" -AccessRights AllExtendedRights -InheritanceType All

2. A warning appears asking if you are sure you want to perform this action. Type Y to confirm.

For detailed syntax and parameter information, see "Remove-PublicFolderAdministrativePermission" in Exchange Server 2007 Help (http://go.microsoft.com/fwlink/?LinkId=79424).

For More Information

For more information about public folders, see "Understanding Public Folders" in Exchange Server 2007 Help (http://go.microsoft.com/fwlink/?linkid=65320).

For more information about managing public folders, see "Managing Public Folders" in Exchange Server 2007 Help (http://go.microsoft.com/fwlink/?linkid=65320).

For more information about using the Exchange Management Shell, see "Using the Exchange Management Shell" in Exchange Server 2007 Help (http://go.microsoft.com/fwlink/?linkid=65320).

How to View Public Folder Administrative Permission Settings

This topic explains how to use the Exchange Management Shell to view information about administrative permissions for a public folder.

Note:

You cannot use the Exchange Management Console to perform this procedure.

Before You Begin

To perform the following procedure, the account you use must be delegated the following:

Exchange View-Only Administrator role

For more information about permissions, delegating roles, and the rights that are required to administer Microsoft Exchange Server 2007, see Permission Considerations.

Also, before you perform this procedure, be sure to read Configuring Public Folder Permissions.

To use the Exchange Management Shell to view information about administrative permissions for a public folder

To view the user David's access rights for the public folder named Marketing, run the following command:

Get-PublicFolderAdministrativePermission -Identity "\Marketing" -User "David"

To view the administrative access rights sorted by user for the public folder named Sales, run the following command:

Get-PublicFolderAdministrativePermission -Identity "\Sales" | fl User,AccessRights

For detailed syntax and parameter information, see "Get-PublicFolderAdministrativePermission" in Exchange Server 2007 Help (http://go.microsoft.com/fwlink/?LinkId=79424).

For More Information

To learn more about public folders, see "Understanding Public Folders" in Exchange Server 2007 Help (http://go.microsoft.com/fwlink/?linkid=65320).

For more information about managing public folders, see "Managing Public Folders" in Exchange Server 2007 Help (http://go.microsoft.com/fwlink/?linkid=65320).

For more information about using the Exchange Management Shell, see "Using the Exchange Management Shell" in Exchange Server 2007 Help (http://go.microsoft.com/fwlink/?linkid=65320).

Configuring Permissions in Exchange Server 2007

menguin

Geek

Latest posts