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:
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:
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:
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:
Exchange 2007 has the following predefined groups that manage Exchange configuration data:
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:
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:
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:
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:
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:
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:
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:
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:
Certain operations, such as moving mailboxes, require Exchange Server Administrator role or higher.
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:
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):
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:
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:
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
For detailed syntax and parameter information, see "Add-ExchangeAdministrator" in Exchange Server 2007 Help (http:// go.microsoft.com/fwlink/?LinkId =79424).
For More Information
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:
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
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:
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
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:
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:
To use the Exchange Management Shell to grant full access permissions for a mailbox
To use the Exchange Management Shell to grant Receive As permissions for a mailbox database
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:
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:
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
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 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:
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):
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:
This section lists the management tasks that you can perform to configure and maintain public folder permissions:
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).
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:
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
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
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:
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:
Before You Begin
To perform these procedures, the account you use must be delegated the following:
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
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 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 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
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:
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
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:
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
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:
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:
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
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).
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.
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
- 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).
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.
Exchange 2007 has the following predefined groups that manage Exchange configuration data:
- Exchange Organization Administrators
- Exchange Recipient Administrators
- Exchange View-Only Administrators
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.
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.
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.
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.
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.
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
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)
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
- 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.
- Exchange View-Only Administrator role or higher
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.
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
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.
- 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.
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
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
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:
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
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
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:
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
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
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:
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:
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
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 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:
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.
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.
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)
- 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.
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
- How to Remove or Replace Public Folder Client Permissions
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
- How to Add Administrative Permissions for Users to Access Public Folders
- How to Remove Public Folder Administrative Permissions
- How to View Public Folder Administrative Permission Settings
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
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:
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:
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.
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.
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
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:
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:
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:
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:
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
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:
- To view the user David's client access permissions to the public folder named East Coast, run the following command:
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
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:
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
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
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:
- To view the administrative access rights sorted by user for the public folder named Sales, run the following command:
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).